A Common-Criteria Based Process for COTS Component Selection

1. A Common-Criteria Based Process for COTS Component Selection Wes J. Lloyd Spring 2004 CS 681 - Advanced Topics in Computer Security

2. Component Based Software Engineering (CBSE) • GOALS of CBSE • Develop Software Systems by using Commercial Off-The-Shelf (COTS) Components • Components implement portions of the system’s functionality • Reduce System Development Time and Effort • Improve Overall System Quality • CBSE for Developing Secure Systems

3. Component Selection Problem • Best component must be selected from component candidates in order to fulfill system requirements • Existing Selection Processes only poorly consider the evaluation of non-functional requirements. [1] • Security requirements are primarily classified as non-functional requirements. [2] • Problem: Existing CBSE component selection processes do not well address security evaluation

4. Common Criteria (CC) for IT Security Evaluation • Standards Document providing criteria for security specification and evaluation of software systems • The CC provides: • A hierarchically organized set of standard security requirements • A hierarchically organized set of security assurance/evaluation activities • A process for system security evaluation

5. Common Criteria Terms • TOE – Target of evaluation: The system and its related documentation being evaluated • ST – Security Target (document): Document which specifies security requirements. The standard security requirements provided by the CC security classes are used as a basis for writing the ST. • PP – Protection Profile (document): Document which specifies a set of security requirements that apply to a specific type of system, for example: firewalls

6. Common Criteria Security Requirements • Reusable Security Requirements organized in a hierarchical manner • Classes Group of families which focus on specific areas of security • Families Grouping of components sharing security objectives • Components Related sets of security requirements • Component elements Individual Security Requirements

7. Common Criteria Security Classes • Security Audit (FAU) • Communication (FCO)- Identification of parties • Cryptographic Support (FCS) • User Data Protection (FDP) • Identification and Authentication (FIA) • Security Management (FMT) • Privacy (FPR) • Protection of the system security functions (FPT) • Resource Utilization (FRU) • System Access (FTA) • Trusted path/channels (FTP)

8. Evaluation Assurance Levels (EALs) • CC defines (7) EALs • Each subsequent level specifies additional evaluation activities. • Evaluation level is achieved by conducting additional assessment activities with increasing scope, depth, and rigor at each subsequent level • EAL1: Functionally Tested • EAL2: Structurally Tested • EAL3: Methodically Tested and Checked • EAL4: Methodically Designed, Tested, and Reviewed • EAL5: Semi formally designed and tested • EAL6: Semi formally verified, designed, and tested • EAL7: Formally verified, designed, and tested

9. Evaluation Assurance Activities D- Developer, C- Document Assessment, E- Evaluator Activities

10. Common Criteria Evaluation Process

11. Common Criteria for CBSE • CBSE • Using COTS Components • Considering architecture first, product second • Software design considers the system architecture first, then the candidate components • EJB, J2EE, Java, .NET, Corba, DCOM/COM • How can the CC help specify and evaluate security for CBSE?

12. CCComponents Case Study • How can the CC describe security requirements of components? • What is the breadth of security functions provided by COTS components in relation to the CC security classes?

13. CCComponents Case Study (Method) • COTS components implementing security functions were sought • www.componentsource.com • www.google.com • Related Keywords were used to search for components with security functions related to CC security classes • Components evaluated in the study were selected randomly from the result of searches.

14. CCComponents Case Study (Method - 2) • Search Terms • FCS: Cryptography • FAU: log, logging • FDP: access control • FCO: repudiation • FIA: authentication • FPR: anonymity • FPR: pseudonymity • FTA: access limits, connection limits • FTP: secure socket, secure channel, trusted channel, trusted socket • FMT/FPT: system security, system security management • FRU: utilization, resource utilization

15. Volter’s Component Types • Used to help classify COTS components for evaluation in the case study • Logical components: • Based on the Model-View-Control aggregate design pattern • Domain (controller) • Data (model) • User (view)

16. Volter’s Component Types (2) • Technical components: • Act as containers (frameworks) that provide a runtime environment for logical components to operate • Scope of technical components varies • Application Level: • J2EE, EJB, Java, .NET, CORBA, COM/DCOM • Domain Level: • Struts Web Application Framework • DataObjects .NET Framework

17. Case Study Results • Forty-two COTS components with security functions were identified • One package included 18 SSL-based secure socket components bundled together as a library of components • All other components were sold separately • Components Evaluated: Domain: 16, Data: 5, User: 1, Technical: 2 • By observation the ordinal ranking, not the ratios may be suggestive of the occurrence of CC security requirements in COTS components

18. Case Study Results (2) • On average each COTS component implemented security requirements from (2) CC security classes (~2.167) • COTS components were found which claimed support of 8 of the 11 security classes. • Security Requirements from (3) CC Classes were not directly identified, but could be inferred: Privacy (FPR), Protection of the system’s security system (FPT), and system access (FTA)

19. Case Study Results (3) • CC security classes found • 50% of COTS components claimed to provide cryptography functions • 38% of COTS components claimed to provide User Authentication and Identification functions • 38% of COTS components claimed to implement Access Control functions • 33% of COTS components claimed to provide security auditing functions through logging, analysis, etc.

20. Case Study Results (4)

21. Common Criteria Based Selection Process • Step 0: System High Level Design • Specify Component Architecture • Consider evaluation of component architectures/frameworks based on security requirements • Step 1: Component Requirements Definition • Generate a Security Target (ST) document to elicit security requirements for the desired COTS component • Use CC Security Requirements

22. Common Criteria Based Selection Process (2) • Step 2: Component Search • Conduct search by comparing primary requirements against product brochures, features lists, and documentation. • If no components are found: • ST could be revised to have less stringent security requirements • Abandon Search, Develop Component from scratch

23. Common Criteria Based Selection Process (3) • Step 3: Component Evaluation • Perform full or partial EAL Level 1 evaluation on the candidate components • Partial evaluation can reduce time/cost • Suggested order of activities to rapidly eliminate candidates: • ADV_FSP: Functional Specification and documentation evaluation • ADV_RCR Evaluation of the representation correspondence to functional requirements • ATE_IND independent testing • AGD_ADM Administrator Guidance • AGD_USR User Guidance • ACM_CAP CM Capabilities • ADO_IGS Installation, generation, and start-up

24. Common Criteria Based Selection Process (4) • Step 3: Component Evaluation… • Halt evaluation activities once only one appropriate component remains • If multiple candidates exist after EAL Level 1 evaluation • Revise ST to include more rigorous security requirements -OR- • Perform EAL Level 2 evaluation • Repeat process until an appropriate component is identified • Step 4: Component Selection • Step 5: Component Operation

25. Component Requirements Definition: Create ST System High Level Design Component Search Abort Search – Develop Component Component Evaluation Component Selection Integrate and Operate Component Common Criteria Based Selection Process (5)

26. Process Application Example • Step 0: • The high level design specifies Java as the language of implementation. • The component based system will consist of distributed client nodes which communicate with each other over an open network channel. • Encryption must be used to protect data. • The component must provide an implementation to the Java Encryption Extension (JCE)

27. Process Application Example (2) • Step 1: Generate an ST document

28. Process Application Example (3) • Step 2: A search initally identifies (4) candidate components: • RSA Bsafe • IAIK-JCE • Is Networks Provider • Logi.crypto • Step 3: A partial EAL level 1 assessment evaluates the (4) candidate components eliminating those which fail to provide security functions as specified by the ST. • As needed the ST can be adjusted after first assessment cycle, or a full EAL level 1 could be conducted

29. Process Application Example (4) • Step 4: The best component which meets security requirements as specified in the ST is selected • Step 5: The component is integrated for use in the component-based system

30. Future Work • Develop Subtypes of Volter Component Types identifying various domains of COTS components • Uses subtypes to develop Protection Profiles for COTS Components • Consider enhancing the selection process through the use of decision making techniques such as the weighted sum metric (WSM) and the Analytic Hierarchy Process (AHP) in step 2 • Conduct case study applications of the selection process to evaluate its effectiveness and practicality. • Based on lessons learned identify and make process improvements

31. References • Ruhe, G., Intelligent Support for Selection of COTS Products, in Proceedings of the Net.Object Days 2002, Erfurt, Springer, 2003, pp. 34-45. • Franz, E., Pohl, C., Towards Unified Treatment of Security and Other Non-Functional Properties, In proceedings of the 2004 AOSD Technology for Application-Level Security Workshop, AOSD 2004, Lancaster, UK, 2004. • ISO/IEC-15408 (1999) Common Criteria for Information Technology Security Evaluation, v 2.1, Nat’l Inst. Standards and Technology, Washington, DC, August 1999, http://csrc.nist.gov/cc • Han, J., Zheng, Y., Security Characterization and Integrity Assurance for Component-Based Software, in proceedings of the international conference on Software Methods and Tools (SMT 2000), Wollongong, NSW Australia, pp. 61-66, 2000.

32. Questions / Suggestions