Presentation is loading. Please wait.

Presentation is loading. Please wait.

© Crown Copyright (2000) Module 2.1 Security Requirements.

Similar presentations

Presentation on theme: "© Crown Copyright (2000) Module 2.1 Security Requirements."— Presentation transcript:

1 © Crown Copyright (2000) Module 2.1 Security Requirements

2 You Are Here M2.1 Security Requirements M2.2 Development Representations M2.3 Functional Testing M2.4 Development Environment M2.5 Operational Environment M2.6 Vulnerability Analysis M2.7 Penetration Testing M2.8 Assurance Maintenance/Composition MODULE 2 - ASSURANCE

3 Introduction Security Target –defines scope of security problem –specifies security functions –identifies assurance requirement Security Policy Model –required at higher assurance levels

4 Define the Security Problem Assets –what are the protection needs? Threats –asset at risk –threat agent –method of attack Other constraints on the TOE

5 Scope the Security Problem TOE boundary and interfaces –data in/out –links to underlying systems Identify what is assumed: –IT dependencies, e.g. underlying O/S –connectivity to other systems –non-technical aspects (personnel, procedural, physical)

6 Specifying Countermeasures Security Functions, e.g. –Access Control –Identification & Authentication –Audit Non-IT countermeasures, e.g. –physical protection –procedural measures

7 Identifying the Assurance Requirement What assurance is needed to reduce residual risk to assets to acceptable level? –asset value –threats and risk to assets –balance between IT and non-IT What practical constraints apply?

8 Suitability Countermeasures mapped to threats –all threats covered –no redundant countermeasures Rationale or analysis demonstrating that the specified countermeasures will counter the threats

9 Specification Styles Informal –English Semi-formal –restricted notation, e.g. SSADM Formal –mathematical concepts, e.g. Z

10 Example Informal Specification The TOE will prevent read access by a subject in respect of an object whose label is not dominated by the label of the subject.

11 Example Semi-formal Specification A subject is permitted to read an object only if: a) the hierarchical part of the subject label is greater than or equal to that of the object label and b) the categories within the object label form a subset of the categories within the subject label.

12 Example Formal Specification L1, L2 : class L1 dominates L2 security-level (L1) security-level (L2) categories (L2) categories (L1) The Security Function is defined by introducing the function canread: sub canread obj max-level(sub) dominates level(obj)

13 Security Policy Models Provides a precise and abstract definition of the security policies Defines the policy rules and characteristics Not all security policies can be modelled

14 Evaluation Reporting Confirm required content is provided Confirm specifications exhibit required characteristics Confirm absence of ambiguities, inconsistencies, and justify search Confirm suitability of countermeasures to address the security problem

15 ITSEC Requirements

16 ITSEC Security Target Objectives Assumptions Threats SEFs ITSEC ST Suitability Analysis

17 CC Requirements

18 Protection Profile SECURITY ENVIRONMENT SECURITY OBJECTIVES SECURITY REQUIREMENTS Threats Organisational Security Policies Assumptions TOE Security Objectives Environment Security Objectives FunctionalAssurance IT Environment Rationale

19 CC Security Target SECURITY REQUIREMENTS FunctionalAssurance IT Environment TOE SUMMARY SPECIFICATION IT Security Functions Assurance Measures SECURITY ENVIRONMENT SECURITY OBJECTIVES Rationale

20 CC Part 2 Organisation Class –e.g. FAU Security audit Family –e.g FAU_GEN Security audit data generation Component –e.g. FAU_GEN.1 Audit data generation Element –e.g. FAU_GEN.1.1

21 CC Functional Components - 1 Assignment and selection, e.g. FAU_SAR.3.1 The TSF shall provide the ability to perform [selection: searches, sorting, ordering] of audit data based on [assignment: criteria with logical relations]. Refinement, e.g. FMT_MTD.3.1 The TSF shall ensure that only secure values are accepted for TSF data. Refinement: the TSF shall ensure that the minimum password length enforced by the TOE is configured to a value of at least 6 characters.

22 CC Functional Components - 2 Iteration, e.g. FMT_MTD.1.1;1 The TSF shall restrict the ability to create, delete, and clear the audit trail to authorised administrators. FMT_MTD.1.1;2 The TSF shall restrict the ability to modify or observe the set of audited events to authorised administrators. FMT_MTD.1.1;3 The TSF shall restrict the ability to initialize the authentication data to authorised administrators.

23 CC Functional Components - 3 Dependencies, e.g. –FAU_GEN.1 (Audit data generation) depends on –FPT_STM.1 (Reliable timestamps) Mutual support –bypass and tampering attacks –absence of conflict

24 Summary The Security Target provides: –a precise definition of the security problem –a formal statement of the scope of evaluation –a specification of the TOEs security functions, to solve the security problem –the baseline for the evaluation of the TOE Security Policy Models provide additional clarification of notion of TOE security

25 Further Reading ITSEC evaluation ITSEC Section 2 UKSP 05 Part III, Chapters 3-4 CC evaluation CC Part 1, Annexes B & C CEM Part 2, Chapters 3 and 4 CC Part 3, Section 10.7 and CEM Part 2, Chapter 8 (ADV_SPM section)

26 Ideas for Exercise - 1 For a simple example TOE, identify the content of its security target in terms of: –assets to be protected –threats –environmental assumptions –security functions.

27 Ideas for Exercise - 2 Perform a high-level evaluation of an existing security target. Read through the security target and identify where the key aspects are defined: –threats –environmental assumptions –security functions –assurance requirement

Download ppt "© Crown Copyright (2000) Module 2.1 Security Requirements."

Similar presentations

Ads by Google