1. Security Functional Requirements Kashif Imran

2. Overview Common Criteria Protection Profiles Security Objectives Security Requirements Security Functional Requirements

3. Overview

4. PP for Directory for US Department of Defense. Identifies the directory’s basic security requirements. Functional and Assurance requirements. Overview

5. Common Criteria

6. Used as the basis for evaluation of security properties of IT products. Permits comparability between the results of independent security evaluations. Evaluation results may help consumers. Common Criteria

7. Useful for the development of IT products with security functionality. Provides protection from unauthorized disclosure, modification, or loss of use. Common Criteria

8. Protection Profiles

9. PP describes the general requirements for a TOE. Product acquisition guide for IT department. PP is a set of security requirements for desired product or system. Protection Profiles

10. It can be made using the CC. PP consists of mainly 4 parts. –TOE Description. –Security Environment. –Security Objectives. –Security Requirements. Protection Profiles

11. Security Objectives

12. The security objectives are a concise and abstract statement. Provide a high-level, natural language solution of the problem Security objectives is divided into two part wise solutions. –Security objectives for the TOE –Security objectives for the Operational Environment

13. Security objectives for the TOE The TOE provides security functionality to solve a certain part of the problem defined by the security problem definition. Example: The TOE shall keep confidential the content of all files transmitted between it and a Server.

14. Security objectives for the TOE Some of the Security objectives of the TOE are: –O.AuditReview The TOE must provide the means for authorized users to review the audit data in a timely and efficient manner. –O.Availability The TOE must ensure its information is available. –O.Confidentiality The TOE must provide a means to ensure the confidentiality of data when required.

15. Security objectives for the Operational Environment The operational environment of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality. Example: The operational environment shall provide a workstation with the OS Inux version 3.01b to execute the TOE on.

16. Security objectives for the Operational Environment Some of the Security objectives of the Operational Environment are: –OE.AuditLog Administrators and Auditors must ensure that audit facilities are used and managed effectively. –OE.AuthInfo Those responsible for the TOE must ensure that the authentication data for each user account and for the TOE itself is held securely and not disclosed to persons not authorized to use the account. –OE.Operations Those responsible for the TOE must ensure that the TOE and its operating platform are delivered, installed, managed, and operated in a manner which maintains IT security.

17. Security Requirements The Security requirements consists of two groups of requirements: –Security Functional Requirements (SFRs). –Security Assurance Requirements (SARs).

18. Security Assurance Requirements Description of how assurance is to be gained that the TOE meets the SFRs. It describes how the TOE is to be evaluated.

19. Security Functional Requirements These requirements describe the desired security behaviour expected of a Target of Evaluation (TOE). These requirements describe security properties that users can detect by direct interaction Security objectives for the operational environment are not required to be translated.

20. Class Structure

21. Family Structure

22. Component Structure

23. TOE SECURITY FUNCTIONAL REQUIREMENTS

24. Functional Components Class FAU: Audit Class FCO: Communication Class FCS: Cryptographic Support Class FIA: Identification and Authentication Class FMT: Security Management Class FPT: Protection of the TOE Security Functions Class FRU: Resource Utilisation Class FTP: Trusted Path/Channels

25. Class FAU: Audit FAU_ARP.1 Security Audit Automatic Response – Security Alarms FAU_GEN.1 Audit data generation FAU_GEN.2 Audit data generation – User Identify Association FAU_SAA.1 Security Audit Analysis – Potential Violation Analysis FAU_SAR.1 Security Audit Review – Audit Review FAU_SAR.2 Security Audit Review – Restricted Audit Review FAU_SEL.1 Security Audit Event Selection – Selective Audit FAU_STG.2 Security Audit Event Storage – Guarantees of Audit Data Availability FAU_STG.3 Security Audit Event Storage – Action in case of possible audit data loss

26. Class FAU: Audit FAU_ARP.1 Security alarms. Hierarchical to: No other components. FAU_ARP.1.1 The TSF shall report to an authorized role upon detection of a potential security violation. Dependencies: –FAU_SAA.1 Potential violation analysis

27. Class FAU: Audit FAU_GEN.1 Audit data generation Hierarchical to: No other components. FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events. Loss of a secure state Possibly protocol failures Dependencies: FAU_SAA.1 Potential violation analysis

28. Class FAU: Audit FAU_GEN.2 User identity association Hierarchical to: No other components. FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the identity of the user that caused the event. Dependencies: –FAU_GEN.1 Audit data generation –FIA_UID.1 Timing of identification

29. Class FCO: Communication FCO_NRO.1 Selective proof of origin FCO_NRR.1 Selective proof of receipt

30. Class FCO: Communication FCO_NRO.1 Selective proof of origin Hierarchical to: No other components. FCO_NRO.1.1 The TSF shall be able to generate evidence of origin. FCO_NRO.1.2 The TSF shall be able to relate the originator of the information. Dependencies: –FIA_UID.1 Timing of identification

31. Class FCS: Cryptographic Support FCS_CKM.1 Cryptographic Key Generation FCS_CKM.2 Cryptographic Key Distribution FCS_CKM.4 Cryptographic Key Destruction FCS_COP.1 Cryptographic Operation

32. Class FCS: Cryptographic Support FCS_CKM.1 Cryptographic key generation for encrypted communication with remote trusted products. Hierarchical to: –No other components. FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm. Dependencies: –FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation –FCS_CKM.4 Cryptographic key destruction –FMT_MSA.2 Secure security attributes

33. Class FCS: Cryptographic Support FCS_COP.1;1 Cryptographic operation Hierarchical to: –No other components. FCS_COP.1.1 The TSF shall perform in accordance with a specified cryptographic algorithm and cryptographic key sizes. Dependencies: –FDP_ITC.1 Import of user data without security attributes or FCS_CKM.1 Cryptographic key generation. –FCS_CKM.4 Cryptographic key destruction –FMT_MSA.2 Secure security attributes

34. Class FIA: Identification and Authentication FIA_AFL.1 Authentication failure handling FIA_ATD.1 User attribute definition FIA_UAU.2 User authentication before any action FIA_UAU.4 Single -use authentication mechanism FIA_UAU.5 Multiple Authentication mechanisms FIA_UID.2 User identification before any action FIA_USB.1 User-subject binding

35. Class FIA: Identification and Authentication FIA_AFL.1 Authentication failure handling Hierarchical to: –No other components. FIA_AFL.1.1 The TSF shall detect when unsuccessful authentication attempts occur. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall change the user’s identity status to inactive. Dependencies: – FIA_UAU.1 Timing of authentication

36. Class FIA: Identification and Authentication FIA_UAU.4 Single-use authentication mechanisms Hierarchical to: –No other components. FIA_UAU.4.1 The TSF shall prevent reuse of authentication data. Dependencies: –No dependencies

37. Class FMT: Security Management FMT_MOF.1 Management of Security Functions Behavior FMT_MSA.1 Management of security attributes FMT_MSA.2 Secure Security attributes FMT_MSA.3 Static Attribute Initialisation FMT_MTD.1 Management of TSF Data FMT_SMR.2 Restrictions on Security roles

38. Class FMT: Security Management FMT_MOF.1 Management of security functions behaviour. Hierarchical to: –No other components. FMT_MOF.1.1 The TSF shall restrict the ability to modify the behaviour of the functions [FunctionsTable ].FunctionsTable Dependencies: –FMT_SMR.1 Security roles

39. Class FMT: Security Management FMT_MSA.3 Static attribute initialisation. Hierarchical to: –No other components. FMT_MSA.3.1 The TSF shall enforce the default values for security attributes. FMT_MSA.3.2 The TSF shall allow to specify alternative initial values to override the default values when an object or information is created. The initial values may be different depending on the user’s domain. Dependencies: –FMT_MSA.1 Management of security attributes –FMT_SMR.1 Security roles

40. Class FPT: Protection of the TOE Security Functions FPT_AMT.1 Abstract Machine Testing FPT_FLS.1 Failure with preservation of secure state NewEXT_FPT_IIC.11 Inter-TSF Confidentiality of Imported Data NEWEXT_FPT_III.12 Integrity of Imported TSF data - Inter-TSF detection of modification FPT_ITA.1 Inter-TSF availability within a defined availability metric FPT_ITC.1 Inter-TSF Confidentiality of Exported Data

41. Class FPT: Protection of the TOE Security Functions FPT_ITI.1 Inter-TSF detection of modification FPT_RPL.1 Replay detection FPT_RVM.1 Non-bypassability of the TSP FPT_SEP.1 TSF domain separation FPT_STM.1 Reliable time stamps FPT_TDC.1 Inter-TSF basic TSF data consistency FPT_TST.1 TSF testing

42. Class FPT: Protection of the TOE Security Functions FPT_AMT.1 Abstract machine testing Hierarchical to: –No other components. FPT_AMT.1.1 The TSF shall run a suite of tests to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF. Dependencies: –No dependencies

43. Class FPT: Protection of the TOE Security Functions FPT_FLS.1 Failure with preservation of secure state Hierarchical to: –No other components. FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: –failure of an automated audit system. –others to be discussed. Dependencies: –ADV_SPM.1 Informal TOE security policy model

44. Class FRU: Resource Utilisation FRU_RSA.1 Maximum quotas Hierarchical to: –No other components. FRU_RSA.1.1 The TSF shall enforce maximum quotas of the resources: –Resources that user / users can use simultaneously / over a specified period of time. Dependencies: –No dependencies.

45. Class FTP: Trusted path/channels FTP_ITC.1 Inter-TSF trusted channel Hierarchical to: –No other components. FTP_ITC.1.1 The TSF shall provide a communication channel between itself and a remote trusted IT product. - FTP_ITC.1.2 The TSF shall permit to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel. Dependencies: – No dependencies