A Common-Criteria Based
Approach for COTS
Component Selection
Wes J. Lloyd
Colorado State University
Young Researchers Workshop (YRW) 2004
1
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
2
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
3
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
4
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.
5
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
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): 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
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
Assurance Class
ACM: Configuration
Management
ADO: Delivery and Operation
Assurance Components by Evaluation Assurance Level
EAL1
EAL2
EAL3
Functionally
Structurally
Methodically tested and
Tested
Tested
checked
D-1, C-2, E-1
D-3, C-6, E-1
D-4, C-12, E-2
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
ATE: Tests
AVA: Vulnerability
Assessment
Total Activities
D-1, C-2, E-2
D-1, C-1, E-2
D-7, C-23, E-10
40 total
D-4, C-8, E-5
D-5, C-10, E-6
D-3, C-3, E-4
D-4, C-7, E-7
D-18, C-45, E-20
83 total
D-22, C-61, E-27
110 total
D- Developer, C- Document Assessment, E- Evaluator Activities
10
Common Criteria Evaluation Process
11
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?
12
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
13
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
14
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
15
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
16
Common Criteria Based
Selection Process (5)
System High
Level Design
Component
Requirements
Definition:
Create ST
Component
Search
Abort Search – Develop Component
Component
Evaluation
Component
Selection
Integrate and
Operate
Component
17
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
18
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)
19
Process Application Example (2)
 Step 1: Generate an Security Target (ST)
document
Standards: 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.
20
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
21
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
22
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
23
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?
24
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.
25
References
1.
2.
3.
4.
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.
26
Questions / Suggestions
27