1. 1 A Disciplined Security Specification for a High- Assurance Grid by Ning Zhu, Jussipekka Leiwo, and Stephen John Turner Parallel Computing Centre Distributed Parallel and Distributed Computing Center, School of Computer Engineering, Nanyang Technological University, Singapore 639798

2. 2 0. Outline Introduction Background & Methodology A Common Criteria Compliant Generic Security Framework for the Grid Security Environment and Objectives for the Grid Security Requirements for the Grid Conclusions and Future Work

3. 3 1. Introduction Grid Computing Overview Grid is a hardware and software infrastructure that provides dependable, consistent, pervasive and inexpensive access to heterogeneous high-end computing capabilities, knowledge bases and services. It aims to provide flexible, secure, coordinated resource sharing and problem solving among dynamic distributed collections of individuals, institutions, and resources. Security=Functionality + Assurance

4. 4 1. Introduction Problems of Current Grid Security Solutions GSI, UNICORE, CAS, PERMIS Inadequate functionality Non-systematic implementation without considering security assurance Our work A disciplined security specification toward a generic security framework for the Grid Follow the generic framework to implement highly assured trustworthy Grid security solution

5. 5 2. Background & Methodology Security Assurance Security can not be considered appropriate even if the security techniques used are known to be theoretically highly resistant to attacks. The extent of trustworthiness, the means of providing evidence of the appropriateness of security designs and for demonstrating that implementations meet the security objectives, must be considered.

6. 6 2. Background & Methodology Assurance Methods Assessment of the TOE (Target of Evaluation) directly Assessment of the processes to develop the TOE Assessment of the environment where the TOE is developed ISO/IEC 15408, the Common Criteria An internationally recognized standard for specifying and evaluating security properties of IT products and systems Comparison with process assurance methods and environment assurance methods

7. 7 2. Background & Methodology ClearingHouse Project A typical Grid platform providing a generic Grid-based application execution and information sharing engine Resource management, automatic resource discovery, and economy management of resources in a service-oriented environment are main issues addressed by ClearingHouse currently

8. 8 3. A Common Criteria Compliant Generic Security Framework for the Grid Systematically devised and highly assured based on the Common Criteria Specific Grid security solutions are instantiated from the framework in a manner that preserves all dependencies between design artifacts and brings assurance that all relevant TOE and environmental elements are considered

9. 9 4. Security Environment and Objectives for the Grid Security environment: It describes the security aspects of the environment in which the TOE is intended to be used and the manner in which it is expected to be employed. Security objectives: They reflect the stated intent to counter identified threats and/or comply with any organizational security policies and usage assumptions.

10. 10 4.1 Security Environment for the Grid Assets to be protected Subjects within the set of interactions occurring with or within the TOE that causes operations to be performed Assumptions that cannot be enforced by technical means to be met by the environment in order for the TOE to be considered secure Organizational security policies Threats to security:

11. 11 4.1 Security Environment for the Grid T.Hack_PhysAttackers interact with the TOE to exploit vulnerabilities in the physical environment. T.RED_InsecureAn attacker operates on AST.RED of the TOE without authorization. T.USD_InsecureSimilar to T.RED_Insecure but on AST.USD. T.USD_ForgeryAn attacker forges valid user identity, role/attributes, and/or usage quota. T.JOD_InsecureSimilar to T.RED_Insecure, but on AST.JOD. T.USD_JOD_CheatAn attacker forges a TOE interface to defraud the user of his useful AST.USD and AST.JOD. T.INR_MisuseAn attacker operates on the information resources without required privileges. T.CPR_MisuseAn attacker runs his programs on the computing resources without authorization. T.INR_CPR_UnsecuredAn attacker personates one trusted by the TOE and contributes insecure, potentially dangerous, and/or intrusive information/computing resource to the Grid. T.AUD_InsecureAttackers steal audit information of the TOE and even modify or delete the log file.

12. 12 4.2 Security Objectives for the Grid Security objectives for the TOE: OT.Auth_TOEThe TOE should enable the user to trust it as the true TOE he wants to access. OT.AccessControlThe TOE can only be used by properly authenticated and authorized users, and the access control routine is non-bypassible. OT.RED_SecureResource data should be protected and only operated by authorized TOE users. OT.USD_SecureSensitive user data is confidential and tamperproof, and has integrity in the TOE. OT.JOD_SecureJob data can only be accessed by appropriately authorized users of the TOE. OT.INR_CPR_SecureThe information/computing resource can only be operated by authorized users. OT.INR_CPR_TrustedThe TOE only contains trusted, secure, and available resources. OT.AUD_SecureAudit data of the TOE can only be read and utilized by an authorized user. OT.TOE_SecureThe security and administrative mechanisms of the TOE are protected securely. OT.Lifecycle_SecurityThe TOE shall detect flaws during the initialization, personalization and operational usage.

13. 13 4.2 Security Objectives for the Grid Security objectives for the IT-environment of the TOE Security objectives rationale Demonstrating that the security objectives address all of the environmental aspects identified and the objectives are effective and provide complete coverage Security environment to security objectives mapping for generating tracings:

14. 14 4.2 Security Objectives for the Grid Threats-Assumptions-Policies/ Security Objectives OT.Auth_TOE OT.AccessControl OT.RED_SecureOT.USD_Secure OT.JOD_Secure OT.INR_CPR_Secure OT.INR_CPR_Trust ed OT.AUD_Secure OT.TOE_Secure OT.Lifecycle_Security OE.SecureComm OE.USD_Protect OE.Stand ardFormats T.Hack_Phys X X X X X T.RED_Insecure X X T.USD_Insecure X X T.USD_Forgery X X X X T.JOD_Insecure X X T.USD_JOD_Cheat X T.INR_Misuse X X T.CPR_Misuse X X T.INR_CPR_Unsecured X X X T.AUD_Insecure X X A.SecureKey X X P.LocalSecureRe X X P.CredStandards X X P.HWSecurity X X

15. 15 5. Security Requirements for the Grid Security requirements are the refinement of the security objectives and if met, will ensure that the TOE can meet its security objectives. Security functional requirements are levied on those functions of the TOE that are specifically in support of IT security and define the desired security behavior. Security assurance requirements specify a minimum strength level consistent with the security objectives.

16. 16 5.1 Security Functional Requirements for the Grid A systematically drawn set of Grid security functional requirements conforming to the Common Criteria: FAU (Security Audit) FDP (User Data Protection) FIA (Identification and Authentication) FMT (Security Management) FPR (Privacy) FPT (Protection of the TSF) FTA (TOE Access)

17. 17 5.1 Security Functional Requirements for the Grid Each class consists of class introduction and functional families. Functional components plus family behavior, component leveling, management requirements and audit requirements constitute a family specification. Each component specification includes functional elements and the dependencies among functional components.

18. 18 5.1 Security Functional Requirements for the Grid A sample security functional requirement: User Data Protection: This class specifies requirements for TOE security functions and TOE security function policies related to protecting user data. It includes six families: Access control policy (FDP_ACC), Access control functions (FDP_ACF), Data authentication (FDP_DAU), Import from outside TSF control (FDP_ITC), Residual information protection (FDP_RIP), and Stored data integrity (FDP_SDI). FDP_ACC identifies the access control SFPs and defines the scope of control of the policies that form the identified access control portion of the TSP. This family has only one component FDP_ACC.1 Subset access control. No management activities or auditable events are foreseen.

19. 19 5.1 Security Functional Requirements for the Grid FDP_ACC.1 has only one element FDP_ACC.1.1: The TSF shall enforce the [assignment: access control SFP] on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]. It has the dependency on FDP_ACF.1 Security attribute based access control.

20. 20 5.1 Security Functional Requirements for the Grid We may make further operations on the security functional requirements including assignment, selection, refinement and iteration, to address different aspects of the security needs of the TOE in more detail. Security requirements for the IT environment of the TOE can also be defined such as those for communication, cryptographic support, resource utilization and trusted path/channels.

21. 21 5.2 Security Assurance Requirements for the Grid Security assurance requirements are expressed as evaluation assurance levels (EALs). EAL 2 - structurally tested, EAL 3 - methodically tested and checked, and EAL 4 - methodically designed, tested, and reviewed can be adopted as a basis to guide implementing and evaluating assurance of a Grid system/application.

22. 22 5.3 Security Requirements Rationale Demonstrating that the security requirements are suitable to meet and traceable to the IT security objectives Mapping table can still be utilized to help express the rationale intuitively and clearly:

23. 23 5.3 Security Requirements Rationale Security Functional Requirements/ Security Objectives OT.Auth_TOE OT.AccessControl OT.RED_SecureOT.USD_Secure OT.JOD_Secure OT.INR_CPR_Secure OT.INR_CPR_Trusted OT.AUD_Secure OT.TOE_Secure OT.Lifecycle_Security …………………………… FDP_ACCXXXXXXXX FDP_ACFXXXXXXXXX FDP_DAUX FDP_ITCXX FDP_RIPXX FDP_SDIX ……………………………

24. 24 5.3 Security Requirements Rationale Different subsets of the security functional requirements can be defined and tailored for different strengths of the security functionality. Different original or augmented EALs can also be imposed to ensure the achievement of such different level security respectively. Thus more flexible trustworthy Grid security solutions will be provided following the generic Grid security framework, to fulfill their specific security objectives correctly and effectively.

25. 25 6. Conclusions and Future Work A disciplined approach to specify and model security for the high-assurance Grids A TOE summary specification to provide a high-level definition of the security functions and assurance measures Accomplish a specific TOE implementation for Grid security

26. 26 Thanks!