1

A Common-Criteria Based Approach for COTS Component Selection

Wes J. Lloyd

Colorado State UniversityYoung 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

• FamiliesGrouping of components sharing security objectives

– ComponentsRelated sets of security requirements

• Component elementsIndividual 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 ActivitiesAssurance Components by Evaluation Assurance Level Assurance Class

EAL1 Functionally

Tested

EAL2 Structurally

Tested

EAL3 Methodically tested and

checked ACM: Configuration Management

D-1, C-2, E-1 D-3, C-6, E-1 D-4, C-12, E-2

ADO: Delivery and Operation D-1, C-1, E-2 D-3, C-2 E-3 D-3, C-2, E-3

ADV: Development D-2, C-5, E-3 D-3, C-12, E-5 D-3, C-14, E-5

AGD: Guidance Documents D-2, C-14, E-2 D-2, C-14, E-2 D-2, C-14, E-2

ALC: Lifecycle Support D-1, C-2, E-2

ATE: Tests D-1, C-1, E-2 D-4, C-8, E-5 D-5, C-10, E-6

AVA: Vulnerability Assessment

D-3, C-3, E-4 D-4, C-7, E-7

Total Activities D-7, C-23, E-10 40 total

D-18, C-45, E-20 83 total

D-22, C-61, E-27 110 total

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)

documentStandards: PKCS #1- v2.1 RSA Encryption Std., FIPS std. Pub 140-2 – Computer Security – Cryptography – May 25, 2001

FCS_CKM _1.1. Cryptographic key generation

Key Generation algorithm: RSA Asymmetric key generation Cryptographic key size: 1024-bit

FCS-CKM_2.1. Cryptographic key distribution Distribution method: A central authentication server provides public keys to clients as needed FCS-CKM_3.1. Cryptographic key access Cryptographic key archival on the local file storage media of the central key distribution server is used. FCS_CKM_4.1. Cryptographic key destruction Public keys expire after a specified period of inactivity. When a user attempts access with an expired key they will need to request a new key from the central key distribution server. FCS_COP.1.1. Cryptographic Operation Data encryption and decryption operations must be supported. Digital signature generation and verification must be supported.

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. 34-45.

2. 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.

3. 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

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. 61-66, 2000.

27

Questions / Suggestions