chapter\Common Criteria Definitions\ (*<<*) theory CC_terminology imports "../technical_report/technical_report" begin text\We re-use the class @\typ math_content\, which provides also a framework for semi-formal terminology, which we re-use by this definition.\ doc_class concept_definition = math_content + status :: status <= "semiformal" mcc :: math_content_class <= "terminology" tag :: string short_tag :: "string option" <= "None" text\The \<^verbatim>\short_tag\, if set, is used in the presentation directly.\ type_synonym concept = concept_definition declare[[ Definition_default_class="concept_definition"]] (*>>*) section \Terminology\ subsection \Terms and definitions common in the CC\ Definition* [aas_def, tag= "''adverse actions''"] \actions performed by a threat agent on an asset\ declare_reference*[toe_def] Definition* [assts_def, tag="''assets''"] \entities that the owner of the @{docitem toe_def} presumably places value upon \ Definition* [asgn_def, tag="''assignment''"] \the specification of an identified parameter in a component (of the CC) or requirement.\ declare_reference*[sfrs_def] Definition* [assrc_def, tag="''assurance''"] \grounds for confidence that a @{docitem toe_def} meets the @{docitem sfrs_def}\ Definition* [attptl_def, tag="''attack potential''"] \measure of the effort to be expended in attacking a TOE, expressed in terms of an attacker's expertise, resources and motivation\ Definition* [argmt_def, tag= "''augmentation''"] \addition of one or more requirement(s) to a package\ Definition* [authdata_def, tag="''authentication data''"] \information used to verify the claimed identity of a user\ Definition* [authusr_def, tag = "''authorised user''"] \@{docitem toe_def} user who may, in accordance with the @{docitem sfrs_def}, perform an operation\ Definition* [bpp_def, tag="''Base Protection Profile''"] \Protection Profile used as a basis to build a Protection Profile Configuration\ Definition* [cls_def,tag="''class''"] \set of CC families that share a common focus\ Definition* [cohrnt_def,tag="''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.\ Definition* [cmplt_def, tag="''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.\ Definition* [compnt_def, tag="''component''"] \smallest selectable set of elements on which requirements may be based\ Definition*[cap_def, tag="''composed assurance package''"] \assurance package consisting of requirements drawn from CC Part 3 (predominately from the ACO class), representing a point on the CC predefined composition assurance scale\ Definition* [cfrm_def,tag="''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.\ Definition* [cnnctvty_def, tag="''connectivity''"] \property of the @{docitem toe_def} allowing interaction with IT entities external to the @{docitem toe_def} This includes exchange of data by wire or by wireless means, over any distance in any environment or configuration.\ Definition* [cnstnt_def, tag="''consistent''"] \relationship between two or more entities such that there are no apparent contradictions between these entities\ Definition* [cnt_vrb_def, tag="''counter, verb''"] \meet an attack where the impact of a particular threat is mitigated but not necessarily eradicated\ declare_reference*[st_def] declare_reference*[pp_def] Definition* [dmnst_conf_def, tag="''demonstrable conformance''"] \relation between an @{docitem st_def} and a @{docitem pp_def}, where the @{docitem st_def} provides a solution which solves the generic security problem in the PP The @{docitem pp_def} and the @{docitem st_def} may contain entirely different statements that discuss different entities, use different concepts etc. Demonstrable conformance is also suitable for a @{docitem toe_def} type where several similar @{docitem pp_def}s already exist, thus allowing the ST author to claim conformance to these @{docitem pp_def}s simultaneously, thereby saving work.\ Definition* [dmstrt_def, tag="''demonstrate''"] \provide a conclusion gained by an analysis which is less rigorous than a “proof”\ Definition* [dpndcy, tag="''dependency''"] \relationship between components such that if a requirement based on the depending component is included in a @{docitem pp_def}, ST or package, a requirement based on the component that is depended upon must normally also be included in the @{docitem pp_def}, @{docitem st_def} or package\ Definition* [dscrb_def, tag="''describe''"] \provide specific details of an entity\ Definition* [dtrmn_def, tag="''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\ Definition* [devenv_def, tag="''development environment''"] \environment in which the @{docitem toe_def} is developed\ Definition* [elmnt_def, tag="''element''"] \indivisible statement of a security need\ Definition* [ensr_def, tag="''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.\ Definition* [eval_def, tag="''evaluation''"] \assessment of a @{docitem pp_def}, an @{docitem st_def} or a @{docitem toe_def}, against defined criteria.\ Definition* [eal_def, tag= "''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\ Definition* [eval_auth_def, tag="''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\ Definition* [eval_schm_def, tag="''evaluation scheme''"] \administrative and regulatory framework under which the CC is applied by an evaluation authority within a specific community\ Definition* [exst_def, tag="''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.\ Definition* [expln_def, tag="''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.\ Definition* [extn_def, tag= "''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\ Definition* [extnl_ent_def, tag="''external entity''"] \human or IT entity possibly interacting with the TOE from outside of the TOE boundary\ Definition* [fmly_def, tag="''family''"] \set of components that share a similar goal but differ in emphasis or rigour\ Definition* [fml_def, tag="''formal''"] \expressed in a restricted syntax language with defined semantics based on well-established mathematical concepts \ Definition* [gudn_doc_def, tag="''guidance documentation''"] \documentation that describes the delivery, preparation, operation, management and/or use of the TOE\ Definition* [ident_def, tag="''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.\ Definition* [infml_def, tag="''informal''"] \expressed in natural language\ Definition* [intr_tsf_trans_def, tag ="''inter TSF transfers''"] \communicating data between the TOE and the security functionality of other trusted IT products\ Definition* [intl_com_chan_def, tag ="''internal communication channel''"] \communication channel between separated parts of the TOE\ Definition* [int_toe_trans, tag="''internal TOE transfer''"] \communicating data between separated parts of the TOE\ Definition* [inter_consist_def, tag="''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.\ Definition* [iter_def, tag="''iteration''"] \use of the same component to express two or more distinct requirements\ Definition* [jstfct_def, tag="''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.\ Definition* [objct_def, tag="''object''"] \passive entity in the TOE, that contains or receives information, and upon which subjects perform operations\ Definition* [op_cc_cmpnt_def, tag ="''operation (on a component of the CC)''"] \modification or repetition of a component Allowed operations on components are assignment, iteration, refinement and selection.\ Definition* [op_obj_def, tag= "''operation (on an object)''"] \specific type of action performed by a subject on an object\ Definition* [op_env_def, tag= "''operational environment''"] \environment in which the TOE is operated\ Definition* [org_sec_po_def, tag="''organisational security policy''"] \set of security rules, procedures, or guidelines for an organisation A policy may pertain to a specific operational environment.\ Definition* [pckg_def, tag="''package''"] \named set of either security functional or security assurance requirements An example of a package is “EAL 3”.\ Definition* [pp_config_def, tag="''Protection Profile Configuration''"] \Protection Profile composed of Base Protection Profiles and Protection Profile Module\ Definition* [pp_eval_def, tag="''Protection Profile evaluation''"] \ assessment of a PP against defined criteria \ Definition* [pp_def, tag="''Protection Profile''"] \implementation-independent statement of security needs for a TOE type\ Definition* [ppm_def, tag="''Protection Profile Module''"] \implementation-independent statement of security needs for a TOE type complementary to one or more Base Protection Profiles\ declare_reference*[tsf_def] Definition* [prv_def, tag="''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 @{docitem tsf_def} representations at a high level of rigour.\ Definition* [ref_def, tag="''refinement''"] \addition of details to a component\ Definition* [role_def, tag="''role''"] \predefined set of rules establishing the allowed interactions between a user and the @{docitem toe_def}\ declare_reference*[sfp_def] Definition* [scrt_def, tag="''secret''"] \information that must be known only to authorised users and/or the @{docitem tsf_def} in order to enforce a specific @{docitem sfp_def}\ declare_reference*[sfr_def] Definition* [sec_st_def, tag="''secure state''"] \state in which the @{docitem tsf_def} data are consistent and the @{docitem tsf_def} continues correct enforcement of the @{docitem sfr_def}s\ Definition* [sec_att_def, tag="''security attribute''"] \property of subjects, users (including external IT products), objects, information, sessions and/or resources that is used in defining the @{docitem sfr_def}s and whose values are used in enforcing the @{docitem sfr_def}s\ Definition* [sec_def, tag="''security''"] \function policy set of rules describing specific security behaviour enforced by the @{docitem tsf_def} and expressible as a set of @{docitem sfr_def}s\ Definition* [sec_obj_def, tag="''security objective''"] \statement of an intent to counter identified threats and/or satisfy identified organisation security policies and/or assumptions\ Definition* [sec_prob_def, tag ="''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: \begin{itemize}  \item threats to be countered by the TOE and its operational environment,  \item the OSPs enforced by the TOE and its operational environment, and  \item the assumptions that are upheld for the operational environment of the TOE. \end{itemize}\ Definition* [sr_def, tag="''security requirement''", short_tag="Some(''SR'')"] \requirement, stated in a standardised language, which is meant to contribute to achieving the security objectives for a TOE\ text \@{docitem toe_def}\ Definition* [st, tag="''Security Target''", short_tag="Some(''ST'')"] \implementation-dependent statement of security needs for a specific i\
dentified @{docitem toe_def}\ Definition* [slct_def, tag="''selection''"] \specification of one or more items from a list in a component\ Definition* [smfrml_def, tag="''semiformal''"] \expressed in a restricted syntax language with defined semantics\ Definition* [spcfy_def, tag= "''specify''"] \provide specific details about an entity in a rigorous and precise manner\ Definition* [strct_conf_def, tag="''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. \ Definition* [st_eval_def, tag="''ST evaluation''"] \assessment of an ST against defined criteria\ Definition* [subj_def, tag="''subject''"] \active entity in the TOE that performs operations on objects\ Definition* [toe, tag= "''target of evaluation''"] \set of software, firmware and/or hardware possibly accompanied by guidance\ Definition* [thrt_agnt_def, tag="''threat agent''"] \entity that can adversely act on assets\ Definition* [toe_eval_def, tag="''TOE evaluation''"] \assessment of a TOE against defined criteria\ Definition* [toe_res_def, tag="''TOE resource''"] \anything useable or consumable in the TOE\ Definition* [toe_sf_def, tag="''TOE security functionality''", short_tag= "Some(''TSF'')"] \combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the correct enforcement of the @{docitem sfr_def}s\ Definition* [tr_vrb_def, tag="''trace, verb''"] \perform an informal correspondence analysis between two entities with only a minimal level of rigour\ Definition* [trnsfs_out_toe_def, tag="''transfers outside of the TOE''"] \TSF mediated communication of data to entities not under the control of the TSF\ Definition* [transl_def, tag= "''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.\ Definition* [trst_chan_def, tag="''trusted channel''"] \a means by which a TSF and another trusted IT product can communicate with necessary confidence\ Definition* [trst_it_prod_def, tag="''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.\ Definition* [trst_path_def, tag="''trusted path''"] \means by which a user and a TSF can communicate with the necessary confidence\ Definition* [tsf_data_def, tag="''TSF data''"] \data for the operation of the TOE upon which the enforcement of the SFR relies\ Definition* [tsf_intrfc_def, tag="''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\ Definition* [usr_def, tag="''user''"] \see external entity\ Definition* [usr_datat_def, tag="''user data''"] \data for the user, that does not affect the operation of the TSF\ Definition* [vrfy_def, tag="''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.\ Definition* [dev_def, tag="''Developer''"] \who respond to actual or perceived consumer security requirements in constructing a @{docitem toe_def}, reference this CC_Part_3 when interpreting statements of assurance requirements and determining assurance approaches of @{docitem toe}s.\ Definition*[evalu_def, tag="'' Evaluator''"] \who use the assurance requirements defined in CC_Part_3 as mandatory statement of evaluation criteria when determining the assurance of @{docitem toe_def}s and when evaluating @{docitem pp_def}s and @{docitem st_def}s.\ end