1 / 45

Security Functional Requirements

Security Functional Requirements. Kashif Imran. Overview Common Criteria Protection Profiles Security Objectives Security Requirements Security Functional Requirements. Overview. Overview. PP for Directory for US Department of Defense.

owen
Download Presentation

Security Functional Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Functional Requirements Kashif Imran

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

  3. Overview

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

  5. Common Criteria

  6. Common Criteria • 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 .

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

  8. Protection Profiles

  9. Protection Profiles • 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.

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

  11. Security Objectives

  12. Security Objectives • 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]. • 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

More Related