Раздел: Документация
0 ... 6 7 8 9 10 11 12 ... 20  Security Environment material (PP/ST)  Security Objectives material (PP/ST) Security Requirements material (PP/ST) Security Specification material (ST) Figure 4.5 - Derivation of requirements and specifications 4.3.1 security environment The security environment includes all the laws, organisational security policies, customs, expertise and knowledge that are determined to be relevant. It thus defines the context in which the TOE is intended to be used. The security environment also includes the threats to security that are, or are held to be, present in the environment. To establish the security environment, the PP or ST writer has to take into account: a)the TOE physical environment which identifies all aspects of the TOE operating environment relevant to TOE security, including known physical and personnel security arrangements; b)the assets requiring protection by the element of the TOE to which security requirements or policies will apply; this may include assets that are directly referred to, such as files and databases, as well as assets that are indirectly subject to security requirements, such as authorisation credentials and the IT implementation itself; c)the TOE purpose, which would address the product type and the intended usage of the TOE. Investigation ofthe securitypolicies, threats and risks should permitthe following securityspecific statements to be made about the TOE: a)A statement of assumptions which are to be met by the environment of the TOE in order for the TOE to be considered secure. This statement can be accepted as axiomatic for the TOE evaluation. b)A statement of threats to security of the assets would identify all the threats perceived by the security analysis as relevant to the TOE. The CC characterises a threat in terms of a threat agent, a presumed attack method, any vulnerabilities that are the foundation for the attack, and identification of the asset under attack. An assessment of risks to security would qualify each threat with an assessment of the likelihood of such a threat developing into an actual attack, the likelihood of such an attack proving successful, and the consequences of any damage that may result. c)A statement of applicable organisational security policies would identify relevant policies and rules. For an IT system, such policies may be explicitly referenced, whereas for a general purpose IT product or product class, working assumptions about organisational security policy may need to be made. 4.3.2 security objectives The results of the analysis of the security environment could then be used to state the security objectives that counter the identified threats and address identified organisational security policies and assumptions. The security objectives should be consistent with the stated operational aim or product purpose of the TOE, and any knowledge about its physical environment. The intent of determining security objectives is to address all of the security concerns and to declare which security aspects are either addressed directly by the TOE or by its environment. This categorisation is based on a process incorporating engineering judgement, security policy, economic factors and risk acceptance decisions. The security objectives for the environment would be implemented within the IT domain, and by non-technical or procedural means. Only the security objectives for the TOE and its IT environment are addressed by IT security requirements. 4.3.3 it security requirements The IT security requirements are the refinement of the security objectives into a set of security requirements for the TOE and security requirements for the environment which, if met, will ensure that the TOE can meet its security objectives. The CC presents security requirements under the distinct categories of functional requirements and assurance requirements. The functional requirements are levied on those functions of the TOE that are specifically in support of IT security, and define the desired security behaviour. Part 2 defines the CC functional requirements. Examples of functional requirements include requirements for identification, authentication, security audit and non-repudiation of origin. When the TOE contains security functions that are realised by a probabilistic or permutational mechanism (e.g. a password or hash function), the assurance requirements may specify that a minimum strength level consistent with the security objectives is to be claimed. In this case, the level specified will be one of the following SOF-basic, SOF-medium, SOF-high. Each such function will be required to meet that minimum level or at least an optionally defined specific metric. The degree of assurance can be varied for a given set of functional requirements; therefore it is typically expressed in terms of increasing levels of rigour built with assurance components. Part 3 defines the CC assurance requirements and a scale of evaluation assurance levels (EALs) constructed using these components. The assurance requirements are levied on actions of the developer, on evidence produced and on the actions of the evaluator. Examples of assurance requirements include constraints on the rigour of the development process and requirements to search for and analyse the impact of potential security vulnerabilities. Assurance that the security objectives are achieved by the selected security functions is derived from the following two factors: a)confidence in the correctness of the implementation of the security functions, i.e., the assessment whether they are correctly implemented; and b)confidence in the effectiveness of the security functions, i.e., the assessment whether they actually satisfy the stated security objectives. Security requirements generally include both requirements for the presence of desired behaviour and requirements for the absence of undesired behaviour. It is normally possible to demonstrate, by use or testing, the presence of the desired behaviour. It is not always possible to perform a conclusive demonstration of absence of undesired behaviour. Testing, design review, and implementation review contribute significantly to reducing the risk that such undesired behaviour 0 ... 6 7 8 9 10 11 12 ... 20
|
