A Common-Criteria Based Approach for COTS Component Selection

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)
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. 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, Natl 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