1 A Common-Criteria Based Approach for COTS Component Selection Wes J. Lloyd Colorado State University Young Researchers Workshop (YRW) 2004

2 Component-Based Software Development  Component Based Software Development (CBSD) –Develop software by integrating existing (COTS) Components to implement functional requirements of the system being developed  Components vs. Components off the shelf (COTS)  CBSD Promises: –High Quality, Feature Rich Software –Reduced System Development Time –Lower Development Costs

3 CBSD Challenges  Components sometimes do not –Meet Basic System Requirements –Meet Future System Requirements  Poor selection of components can decrease: –System Maintainability –System Reliability –System Security

4 Need for Component Security  Government and Commercial Software Developers are motivated to use CBSD techniques –Develop and deliver software faster –Use security functions provided by preexisting components and frameworks  Problem –Secure Components are desired –Must ensure integrity and confidentiality of data exposed to components

5 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 only loosely specify how to evaluation security of components.

6 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

7 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

8 Common Criteria Security Classes  Security Audit (FAU): Logging  Communication (FCO): Identification of parties, repudiation  Cryptographic Support (FCS): Cryptography  User Data Protection (FDP): Access control  Identification and Authentication (FIA)  Security Management (FMT): System security & mgmt.  Privacy (FPR): Anonymity, psuedonymity  Protection of the system security functions (FPT)  Resource Utilization (FRU): Utilization limitations  System Access (FTA): Access/connection limits  Trusted path/channels (FTP): Secure channels, sockets

9 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

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

11 Common Criteria Evaluation Process

12 Component Security  Research Goal –Determine if the Common Criteria for IT systems can be applied to define security requirements and evaluate security attributes of (COTS) components for use in component based systems? –Does such an approach aid component selection, component security specification and evaluation?

13 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

14 Common Criteria Based Selection Process (2)  Step 2: Component Search –Conduct search by identifying claims of support for identified requirements (security and general requirements) in 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

15 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

16 Common Criteria Based Selection Process (4)  Step 3: Component Evaluation… –Halt evaluation activities when 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

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

18 Process Application Example  Consider a component based system –CBS needs to provide data encryption service  An off-the-shelf component to provide data encryption service is desired

19 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)

20 Process Application Example (2)  Step 1: Generate an Security Target (ST) document

21 Process Application Example (3)  Step 2: A search initially 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

22 Process Application Example (4)  In this basic example all of the candidate components met initial security requirements defined in the ST.  Enhancing the requirements was required to eliminate candidate components

23 Future Work  CHALLENGE: An Empirical evaluation of software development processes is very difficult –Consider complexities of scientifically evaluating various software processes: The Waterfall Model The Spiral Model eXtreme Programming  Conduct an exploratory investigation applying the CC-based selection process to investigate research questions –Identify Specific areas to narrow research –Identify opportunities for science

24 Future Work  Exploratory Investigation – Research Questions –Does the CC-based selection process provide advantages over existing processes or ad hoc approaches for COTS Selection, COTS Security Specification, and COTS Security Evaluation? –What difficulties are encountered: specifying security requirements, evaluating component security? –Which evaluation activities provide the least/most information regarding COTS functionality? Which are time consuming? –What effort is required to train developers on the use of the process? Which parts of the process are difficult to understand and apply?

25 Future Work  Integrate enhancements to the selection process based on lessons learned from exploratory investigations  Consider enhancements to the selection process by introducing the use of formal decision making techniques such as the weighted sum metric (WSM) and the Analytic Hierarchy Process (AHP)  Develop Protection Profiles (PPs) for common COTS Components –PPs are reusable sets of CC security requirements for common systems. –PPs are already used to define common sets of security requirements for systems.

26 References 1. Ruhe, G., Intelligent Support for Selection of COTS Products, in Proceedings of the Net.Object Days 2002, Erfurt, Springer, 2003, pp 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, ISO/IEC (1999) Common Criteria for Information Technology Security Evaluation, v 2.1, Nat’l Inst. Standards and Technology, Washington, DC, August 1999, 4. 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 , 2000.

27 Questions / Suggestions