SECURITY FUNCTIONAL REQUIREMENTS ANALYSIS FOR DEVELOPING

SECURE SOFTWARE

by

Dan Wu

A Dissertation Presented to the

FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF PHILOSOPHY
(COMPUTER SCIENCE)

May 2007

Copyright 2007

Dan Wu

UMI Number: 3262759

UMI Microform 3262759

Copyright 2007 by ProQuest Information and Learning Company.
All rights reserved. This microform edition is protected against
unauthorized copying under Title 17, United States Code.

ProQuest Information and Learning Company

300 North Zeeb Road
P.O. Box 1346
Ann Arbor, MI 48106-1346

Dedication
To my grandmother, my parents and Jia, thanks for their support and love.

ii

Acknowledgements
This dissertation could not have been finished without many peoples support and
help. The person I am mostly appreciated for is my advisor: Dr. Barry Boehm. How
lucky I am to be his student and work with him for almost 4 years. I cannot achieve
todays goal without his consistent guidance, encouragement and support on every
aspect of my student life. I also sincerely thank my other committee members: Dr.
Neno Medvidovic and Dr. Bert Steece, for the great guidance and feedbacks on my
research, presentations and drafts of dissertation.
I want to give my special thanks to Ed Colbert, who provides me many useful
feedbacks on this research. I felt very happy working with him and learned many
things from him. I would also thank for Dr George Freidman and Dr Rick Selby,
who gave me many suggestions on how to extend my research and future research
areas.
I want to thank for my family for the unconditionally love and support. I wont be
achieving todays success without his inspiration in my childhood. He is always the
greatest person in my life. My mother, even did not spend much time with me, still
gave me the best love and care in the world. My lovely younger sister, I will be
always loving you and taking care of you.
I really want to share all my success with my grandmother. I feel so sad I could not
be with her in her last few days. Grandmother and aunt Nan, I wish you could feel all
the happiness I feel now, and be very peaceful in the heaven.

iii

Table of Contents
Dedication ....................................................................................................................ii
Acknowledgements .....................................................................................................iii
Table of Contents ........................................................................................................iv
List of Tables ..............................................................................................................vi
List of Figures .............................................................................................................ix
Abbreviations ............................................................................................................... x
Abstract .......................................................................................................................xi
Chapter 1: Introduction ................................................................................................ 1
Chapter 2: Background and Related Work .................................................................. 6
2.1 Security Objectives Taxonomy .......................................................................... 6
2.2 Security Considerations in SDLC ...................................................................... 9
2.2.1 NIST Special Publications........................................................................... 9
2.2.2 MBASE Security Extensions..................................................................... 11
2.2.3 SSE-CMM & IA-CMM............................................................................. 13
2.3 Security Evaluation Criteria ............................................................................. 13
2.3.1 Trusted Computer Systems Evaluation Criteria ........................................ 14
2.3.2 Information Technology Security Evaluation Criteria .............................. 16
2.3.3 Common Criteria ....................................................................................... 17
2.4 Software Pattern and Security Pattern.............................................................. 26
Chapter 3: Research Approach .................................................................................. 32
Chapter 4: Data Context and General Observations .................................................. 34
4.1 SFR Classes Usage........................................................................................... 35
4.2 SFR & EAL: General Trends ........................................................................... 37
4.3 Observations on Security Projects Through Timeline ..................................... 40
Chapter 5: Security Target Analysis Result ............................................................... 44
5.1 SFR Reusable Packages ................................................................................... 45
5.1.1 Identification and Authentication .............................................................. 45
5.1.2 Confidentiality ........................................................................................... 47
5.1.3 Integrity...................................................................................................... 50
5.1.4 Availability ................................................................................................ 51
5.1.5 Non-Repudiation........................................................................................ 53
5.1.6 Security Management ................................................................................ 54
5.1.7 Privacy ....................................................................................................... 56
5.1.8 Accountability............................................................................................ 57
iv

5.1.9 Recoverability............................................................................................ 57
5.1.10 Intrusion Detection and Response ........................................................... 58
5.1.11 SFRs Correlations.................................................................................... 60
5.2 SFR Patterns in Domains ................................................................................. 69
5.2.1 Access Control Devices and Systems (ACDS) ......................................... 69
5.2.2 Boundary Protection Devices and Systems (BPDS) ................................. 70
5.2.3 Database (DB) ........................................................................................... 74
5.2.4 Data Protection (DP).................................................................................. 76
5.2.5 Detection Devices (DD) ............................................................................ 78
5.2.6 ICs, Smart Cards & Related Services (ICSCRS)....................................... 80
5.2.7 Key Management (KM)............................................................................. 83
5.2.8 Network and Network Related Devices and Systems (NNRDS) .............. 85
5.2.9 Operating Systems (OS) ............................................................................ 89
Chapter 6: Validation Approach ................................................................................ 93
6.1 SFR Packages Validation ................................................................................. 93
6.2 SFR Patterns Validation ................................................................................... 94
6.2.1 SFR Pattern Validation Result in BPDS Domain...................................... 96
6.2.2 SFR Pattern Validation Result in ICSCRS Domain .................................. 97
6.2.3 SFR Pattern Validation Result in NNRDS Domain .................................. 98
6.2.4 SFR Pattern Validation Result in OS Domain......................................... 100
6.2.5 SFR Pattern Validation in Other Domains .............................................. 101
Chapter 7: Contributions and Future Work.............................................................. 104
7.1 Contributions .................................................................................................. 104
7.2 Future Work ................................................................................................... 105
References ................................................................................................................ 107
Appendices............................................................................................................... 111
SFR abbreviations and full names........................................................................ 111

List of Tables
Table 1: MBASE Completion Criteria for Anchor Points ......................................... 12
Table 2: Security Classes in Orange Book................................................................. 15
Table 3: ITSEC Levels Mapping with OB Levels ..................................................... 17
Table 4: Mapping Between SFR and Security Objectives......................................... 20
Table 5: Contents of ST Sections............................................................................... 26
Table 6: Element Content of SFR Pattern.................................................................. 27
Table 7: Advantages and Disvantages of Pattern Exploring Approach..................... 31
Table 8: Summaries of Security Products in Different Domains............................... 34
Table 9: Average EAL & Number of SFRs ............................................................... 41
Table 10: Number of Security Products with Certain SO.......................................... 42
Table 11: Percentages of Security Products with Certain SO.................................... 42
Table 12: Average Number of SFRs for Achieving SO ............................................ 43
Table 13: SFR Packages for Identification and Authentication................................. 45
Table 14: SFR Packages for Access Control ............................................................. 48
Table 15: SFR Packages for Encryption .................................................................... 49
Table 16: SFR Packages fr Integrity .......................................................................... 51
Table 17: SFR Packages for Non-Repudiation (Part 1) ............................................. 54
Table 18: SFR Packages for Non-Repudiation (Part 2) ............................................. 54
Table 19: SFR Packages for Accountability .............................................................. 57
Table 20: SFR Packages for Recoverability .............................................................. 58
Table 21: SFR Packages for Intrusion Detection and Response................................ 59
vi

Table 22: Correlations Among SFR Classes.............................................................. 61

Table 23: Correlations Among Security Objectives .................................................. 65
Table 24: Correlations Among Security Objectives in BPDS ................................... 67
Table 25: Correlations Among Security Objectives in ICSCRS ............................... 67
Table 26: Correlations Among Security Objectives in NNRDS................................ 68
Table 27: Correlations Among Security Objectives in OS ........................................ 68
Table 28: Security Objectives in ACDS .................................................................... 69
Table 29: SFR Patterns for Primary Security Objectives in ACDS........................... 69
Table 30: Security Objectives in BPDS ..................................................................... 71
Table 31: SFR Patterns for Primary Security Objectives in BPDS ........................... 72
Table 32: Security Objectives in DB ......................................................................... 74
Table 33: SFR Patterns for Primary Security Objectives in DB................................ 74
Table 34: Security Objectives in DP.......................................................................... 76
Table 35: SFR Patterns for Primary Security Objectives in DP ................................ 77
Table 36: Security Objectives in DD ......................................................................... 78
Table 37: SFR Patterns for Primary Security Objectives in DD................................ 79
Table 38: Security Objectives in ICSCRS ................................................................. 80
Table 39: SFR Patterns for Primary Security Objectives in ICSCRS........................ 81
Table 40: Security Objectives in KM ........................................................................ 83
Table 41: SFR Patterns for Primary Security Objectives in KM ............................... 84
Table 42: Security Objectives in NNRDS ................................................................. 86
Table 43: SFR Patterns for Primary Security Objectives in NNRDS........................ 86
vii

Table 44: Security Objectives in OS.......................................................................... 89

Table 45: SFR Patterns for Primary Security Objectives in OS ................................ 90
Table 46: Number of Total SFRs for Supporting Security Objectives ...................... 95
Table 47: Effectivness of Security Patterns in BPDS ................................................ 96
Table 48: Range of Effectiveness of BPDS Security Pattern .................................... 97
Table 49: Effectivness of Security Patterns in ICSCRS ............................................ 97
Table 50: Range of Effectiveness of ICSCRS Security Pattern................................. 98
Table 51: Effectiveness of Security Patterns for Two SOs........................................ 98
Table 52: Effectiveness of Security Patterns in NNRDS........................................... 99
Table 53: Range of Effectiveness of NNRDS Security Pattern................................. 99
Table 54: Effectivness of Security Patterns in OS ................................................... 100
Table 55: Range of Effectiveness of OS Security Pattern ....................................... 100
Table 56: Effectivness of Security Patterns in AC .................................................. 101
Table 57: Effectivness of Security Patterns in DB .................................................. 101
Table 58: Effectivness of Security Patterns in DP ................................................... 101
Table 59: Effectivness of Security Patterns in DD .................................................. 102
Table 60: Effectiveness of Security Patterns in KM................................................ 102

viii

List of Figures
Figure 1: NIST Work Breakdown Structure .............................................................. 10
Figure 2: Structure of PP & ST Document ................................................................ 18
Figure 3: Organization and Construction of Requirements ....................................... 19
Figure 4: Purpose and Scope for GoF Approach ....................................................... 28
Figure 5: Pattern and Problem Categories for POSA Approach................................ 28
Figure 6: Levels of Solution for Security Patterns..................................................... 29
Figure 7: Steps and Archifacts of Research Approach .............................................. 32
Figure 8: SFRs Usage in STs ..................................................................................... 36
Figure 9: Relationship Between Number of SFRs and EAL ..................................... 38
Figure 10: Relationship Between Number of SFRs and EAL (Subset)..................... 39
Figure 11: Dataset 1: Number of SFRs by SFR Classes in STs ................................ 61
Figure 12: Dataset 2: Number of SFRs by SO in STs ............................................... 63

ix

Abbreviations
CC Common Criteria
EAL Evaluation Assurance Level
IT Information Technology
PP Protection Profile
SF Security Function
SFP Security Function Policy
SO Security Objective
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functions
TSP TOE Security Policy

Abstract
Research experience shows that security needs to be considered from the
beginning of software development life cycle to avoid expensive rework and reduce
potential security vulnerabilities. Hence, defining the right set of security functional
requirements (SFRs) and evaluated assurance level (EAL) becomes a critical task for
developers when developing secure software. Much effort has been put into creating
industry standards to provide a shared common base for stakeholders with concerns
on security. One of the industry standards, which is used widely in both industry and
government sides in many countries, is Common Criteria (CC). However, one of the
drawbacks of Common Criteria is the inefficiency of use. Moreover, with limited
project information in the early lifecycle phase, it is hard for developers with less
security experience to select the right security requirements from what are defined in
CC. Extensions on it and experiences from empirical studies on using it are
demanded to achieve a better and more efficient use of CC, which also benefits
developers by saving their effort on security functional requirements definition.
A thorough analysis has been done on a dataset consisted by the Security Target
(ST) files of 242 security products published on common criteria portal website. A
mapping between security objectives and SFRs is presented, which can save much
development effort by reduce the range of candidate SFRs when developers know
the projects security objectives in the early phases. In the cases when developers
only know the product domain of this project, SFR patterns for nine different
domains of security products are presented based on the statistic result from the
xi

published 242 security products, which can be customized or directly used for
particular security application. The analysis result of correlations among SFR classes
defined in CC and correlations among security objectives provide a good guidance
for developers in designing the architecture of security products. A trend shows that
EAL tends to increase when the number of SFRs increases. It is not strongly proved
by the current dataset, but shows a research direction for further discussion and
explorations in the future.
To validate the correctness of the mapping scheme between security objectives and
SFRs, each of the ST files is reviewed to find out the consistency and difference
between the presented mapping scheme with the actual selected SFRs in 242 security
products with certain security objectives. A method is presented to evaluate the
effectiveness of these security patterns, which can be used as a factor for developers
when to consider applying the patterns for actual use.

xii

Chapter 1: Introduction
Today security has become an important issue in not only government departments
but also commercial companies. Much effort has been devoted to design security
products, such as firewalls, intrusion detection systems, data protection systems and
so on. Software that did not have security features in the past, such as database, must
be upgraded to include security features to become secure systems. In terms of
physical representation, a security product can include software, firmware, hardware
and supported documentation. Developers, when designing a new security system,
have choices of developing originally, using Commercial Off-the-Shelf (COTS)
security products and subscribing security services. No matter what choice is made,
developers need to find out the security objectives and security requirements for later
development or being used as one critical criteria for choosing security COTS
products and subscribing security services.
Security in the past was often treated as an add-on on other requirements. Security
patches were largely applied during software maintenance phase to add protections.
This approach is expensive on both the developer and user sides. It is well known
that the later a bug is fixed the more expensive it is to fix it. Since the patching often
happens after the software is delivered, it is expensive to develop the patches. It is
also a time-consuming job for users to install the security patches every time they get
updated. In terms of effectiveness, security patches are designed after the launch of
many successful attacks on one or many security vulnerabilities. Hence users already
1

suffered with the loss of asset values caused by the attacks in the most cases.
Changes on the old approach are highly demanded because of these drawbacks. The
most critical change is to consider security from the beginning of software
development life cycle (SDLC) to address potential threats and enforce organization
security policies. It is not hard to understand the requirements of security patches
since they are clearly driven by discovered vulnerabilities. However, with very
limited information in the beginning phase, it is often hard for developers especially
those with limited security knowledge to determine the right set of security
requirements for the security product. Furthermore, it is a hard task to describe these
security requirements in a way to minimize the ambiguity of them. It is also
important for other stakeholders, such as users and administrators, to interpret the
security requirements in the same way. Industry standards such as Common Criteria
(CC) [13] address this problem by defining security requirements, which provides a
shared common knowledge base. By selecting security functional requirements (SFR)
and evaluated assurance level (EAL) defined in CC, developers can then record them
into a documentation called security target (ST), which is also defined in CC for
future review by certification people or other stakeholders like customers.
CC has a comprehensive set of SFRs that includes 138 SFR components and is
grouped into 11 classes, which is an obvious advantage for wide use. However, it
may become an disadvantage for developers to spend effort on studying each SFR
component defined in CC. Especially when developers only interested in a few
security objectives such as authentication, it is a huge waste of effort for them to
2

study all SFRs to be able to select the appropriate SFRs. One contribution of my
research is to map SFRs in CC to the security objectives defined in section 2.1, hence
reduce the number of candidate SFRs for developers to explore. Security objectives
are defined by analyzing the system assumptions and potential threats of certain
security product. Since the assumption and threats may vary a lot for different
security product in different environments, how to define security objectives is not
addressed in this research. This research focuses on how to select SFRs after
developers know what the products security objectives are. For further increasing
the efficiency of selecting SFRs, this research also defines several SFR packages
with different rigor levels or emphasize for certain security objective. These SFR
packages are first designed based on the definitions of SFRs in CC. The SFR
packages then are refined by observing the difference and extracting the
commonalities in the selected SFR set from a big dataset, which includes ST files for
242 validated security products published on Common Criteria portal website.
Security products can be grouped into domains based on the common
characteristics they share. Examples of characteristics can be threats, IT-environment,
security objectives, etc. Domain specific software architecture (DSSA) is a
successful example to explore architecture patterns [39, 40, 25]. It is also valuable to
discover security requirements patterns for each security product domain with two
major advantages: First, it helps us to understand nature of the problem that this
domains security products address. Second, it provides a good set of requirements
for future reuse.
3

Developer especially architect person is interested in the coupling and cohesion as

important metrics for evaluating the design. Coupling measures the degree of one
component dependent on another component [10]. While cohesion measures how
strongly related and focused responsibilities of a single component [47]. [19][32][41]
state that low coupling and high cohesion lead to reliable and maintainable products.
When designing security products, it is also important to achieve low coupling and
high cohesion, which requires we understand the relationships or correlations among
SFRs.
In a summary, developers can benefit from this research in four aspects:

With the least knowledge of the products security objectives, developers can use
the result shown in table, to focus on the SFRs mapping to the particular security
objective instead of exploring the whole set of SFRs.

With advanced knowledge in products security objectives, such as rigor levels,

developers can apply the SFR packages to their security products with
considerations in variations as stated in section 5.

With knowledge of domain that the product belongs to, developers can customize
the security pattern for particular domains as stated in in section 6.

Use the correlation between SFRs stated in section 5 as a guideline in developing

security system architecture.

The rest paper is structured as following: Section 2 gives a review of background

and related work. Section 3 explains the research approach. Section 4 discusses the
ST dataset context and general observations on it. Section 5 shows the results of
analyzing STs on SFR packages for different security objectives, SFRs correlation
and SFR patterns in security product domains. Section 6 describes the validation
approach used in this research and the initial validation result. Section 7 summarizes
the research status at this point and provides a completion plan for the future work.

Chapter 2: Background and Related Work

Section 2.1 outlines the security taxonomy used in this research. Section 2.2
outlines the research about security extension on software development process.
Section 2.3 discusses some existing standards on defining security requirements and
levels. Section 2.4 outlines the background of pattern approach and current research
on security pattern analysis and exploring.

2.1 Security Objectives Taxonomy

Security objective for certain security product is targeting on one higher
abstraction level than SFRs for addressing systems security threats and enforcing
organizational security policies.
Security objectives, if grouped based on the phases of treating security attacks, can
be preventive, detective and corrective. Preventive security objectives targeting on
security mechanism that can effectively prevent attack before it has any effect on the
system. Detective security objectives targets on security mechanisms that can
quickly and effectively detect intrusion or abnormal behaviors if there is any, and
covers subsequently actions or responses. Corrective security objective focuses on
system recovery or data recovery when system or integrity of data is comprised. CC
defines standards for SFRs, not for security objectives. In this section, I want to
present the taxonomy of security objectives, which provides a consistent language
when talking about security objectives in this research.
Preventive
6

Identification & Authentication: Identify an unknown user using attributes such as

username. Authentication is to prove somebody is whom he claims to be by
verifying the security attributes, such as password. It is the most basic security
objective.
Confidentiality: Protect information from unauthorized disclosure. Confidentiality is
a complex security objective compared with others. It contains several aspects, or
sub objectives: access control, information flow control, encryption, and residual
data protection. It is important to not confuse access control with authorization [17].
Authorization is to make sure if a subject has the proper permission to perform
actions (e.g., read, modify, delete) on an object, and it is often required that the
subject is authenticated. While access control controls the access/operations on an
object based on more general rules, such as system time or host IP address.
Integrity: Integrity protects information from unauthorized modification instead of
disclosure. It is also possible that integrity is compromised by authorized users
mistakes.
Availability: It ensures the accessibility of information and continuousness of system
functionalities.
Non-repudiation: It ensures that the sender cannot deny he sent the information and
the receiver cannot deny the receipt of the information, by assuring the identity of
both the originator and recipient of transmitted information. A good example of
security mechanisms for it is digital signature.

Security Management: It provides users with certain roles the ability to customize
the use of security mechanisms in a security product. The management can be switch
on/off or customize a security function, or management security attributes of users or
roles. This security objective is not highly related with protection on system or
information, hence is quite distinctive with others.
Privacy: Privacy targets on users identity or actions non-observable to others, even
TSF. This security objective is specific because it sometimes conflicts with other
security objectives such as accountability. Unobservability makes users action
unaccountable.
Detective
Accountability: It provides functionalities for generating records for system behavior
or user actions, which can be used for future review.
Intrusion Detection and Response: It addresses the detection instead of prevention of
certain intrusion. It also covers the potential response activities such as security
alarms in case of detecting an intrusion.
Corrective:
Recoverability: It covers two aspects: data recoverability and system function
recoverability. Data recoverability includes data correction after unauthorized
modifications. System function recoverability requires that system recovers to a
secure state and/or is still able to provide the key functionalities after certain failure
happens.

2.2 Security Considerations in SDLC

Security in softwareintensive systems is now a highpriority objective for both
government organizations and industry companies. Designing and implementing
systems with security requirements using traditional approaches for systems often
results incomplete coverage of real threats, and provide little assurance that any
security capabilities developed for the system adequately defend the system against
their intended threats. Traditional standards for software engineering processes often
treat security requirements like other quality requirements. But, achieving moderate
to high levels of security requires more consideration than is needed for most other
system qualities, such as usability. Because of the difficulties achieving security,
new activities (e.g. threat analysis security requirement specification, emergency
response planning) need to be added into traditional software development process.
This section outlines some work on defining the special process for developing
security software and the evaluation models for these security specific processes.

2.2.1 NIST Special Publications

National Institute of Standards and Technologies (NIST) drives this effort in many
aspects. [30] integrates security consideration into the capital planning and
investment control process. [24] defines security-related key roles and their
responsibilities throughout the software development life cycle (SDLC). Figure 1
shows the security considerations in different phases of SDLC.

Figure 1: NIST Work Breakdown Structure

[24] does not discuss each of these security activities in detail, hence NIST
published several other documents address on particular security activities. [18]
describes a standard approach for categorizing security IT systems. Three levels of
threats impact on systems are defined in [18]: Low, moderate or high. The security
categorization can be used as one criteria for selecting security controls for the target
systems. [37] defines the risk assessment method for identifying preliminary
security-related risks, which can be used as another criteria for selecting security
controls. Developers can select security functional and assurance requirements from
Common Criteria [13] for security requirement analysis in acquisition/development
phase. [38] provides the guide for developing a security plan. [44] describes an
framework of building a security awareness and training system for developers and
other key stakeholders.
10

2.2.2 MBASE Security Extensions

Model-Based (System) Architecting and Software Engineering (MBASE) [5] was
developed by the Center for Software and System Engineering (CSSE) at the
University of Southern California in 1997. It defines a set of guidelines for
approaches to integrate the process, product, property and success models for
developing a software system. MBASE is an extension of the risk-driven, iterative
Win-Win Spiral approach also developed at USC [6], so that it could provide more
of an iterative method. MBASE consists of two sets of documentation: the first set is
developed in the inception and elaboration phases, which include the Operational
Concept Description (OCD), the System and Software Requirements Definition
(SSRD), the System and software Architecture Description (SSAD), the Life Cycle
Plan (LCP), and the Feasibility Rationale Description (FRD). The second set is
developed in the construction, transition, & support (CTS) phases. MBASE defines
three critical project milestones: Life Cycle Objectives (LCO), Life Cycle
Architecture (LCA), and the Initial Operational Capability (IOC). LCO is achieved at
the end of the inception phase, LCA is achieved at the end of the elaboration phase
and IOC is achieved at the end of the construction phase. MBASE has been used by
USCs graduate software engineering students since 1999 to work with campus
service providers to develop and transition working e-services applications in USCs
CS577 software development project course. However, MBASE does not have
specific guidelines for developers about what and how to do when they are
developing secure software.
11

[45] defines a extended framework based on MBASE to address special activities

when developing a secure software. Table 1 is a security extension on what need to
be included in MBASE document at LCO and LCA anchor point [7].

OCD

SSRD

SSAD

LCP

FRD

LCO
Organization security goals and policies
Project security goals
System security environment
Security related stakeholders identified
System artifacts classification and access control
System security capabilities
Level of services (LOSs) including security
objectives
Rules of behavior
Security functional requirements (SFRs)
Security assurance requirements (SARs)
Development requirements
Development constraints
LOSs requirements
Security requirements for deployment, transition,
and support environment
Top-level definition of at least one feasible
security architecture

Security planning
Top level of WWWWWHH* by stage
Security activities in inception, production and
support stage
Stakeholders security related responsibilities
Auditing and Monitoring
Top-level Security Risk Control
Security Certification and Accreditation
Security Assurance
Business analysis of security solution
SFR & SAR satisfaction
Security Risk assessment
Vulnerability analysis
Threat Analysis
COTs security assessment if any

LCA
Elaboration about
organization and project
security goals.
Elaboration about access
control on system artifacts
Elaboration about system
security capabilities and
LOSs
Elaboration about SFR
and SAR by increment
Elaboration about other
requirements if any

Choice of security
architecture
Satisfy evolutional
requirements
Elaboration about
WWWWWHH by
increment
Elaboration about security
assurance level and
security risk control
Elaboration about
Security Certification and
Accreditation
Assurance of consistency
All major security risks
covered by risk mitigation
or acceptance/response
plan

Table 1: MBASE Completion Criteria for Anchor Points

12

We can see that security requirements need to be defined during inception phase
and completed at LCO anchor point. In both [24] and [45], the definition of security
requirements is a necessary activity in the early phase of SDLC.

2.2.3 SSE-CMM & IA-CMM

Systems Security Engineering-Capability Maturity Model (SSE-CMM) [28] is a
process reference model created for security system development process. It provides
a framework to measure and improve performances in the application of security
engineering principles. Same as Capability Maturity Model (CMM), SSE-CMM has
five capability levels: Capability level 1 - performed informally; capability level 2 planned and tracked; capability level 3 - well defined; capability level 4 quantitatively controlled; capability level 5 - continuously improving.
The INFOSEC Assurance Capability Maturity Model (IA-CMM) [29] addresses
INFOSEC assurance processes based on the SSE-CMM [28]. The IA-CMM defines
nine process areas and six capability levels from zero to five. A process rated high on
the IA-CMM scale is more likely to produce systems with high levels of security
assurance, with all other things being equal. The IA-CMM provides good criteria for
evaluate the maturity of a software development process for developing secure
software.

2.3 Security Evaluation Criteria

Developer with great security expertise may not have the same capability in
presenting the project security requirements. Industry or government standards [13,
13

27, 42] provide a shared knowledge base and uniform representation of security
requirements, so that developers can select security requirements from standards for
direct or customize use. The evaluation methodologies defined in [13, 27, 42] also
establish the confidence of the products security functionalities. In this section, we
will talk about three well-used security evaluation criteria, and how they organize
security mechanisms and assurance into different classes or levels.

2.3.1 Trusted Computer Systems Evaluation Criteria

Trusted computer systems evaluation criteria (TCSEC, also known as Orange
Book) [42] was first published by Department of Defense in 1983. It has seven
security classes as shown in table 2, grouped into 4 divisions, where D is the lowest
and A is the highest. Each security class covers four aspects: Security policy,
accountability, assurance and documentation. Security policy and accountability
covers what security mechanisms need to be include to have access control
protection to information. Assurance describes how the system provides confidence
for these security mechanisms. Documentation includes the written evidence
required for each class.

14

Division

Name

Minimal Protection

C1

Discretionary Security

C2

Controlled Access Protection

B1

Labeled Security Protection

B2

Structured Protection

B3

Security Domains

A1

Verified Design

Table 2: Security Classes in Orange Book

Orange book mainly targets on security systems for government and military use.
Industry people find several deficiencies while applying it to security systems that
are used in commercial areas. The following are some major issues when applying
orange book to commercial security products:

Orange book focuses on confidentiality, does not address well on integrity

and availability. However, Integrity and availability are more important than
confidentiality in some commercial areas, such as bank transaction system.

Orange book uses government protection classifications, which are different

with commercial protection classifications.

Orange book focuses on operating systems, which limits the domains of

security products that it can apply to.

Moreover, orange book does not separate security functionalities with security
assurance. Security functionalities and assurances are combined in one rating, where
security policy and accountability focus on security functionalities, and assurance
and documentation focus on security assurance. In terms of usability, it only
15

provides 7 classes of security levels, hence does not have much flexibility for
customize use.

2.3.2 Information Technology Security Evaluation Criteria

Many other countries, mostly European, have much own experiences in security
evaluation. Orange book [42] triggers their interests in establishing consistent
evaluation criteria among different countries. Information Technology Security
Evaluation Criteria (ITSEC) [27] is the result of this collaborating effort. It is the
combination of the best parts of various countries evaluation criteria in a consistent
perspective with extensions on some parts.
ITSEC separates security functionalities and assurance, and organizes them
respectively as classes and levels. It has 10 security functionality classes labeled
from F1 to F10, where the functionality requirements in each class from F1 to F7 are
derived from security functional requirements defined in Level D to A1 in Orange
Book classes. F8 to F10 covers the integrity and availability requirements for static
data, and the integrity requirements for data in transmission. It has 7 assurance levels
labeled from E0 to E6, where E0 represents inadequate confidence and E6 represents
the highest level of confidence. The mapping between ITSEC security functionalities
classes plus assurance levels and Orange Book security classes is shown in table 3:

16

ITSEC Security Functionality

E0
(F1, E1)
(F2, E2)
(F3, E3)
(F4, E4)
(F5, E5)
(F6, E6)

Orange Book
D
C1
C2
B1
B2
B3
A1

Table 3: ITSEC Levels Mapping with OB Levels

2.3.3 Common Criteria

Common Criteria (CC) version 1.0 [11] was published by National (NIST) in 1996.
Version 2.3 [13] incorporates feedback from extensive review and trials, and is
adopted as ISO 15408 in 1999. CC has two major goals:

Provide common framework in defining security measures of security

products

Provide formal evaluation method to establish the confidence of security

functionalities of security products.

The evaluation of security products validates security products security functional

requirements as well as the security assurance requirements. Common Criteria
provides a consistent requirement specification between developers, acquires,
evaluators and accrediators by defining 11 Security Functional Requirement (SFR)
classes and 9 Security Assurance Requirement (SAR) classes. Each class is further
grouped into families with different emphasis. The next level below family is
component, which is the smallest item that may be selected by developers as security
requirements. Common Criteria also allows developer to explicitly state SFR if he
cannot find a match from existing ones. CC also provides packages of security
17

assurance requirements, as known as Evaluated Assurance Level (EAL), where EAL

1 has the lowest assurance. The provided EAL package facilitates developers work a
lot in selecting appropriate set of SARs. Developers can directly use or customize the
EAL package for the desired security assurance. In most evaluated security products,
the EAL package will be directly used or with slightly augment by replacing few
SAR components with higher rigor level ones.
CC also defines two documents: Protection Profile (PP) and Security Target (ST).
As defined in [26], both PP and ST describe a set of security functions and assurance
requirements for an information technology product or system (Target of evaluation,
i.e., TOE). The only difference is that PP describes requirements that are
implementation-independent, while ST describes requirements, mechanisms and
measures that are implementation-dependent. ST for a certain secure product can be
derived from one or several PPs or created independently. Figure 2 shows the
structure of PP and ST.
PP (implementation independent)

ST (implementation dependent)

Section 1. Protection Profile Information

Section 1. Security Target Identification

Section 2. TOE Description

Section 2. Description

Section 3. TOE Security Environment

Section 3. Security Environment

Section 4. Security Objectives

Section 4. Security Objectives

Section 5. Security Requirements

Section 5. Security Requirements

Section 6. Application Notes

Section 6. TOE Summary Description

Section 7. PP Rationale

Section 7. PP Claims
Section 8. Rationale

Figure 2: Structure of PP & ST Document

18

As shown in Figure 2, PP and ST has almost the same structure, except that section
6 of ST covers TOE implementation details (TOE security function and descriptions)
and section 7 specifies the PP if ST is derived from it. In both PP and ST, the chosen
SFRs and SARs for the security product are stated in section 5 Security
Requirements.

Figure 3: Organization and Construction of Requirements

As shown in Figure 3, SFR and SAR components can be grouped into reusable
packages and be included in PP or ST files. Common Criteria has done a good job in
grouping SAR components in 7 reusable packages, i.e. EALs, however it does not
define any reusable package for SFR components. There are several validated PPs
published on NIST site, which contains a combination set of SFRs and SARs defined
for a particular type of application (i.e., domain type), such as Operating System.
These PPs are created using a upside down approach and represent experts solutions
on security requirements for a certain domain of security products. In this thesis, I
19

use a bottom-up approach to extract general solutions from the published STs on the
Common Criteria portal website [15]. Although not all the domains are covered in
this thesis, the proposed security objectives framework and their mappings with
SFRs can be used to apply to any domain for discovering security requirements
patterns.
2.3.3.1 Security Objectives Mapping with SFRs
Table 4 shows the result of mapping CC SFR families with security objectives.
Each row is a SFR family and each column is a security objective. The SFR family
instead of SFR class or SFR component is used because the family level is the sweet
point for maximizing the precision and reducing the complexity of the table. Please
refer to section 2.1 for definitions on these security objectives and Appendix B for
full names of SFR families.

ARP

ID&R

Recoverability

Accountability

Privacy

Security
Management

Availability

Integrity

Confidentiality

Family

Identification
&Authentication

Class

Non-repudiation

Security Objectives

Common Criteria

GEN

SAA

SAR

SEL
Security
Audit (FAU) STG

D
D

*D: Direct support I: Indirect support

Table 4: Mapping Between SFR and Security Objectives

20

NRO
Communication
(FCO)
NRR

ID&R

Recoverability

Accountability

Privacy

D
D

CKM
Cryptographic
Support (FCS) COP

ACC

ACF

DAU

User Data
Protection
(FDP)

Security
Management

Availability

Integrity

Confidentiality

Family

Identification
&Authentication

Class

Non-repudiation

Security Objectives

Common Criteria

ETC

IFC

IFF

ITC

ITT

RIP

ROL

SDI

UCT

UIT
AFL

ATD

SOS

UAU

Identification & UID

authentication
(FIA)
USB

Table 4, Continued
21

Recoverability

ID&R

FLS

D
I

MTD
REV

Privacy

MSA

Security
Management

Availability

Integrity

AMT

Family

MOF

Security
Management
(FMT)

Accountability

Confidentiality

Identification
&Authentication

Class

Non-repudiation

Security Objectives

Common Criteria

D
I

SAE

SMF

SMR

ANO

PSE

UNL

Privacy (FPR) UNO

ITA

ITC

ITI

ITT

PHP

RCV

D
D

RPL
RVM
Protection of
the TSF (FPT) SEP

D
I

Table 4, Continued
22

ID&R

Recoverability

TRC
Protection of
the TSF (FPT) TST

D
I

FLT

PRS

RSA

MCS

TOE Access
(FTA)

Accountability

Security
Management

Availability

Integrity

TDC

LSA

STM

Resource
Utilization
(FRU)

Privacy

SSP

Confidentiality

Family

Identification
&Authentication

Class

Non-repudiation

Security Objectives

Common Criteria

SSL

TAB

TAH

TSE

ITC
Trusted path/
channels (FTP) TRP

Table 4, Continued
As you can see from this table, Common Criteria SFR classes and security
objectives have many to many relationships. For examples, the integrity security
objective can be satisfied by SFR components from different classes, such as FCS,
FDP and FPT. While requirements in FCS class can satisfy more than one security
objectives: Confidentiality, integrity and non-repudiation. The second example is
23

more interesting for developers because it indicates that the implementation of one
set of SFRs may satisfy multiple security objectives.
FMT is a special SFR class defined in CC. Unlike other classes which adds the
security to the TOE, several requirements in FMT such as management of functions
in TSF (FMT_MOF) and specifications of management functions (FMT_SMF) add
on usability or flexibility for other selected SFRs. For example, FMT_MOF allows
special users such as administrator to turn on/off or modify a security function,
which provides more flexibility. However, one can argue that this requirement
actually reduces the security rigor because it relies on the assumption that
administrator will never be malicious. There are requirements in FMT also provides
more security rigor, such as security attributes expiration (FMT_SAE). It enforces
time limits for the validity of security attributes. Hence, security management is
defined as a separate security objective and is satisfied by SFRs in FMT. Another
special class is FPT. As shown in the table, several requirements in FPT support all
security objectives since they protect all the TSF functions. Requirements such as
domain separation (FPT_SEP) are necessary when developing secure software with
high level of robustness. If the TOE has high expectation on confidentiality, it is also
necessary to include non-bypassability of TSP (FPT_RVM), which ensures that
security polices such as access control policies are followed.
Privacy needs to be defined as a separate security objective than confidentiality.
Confidentiality cares about data or information, which are usually objects in the
system. Privacy, on the other hand, protects user identity from being disclosure and
24

protects users activities from being observed. Developers need to be very careful in
choosing requirement for privacy, since it may be contradict with SFRs for other
security objectives, such as accountability. For example, anonymity (FPR_ANO)
requires user may use a resource or service without disclose its identity to other
authorized users (E.g., administrator), even TSF. It conflicts with auditing data
associated with user identities (FAU_GEN.2). Unobservaility (FPR_UNO) is special
in FPR since it tries to hide the resource or service being used instead of hiding user
identity. This requirement is often selected by security products in IC and smart card
domain, we will see it from the analyzed result of ST files as shown in Section 5.
2.3.3.2 Security Target
Security Target is formal document defined in CC as a key element in the
evaluation process. Its contents include security objectives, functional and assurance
requirements, summary specification, PP claims, and rationales. It may conform to
an existing PP and becomes a implementation-dependent response for a certain PP,
or may be created independently, as shown in table 5.

25

Section Name
Section 1. Security Target
Identification
Section 2. Description
Section 3. Security
Environment

Section 4. Security
Objectives
Section 5. Security
Requirements
Section 6. TOE Summary
Description
Section 7. PP Claims
Section 8. Rationale

Content
Identify the name and nature of ST. Provide the overview
of ST and relationship with other ST or PP
Describe TOEs type, architecture and system boundaries,
which includes physical and logical boundaries.
State security assumptions and threats for the TOE and
operational environment. Operational environment
includes IT environment and non-IT environment.
Describe organizational security polices, which applies
to both TOE and operational environment.
Describe security objectives for TOE and its IT and nonIT environment.
Describe the SFRs and SARs for implementing security
objectives in section 4, SFRs can be explicit stated.
Describe TOE security functions; Security assurance
measures details are discussed.
Identify dependent PP and any tailoring if applicable.
Demonstrate security objectives mapping to threats,
system assumptions and security policies; Demonstrate
SFRs satisfies security objectives; Demonstrate security
functions implement SFRs;

Table 5: Contents of ST Sections

We will focus on the analysis of section 4, 5 and 6 of validated ST files. The table
of mapping security objectives with SFRs can be validated by information provided
in section 4 and 6. SFRs packages and SFR patterns for different security product
domains can be derived from information provided in section 5 and 6.

2.4 Software Pattern and Security Pattern

The increasing need of security in both government and industry demands more
security engineering methodologies to foster the development of secure software.
One of the biggest efforts is to explore security patterns. Pattern in general has been
successfully used in software design and development for capturing the best
practices. It is usually a generic solution derived from expert knowledge or existing
26

solutions for solving a particular set of problems. Christopher Alexander is the first
person to raise this pattern concept in [1] and [2]. As he wrote in his books:
Pattern: Each pattern is a three-part rule, which expresses a relation between a
certain context, a problem, and a solution.
He explained further with his statement: Each pattern describes a problem which
occurs over and over again in our environment, and then describes the core of the
solution to that problem Alexander also suggests that every pattern should have a
common structure, which is beneficial of comparing and organizing them. [33]
claims five mandatory elements necessary for a pattern: Name, Context, Problem,
Forces and Solution. What is covered in each of these five pattern elements for SFR
patterns is shown in table 6:
Pattern Elements
Name
Context
Problem
Forces
Solution

Contents
Domain Name
Major security features, IT-environment, major assumptions if
specific for this domain
Threats
Variations of the selected SFRs for different scenarios
SFRs that are selected by most of security products in this
domain, which fit in the context and addresses the problems.

Table 6: Element Content of SFR Pattern

Template of patterns often has a fixed structure, which provides a common
framework for classifying patterns. The two most used pattern templates are GoF
approach [22] and POSA approach [9]. The defined criteria and related pattern types
from these two approaches are shown in Figure 4 and 5:

27

Figure 4: Purpose and Scope for GoF Approach

Figure 5: Pattern and Problem Categories for POSA Approach

SFR pattern discussed in section 6 matches with the criteria defined in POSA
approach, with the exception that SFR pattern is in requirement level, which is even
one level higher than the architectural patterns (High Level) defined in POSA
approach. The correlations among SFRs stated in section 5 provide some valuable
information for developing the architectural patterns.
28

[35] gives a definition of security pattern:

Security Pattern: A security pattern describes a particular recurring security
problem that arises in a specific security context and presents a well-proven generic
scheme for a security solution.
Depending on the problem, solution may have two dimensions in terms of levels of
patterns. In one dimension, the process for developing secure software may follow
different patterns in different phases of lifecycle. One example could be the
organizations work breakdown structure, which shows a specific process pattern
works only for a particular organization. The existing industry standards are more
general patterns, where organizations can optimize the standards for their customize
use. The other dimension is the abstraction level of the solution. As shown in Figure,
the solution can have different levels Organization, system, requirement,
architecture and implementation.

Figure 6: Levels of Solution for Security Patterns

29

[34] discovers security pattern in defining organization security policy and

responsibilities related with different security roles. [46, 8, 20] explores security
patterns in architecture level. [43, 36] provides security patterns in security
application code. However, there is not too much work addresses security pattern in
the requirement level as shown in Figure 6. In this thesis, I try to explore the
requirement level of security patterns in security product domains using a standard
SFR definition provided by CC.
Kerth and Cunningham groups the processes that investigators use to find patterns
into three general categories [31], it may not be a complete list and investigators may
use a combination of approaches:

Introspective approach: People define patterns reflecting their own experiences

on a particular problem.

Artifactual approach: People discover patterns by studying different products

designed for solving similar problems.

Sociological approach: People exchange their experiences and opinions in their

solutions, and discover patterns by finding out the common and good practices.

30

Each of these approaches has its advantages and disadvantages, as shown in Table
7:
Advantages
Introspective Reflects expert opinions, often
approach
demonstrated by examples or
actual solutions
Artifactual
Authors effort to obtain a generic
approach
approach from many existing
solutions
Sociological Comes out good solution agreed
approach
and accepted by many experts

Disadvantages
Pattern reflects personal style, may
need further evaluation and
agreement from others
Patterns may not be a direct
solution; may need further
evaluation and refinement
Big communication effort;
sometimes it is hard to achieve an
agreement

Table 7: Advantages and Disvantages of Pattern Exploring Approach

In this thesis, I will use the artifactual approach for discovering patterns in security
requirements. I try to discover the generic security pattern based on Security Target
files of 256 validated products listed on Common Criteria Portal site. As stated in
table, developers may not be able to directly use the discovered pattern as a set of
security requirements for their targeted application. However, the requirement
pattern reflects the common practices from many existing validated security products,
hence it provides a good start set for developers to extend on.

31

Chapter 3: Research Approach

Common Criteria defines 7 reusable packages of SARs (EALs), however it does not
define reusable packages of SFRs. One of the goals of this research is to define
reusable SFR packages targeting on different security objectives based on the
analysis result of 242 STs. Furthermore, the goal is to present SFR packages with
broader scope (i.e., SFR pattern) that fit in different domains of security products.
Another goal of this research is to discover the dependency relationship among SFRs,
which is interested to architect when determining the component structure. To
achieving these goals, the research approach is shown in Figure 7:

Figure 7: Steps and Archifacts of Research Approach

The preparation work is to map SFR defined in CC with security objectives, which
is described in section 2.1. The result of mapping presents the group of SFRs that
32

should be selected to achieve certain security objective. In this research, the first step
is to explore and cleanup the dataset. Result of this step is a big table, where each
row is a TOE (Total 242), each column is a SFR component, each cell of the table
shows the number of certain SFR component selected in the TOE. In this table, 189
TOEs are grouped into 9 domains, and the rest 53 TOEs are not grouped into any
domains. The second step is to do some simple statistics analysis of the big table of
242 STs derived from the first step. Results in this step show the usage of SFR
classes in these STs and the relationship between EAL & SFR. The third step is to
define reusable SFR packages with different levels. With basic knowledge of what
security objectives are required in this secure software and in what level, developers
can find out the corresponding reusable SFR packages defined in this step for
directly use or customization. Step 3 explores the total 189 STs as one set. The fourth
step discovers the correlations among SFRs, which provides valuable information for
security architecture design. The fifth step explores the 189 STs as 9 sets, where each
set matches with a particular domain. Results of this step are security requirements
pattern for each domain, which can be customized for a new products use if it fits in
any of these domains. The last step is the validation of all the results derived from
step 3 and 5.

33

Chapter 4: Data Context and General

Observations
The 242 security target files (STs) for analysis are selected from more than 300
validated security products published on the Common Criteria portal website [15].
For obviating single product or single companys overwhelming impact on the
overall analysis result, we only include the ST for the latest version of the security
product if there is no big difference in SFRs chosen by these different versions of
same security product. These STs were written for security products designed by
different companies: Microsoft, IBM, Cisco, Sun, Symantec, McAfee, etc. In terms
of nationality, they come from different countries, including US, Canada, German,
England, Australia, etc. 189 out of 242 STs are grouped into 9 domains. Table shows
the average number of TOE SFRs, the range of TOE SFR, the average EAL, the
range of EAL and total number of data points in each of these 9 domains.
Domain Name
Access Control Devices
and Systems
Boundary Protection
Devices and Systems
Database
Data Protection
Detection Devices and
Systems
ICs, Smart Cards and
Smart Cards related
Devices and Systems
Key Management systems
Network and Network
related Devices and
Systems
Operating Systems

Avg num of
TOE SFR

Range of
TOE SFR

Avg
EAL

Range
of EAL

Num
of STs

19.00

[8, 38]

2.65

[2, 4]

10

22.21

[4,46]

3.23

[1,4+]

42

23.27
22.56

[2,39]
[1, 69]

3.73
2.47

[2,4+]
[1, 4+]

11
16

18.43

[10, 29]

2.14

[2, 3]

33.97

[3, 91]

4.47

[2+, 5+]

36

29.36

[7, 76]

3.25

[1+, 4+]

13

22.86

[4, 45]

2.73

[1, 4+]

28

35.88

[11, 107]

3.81

[2, 5]

26

Table 8: Summaries of Security Products in Different Domains

34

There are no big differences on number of SFRs in these domains. Security

products in operating system domain contains the most SFRs because they tend to
provide more rich security functionalities with different aspects compared with
security products in other domains, where security products focus on few aspects of
security. The average EAL of security products in smart card domain is the highest
compared with other domains. The main reason is that security products in this
domain often protect highly desirable assets such as credit card information, hence
requires relatively high assurance in security functionalities they provide. There are
42 STs in boundary protection devices and systems, which shows that security
products in this domain such as firewall are still the biggest interest of Industry. 35
STs in smart card domain represent the interest of security from business side,
mainly credit card companies.

4.1 SFR Classes Usage

Not every SFR class defined in Common Criteria is equally used in these STs. As
shown in Figure, five most frequently used SFR classes are FAU (73%), FDP (90%),
FIA (83%), FMT (90%) and FPT (85%). With the mapping result of SFRs and
security objectives discussed in section 2.2.3.1, some explanations can be made as
following:

35

250
217

217

206

201
200

177

150
109
100
60
50

36

41

FRU

FTA

26

23

0
FAU

FCO

FCS

FDP

FIA

FMT

FPR

FPT

FTP

Figure 8: SFRs Usage in STs

Since nothing is perfectly secure, it is always good to have some records of system
behavior or events for future review. Many security products include at least the
audit data generation requirements defined in FAU. FDP is frequently used for
protecting user data for confidentiality, integrity, availability and recoverability. The
242 security products in our dataset are more emphasize on data confidentiality than
integrity. One of the reasons could be the implementation of detecting unauthorized
changes is harder than protection from disclosures. FIA provides identification and
authentication requirements. They are the most basic security mechanisms, hence are
used in most security products. Unlike FAU, FDP and FIA, FMT and FPT do not
directly addressed any security objectives, however they provide requirement for
supportive functionalities, such as security attributes management and reliable time
stamps. Hence SFRs in FMT and FPT are more or less used in most security
products.

36

FRU, which addresses resources availability, only included in less than 15%
validated security products, mainly from database, smart card and operating system
domains. We can see that deny of service (DoS) type of attacks are not addressed
enough in this dataset. FCO and FPR target on non-repudiation and privacy. They
are not typical security mechanisms like identification& authentication and access
confidentiality, hence are not frequently used in this dataset.

4.2 SFR & EAL: General Trends

There is a fluctuation in the approach of handling security functional requirements
and security assurance requirements. Orange book [42] defines each security class as
a combination of some SFRs and SARs, while ITSEC [27] defines separate security
levels for them. Common Criteria v2.3 [13] defines 7 EALs for SARs, but does not
define any level for SFRs. But Common Criteria v3.1 [14] has the trend of
combining some SFRs and SARs back together. In this section, I want to explore on
the relationship between SFRs and EAL using the 242 published STs.

37

Figure 9: Relationship Between Number of SFRs and EAL

As shown in Figure 9, there is an unobvious trend that the assurance level of TOE
increases when the number of SFRs of TOE increases. Customers need to be
satisfied by not only the rich security functionalities, but also by the confidence of
security. Exceptional cases exist that, for some security products, such as device
drivers, they may have few SFRs but extremely high EAL because they are used in
system required very high assurance. Another observation from Figure 9 is: For
security products with EAL higher than 5, the number of SFRs in them are less than
25. The major reason is that it is extremely expensive to achieve EAL higher than 5
for a relatively complex product with many SFRs. I have done a sensibility analysis
to delete few boundary data points to see whether there is a different result. Five data
points have been deleted as marked in Figure 10. Three of them are from OS, KMS,
DP, and two of them are not from any of these nine domains. The result shows that
the trend becomes clearer compared with the trend shown in Figure 9. Since the
number of security products with EAL higher than 5 is much less than the rest, it is
38

not a very strong evidence to derive the conclusion that the EAL of TOE tends to
increase when the number of SFRs of TOE increases. But the result in Figure 10
shows one aspect of the fact that leads to a clear direction for further discussion and
explorations in the future.

Figure 10: Relationship Between Number of SFRs and EAL (Subset)

However, we should also consider that the assurance level of security product can
be affected by but not limited to the following factors:

Domain type: For security products in certain domain, they tend to have
relatively high EAL. For example, as shown in table 8, out of 36 security
products in IC and smart card systems, the average EAL is 4.47.

Mandatory requirement: In certain cases, EAL of security product is mandatory

required by the acquirer of the product.

39

Limited resources: There are not enough resources to achieve the desired EAL.
For example, developers are not capable of doing the formally verified design.
Or there is not enough budget and time for doing it.

4.3 Observations on Security Projects Through

Timeline
After the discussion of general analysis on the EAL and SFRs of these ST files, it
is also very interesting to see how the design of security projects changes through
different time periods, in other words, the change of selected EAL and SFRs. We all
know that security is important for business applications, and it is even more
important for government applications, since the assets protected by those
applications often have higher sensitive levels, which means they contain not only $
values but also personal lives even national safety. After the tragedy in September
11th, U.S. government put much effort and resources to increase the security level in
many aspects. In this thesis, we want to explore these ST files to discover any trace
showing in these data.

40

The following table shows the number of STs, the average EAL and the average of
number of SFRs in year(s) from 1997 to 2005.
Year
NumofSTs EAL
TOESFR
1997 to 2001
29
2.86
22.45
2002
40
3.41
28.65
2003
39
3.26
25.26
2004
46
3.30
25.74
2005
88
3.22
24.74
Table 9: Average EAL & Number of SFRs
As we can see from the table, there are only 29 STs published from 1997 to 2001,
but there are 40 ST files in 2002 one year. In 2005, the number of certified ST files
increased to 88. It not only shows that common criteria is accepted by more people
in both industry and government side, but also shows that security is required in
many fields, and hence is involved in more projects than before. From the average
EAL and the average of number of SFRs in each year, we can see that there is a big
increase from [1997, 2001] to 2002. That shows the dramatic increase of needs for
security during 2002, on the aspects of both functionalities and assurance. One could
question whether it is because the tragedy happened on August 11th, 2001. After
2002, the development of security projects achieves a relatively steady state, where
the EAL and number of SFRs only have little fluctuation. The average of EAL and
number of SFRs in 2005 is little lower than 2004, because of the big number of
security products in 2005 that broads the range of security levels of these products.
To discover more details in how the development of security products changes, let
us take a look on the statistics result of security objectives during these periods. The

41

information about the number and percentage of security products that have a certain
security objective in a particular period is shown in the table 10 and 11:
Year
1997 to 2001
2002
Number
2003
of
2004
Security
2005
Products
Total

I&A Conf Integ Ava Non-R SM

23
29
11
4
2
23
33
40
21
8
7
38
33
39
22
9
7
35
40
46
28
7
2
43
71
87
37
12
9
82
200 241 119 40
27 221

Priv
3
6
5
5
7
26

Acc
21
26
30
30
56
163

Rec
5
8
7
10
12
42

IDR
13
22
15
19
35
104

Table 10: Number of Security Products with Certain SO

Year
1997 to
2001
2002
Percenta 2003
-ge of
2004
Security 2005
Products Total

I&A

Conf

Integ

Ava Non-R

79.3%
82.5%
84.6%
87.0%
80.7%
82.6%

100.0%
100.0%
100.0%
100.0%
98.9%
99.6%

37.9%
52.5%
56.4%
60.9%
42.0%
49.2%

13.8%
20.0%
23.1%
15.2%
13.6%
16.5%

6.9%
17.5%
17.9%
4.3%
10.2%
11.2%

SM

Priv

Acc

Rec

IDR

79.3%
95.0%
89.7%
93.5%
93.2%
91.3%

10.3%
15.0%
12.8%
10.9%
8.0%
10.7%

72.4%
65.0%
76.9%
65.2%
63.6%
67.4%

17.2%
20.0%
17.9%
21.7%
13.6%
17.4%

44.8%
55.0%
38.5%
41.3%
39.8%
43.0%

Table 11: Percentages of Security Products with Certain SO

In table 10, the 23 in the intersection cell of third column and second row
represents that there are 23 security products that have identification& authentication
as security objective from 1997 to 2001. In table 12, the 79.3% in the intersection
cell of third column and second row represents that there are 79.3% of total 29
security products that have identification& authentication as security objective from
1997 to 2001. As shown in table 11 and 12, almost every security product has
security objective as confidentiality. Identification& authentication and security
management are also used in more than 80% of security products. Availability, nonrepudiation, privacy and recoverability are not commonly used in security products
as other security objectives. There is a trend that the percentages of security products
42

that have identification& authentication and integrity keep increasing from [1997,
2001] to 2004, which shows an increase of importance of these two security
objectives. Let us then look at the average number of SFRs that are used by security
products for achieving security objective in these years, as shown in Table 12.
Year
1997 to 2001
2002
2003
2004
2005
Avg

I&A
3.79
4.55
3.82
3.65
3.81
3.92

Conf Integ Ava Non-R SM

8.55 2.38 0.17 0.59 4.66
10.73 3.70 0.35 1.33 6.43
9.77 3.49 0.36 1.13 5.10
9.15 2.80 0.30 0.20 6.78
8.98 2.77 0.20 0.59 6.58
9.44 3.03 0.28 0.77 5.91

Priv
0.14
0.20
0.13
0.13
0.09
0.14

Acc
3.34
3.38
4.08
4.11
3.42
3.67

Rec
0.21
0.53
0.23
0.30
0.26
0.31

IDR
0.90
1.18
1.13
0.83
0.84
0.97

Table 12: Average Number of SFRs for Achieving SO

There is a big increase of number of SFRs for all the security objectives from
[1997, 2001] to 2002, which shows that security schemes of products are stronger in
2002 than [1997, 2001]. The most SFRs are used for achieving confidentiality and
security management, since they are the two main functionalities that are selected by
almost every security product.

43

Chapter 5: Security Target Analysis Result

Security functional requirements selected in ST are grouped into SFRs for TOE
and SFRs for IT-environment. Since different TOE may have IT-environment with
providing different security requirements, some TOEs move the responsibility to its
environment. In this section, I will first present the reusable packages for each SFR
class defined in CC. I will then analysis the correlations between SFR classes and
correlations between security objectives. I will also explore the SFR patterns in
different domains as grouped in CC portal website.
Security functional requirement with more rigors does not necessarily increase the
size of the code for implementing the SFR, in other words, increase the effort of
development. Instead, some SFRs sacrifice other project attributes such as usability
and performance for getting stronger security requirements. One good example is
selective proof of origin (FCO_NRO.1) and enforced proof of origin (FCO_NRO.2).
The difference is that FCO_NRO.1 provides proof of origin upon request, while
FCO_NRO.2 provides proof of origin at all times. Apparently FCO_NRO.2 provides
stronger security than FCO_NRO.1, but they dont have big difference in terms of
code implementations. FCO_NRO.2 sacrifices the product usability by enforcing the
generation of evidence for a list of information types.

44

5.1 SFR Reusable Packages

In this section, the SFR reusable packages are grouped in two formats:

The SFR packages can be formed based on emphasize on different aspects of

certain security objective.

The SFR packages can be formed based on different rigor security level. For
example, SFR package with level 2 provides more security level for the security
objective that it supports than SFR package with level 1.
For any security objective, the SFR package may be defined in one or both formats.

5.1.1 Identification and Authentication

Identification and authentication (I&A) is a basic security objective that can be
used to can support the advanced security objectives, such as confidentiality. It direct
maps to FIA class defined in CC. There are total 13 SFRs that satisfy I&A, which
include user identification, authentication mechanism, specification of secrets,
authentication control, user security attributes self-definition and binding. SFRs
shown in table are used in more than 25% of security products that include
identification and authentication as one of security objectives:
Identification
Authentication

User identification before any action (UID.2); Timing of

identification (UID.1); User attributes definition (ATD.1);
User-subject binding (USB.1)
User authentication before any action (UAU.2); Timing of
authentication (UAU.1); Authentication failure control
(AFL.1); Verification of secrets (SOS.1); Protected
authentication feedback UAU.7;

Table 13: SFR Packages for Identification and Authentication

45

User identification (FIA_UID.1/2) and user authentication (FIA_UAU.1/2) tends

to appear in pair since one can argue that it is not really secure if a user is
identified but not authenticated. However, exceptions exist where TOE does not
have authentication as security objectives, and it only provides identification for
supporting other security objectives, such as accountability. In some other cases,
TOE may rely on IT-environment for identification or authentication, or assume
only the authenticated person can access TOE because of the physical protection
of it.

Multiple authentication mechanisms (UAU.5) is used when different

authentication mechanism is applied with different situations. The use of this
SFR is spread in almost every domain except database.

Single-use authentication mechanism (UAU.4) ensures the authentication data

can only be used one time for some or all authentication mechanisms. It is mostly
used in boundary protection systems, IC/smart card related systems, and key
management systems.

Re-authenticating (UAU.6) increases the rigor level of authentication by reauthenticating the user with a specified time limit.

Unforgeable authentication (UAU.3) is used in security products with very high

authentication requirement. This SFR is mostly used in IC/smart card related
security products.

46

Protected authentication feedback (UAU.7) can be treated as an add-on for

authentication requirement. It is often not hard to be implemented. E.g., the
password used typed in should not be shown in the original characters. It can be
protected using * characters.

5.1.2 Confidentiality
Confidentiality includes several sub-objectives: access control, information flow
control, encryption and residual data protection, hence are supported by multiple
SFR classes. There are total 36 SFRs that support the sub-objectives of
confidentiality. These sub-objectives can be selected together or separately in
particular security product for satisfying confidentiality. In terms of the rigor level of
confidentiality, access control and/or information flow control is usually selected for
basic level of protection of confidentiality. Access control and encryption are used in
the security products with medium to high requirements on confidentiality, and at the
same time, the data being protected need to be accessible. However, residual data
protection (FDP_RIP) targets on data that is not in use anymore.
Access control and information flow control are directly supported by some SFRs
in FDP class, such as access control policies and functions (FDP_ACC, FDP_ACF),
information flow control policy and functions (FDP_IFC, FDP_IFF). It is also
indirectly supported by FIA_UID since identification is required for enforcing access
control polices. In normal cases, authorization should also rely on authentication
(FIA_UAU) to validate the identity of user before any authorization happens.
However, in some cases authentication may be excluded from TOE because the TOE
47

is physically protected and only user with certain roles can access it or the ITenvironment provides the authentication. The difference between FDP_ACC and
FDP_IFC is that the previous one targets on the static user data while the later one
targets on the information flow under TSF control. If the TOE requires import or
export data out of TSF control, FDP_ETC and FDP_ITC should be considered to
include in the SFR set. Statistics result from these 242 STs show that there are more
security products with requirements in importing data (FDP_ITC) than exporting
data (FDP_ETC). One major reason for this is that cryptographic keys need to be
securely imported instead of being generated for some security products.

Static data
access control
Information
flow access
control

Level 1
Access control on subset of
operations
FDP_ACC.1, FDP_ACF.1
Access control on subset of
operations FDP_IFC.1, FDP_IFF.1

Level 2
Access control on all
operations FDP_ACC.2,
FDP_ACF.1
Access control on all
operations FDP_IFC.2,
FDP_IFF.1

Table 14: SFR Packages for Access Control

There are three main techniques of access control: Discretional access control
(DAC), mandatory access control (MAC) and role-based access control (RBAC) [21].
In DAC, each object has an owner and the access policies are determined by the
owner of the subject. In MAC, it is the system that defines the access control polices,
not the owners, and it is used in multilevel security systems. RBAC restrict not only
information but also function access to only authorized users with certain roles. In
some cases, security product may have more than one access control mechanism,

48

where FDP_ACC and FDP_ACF needs to be iterated for different access control
policies and functions.
Encryption is a strong mechanism in protecting data confidentiality, especially for
export information, which may be out of TSF control. CC defines a single SFR class
called cryptographic support (FCS) for encryption-related requirements. The most
reusable SFR package for encryption are shown in table below:
Level 1
Crypto key operation
FCS_COP.1

Level 2
FCS_COP.1 FCS_CKM.1,
FCS_CKM.4

Level 3
FCS_CKM.1,[FCS_CKM.2],
[FCS_CKM.3],FCS_CKM.4

Table 15: SFR Packages for Encryption

As defined in Common Criteria, Cryptographic key operation (FCS_COP.1) has
dependencies as cryptographic key generation (FCS_CKM.1) and cryptographic key
destruction (FCS_CKM.4), or import from outside TSF control (FDP_ITC.1). When
security product has requirement of crypto key operation, it has four choices of
satisfying the dependencies:

Has requirement of cryptographic key generation and cryptographic key

destruction

Has requirement of import cryptographic key from outside TSF control

Has requirement of cryptographic key generation, and rely on ITenvironment for cryptographic key destruction requirement

Rely on IT-environment for requirement of cryptographic key generation and

cryptographic key destruction

49

Cryptographic key distribution (FCS_CKM.2) shall be selected when a secure

product needs to distribute the private or secret key to other trusted IT products. It is
also suitable when private or secret key need to be imported and exported every time
TSF initiates. Note import user data protection (FDP_ITC.1) and export user data
protection (FDP_ETC.1) are not suitable here because cryptographic key should not
be treated as user data. Cryptographic key access (FCS_CKM.3) shall be selected
when security system needs to store cryptographic key hence the key access method
should be specified.
Cryptographic key generation (FCS_CKM.1) and operation requirement
(FCS_COP.1) is not necessary in a one to one relationship. Security product with
digital signature functionality often has more cryptographic key operation
requirements than cryptographic key generation requirements, since a digital
signature can be created with each combination of hash key and private key.
In case user and TSF or TSF and other IT trusted products need trusted
communication path, TSF needs to include: Provide a trusted channel between TOE
and a remote trusted IT product (FTP_ITC.1); provide a trusted path between user
and TSF (FTP_TRP.1). Since reference mediation (FPT_RVM) and domain
separation (FPT_SEP) often used with access control/information flow control, they
are also grouped into SFR package for confidentiality.

5.1.3 Integrity
Integrity ensures data from unauthorized modification. For detecting the
compromise of the integrity, SFRs in FCS are usually used to generate hash value for
50

the information content. For example, data authentication (FDP_DAU) ensures the
validity of static data by generating hash values for the information content several
times and comparing the result. Data authentication with identity (FDP_DAU.2) is
similar with SFRs for non-repudiation, except it is for static data, while SFRs for
non-repudiation is for data in transmission. Moreover, FDP_DAU emphasizes on the
validity of data, while SFRs for non-repudiation more emphasize on the generator of
data instead of the data content. Enforcing access control and information flow
control policies on user/TSF data (FDP_ITT.1/2, FPT_ITT.1/2) can also help to
prevent the compromise of integrity. There are total 24 SFRs for integrity, which can
be grouped by three phases of protecting integrity: Prevention, monitoring, reaction.
SFR packages for each group are shown in Table 16:
Prevent Integrity
Compromise

Integrity Monitor

Recover From
Integrity Error

User/TSF data inter TOE transfer protection (FDP_ITT.1,

FDP_ITT.2, FPT_ITT.1, FPT_ITT.2), Data authentication
(FDP_DAU), Inter-TSF user data transfer protection
(FDP_UIT.1), TSF data consistency (FPT_TDC.1, FPT_TRC.1),
TSF testing (FPT_TST.1)
User/TSF data inter TOE transfer monitoring (FDP.ITT.3,
FDP_ITT.4, FPT_ITT.3), Store data integrity monitoring
(FDP_SDI.1), Inter-TSF detection of modification (FPT_ITI.1),
Cryptographic key management and operation (FCS_CKM,
FCS_COP)
Stored data integrity monitoring and action (FDP_SDI.2),
Rollback (FDP_ROL), Source/destination data exchange
recovery (FDP_UIT.2, FDP_UIT.3), Inter-TSF detection and
correction of modification (FPT_ITI.2)

Table 16: SFR Packages fr Integrity

5.1.4 Availability
Availability security objective focuses on availability on both TOEs capabilities
and resources, which directly maps with SFRs in resource utilization (FRU) and
protection of TSF (FPT), and is also supported by several other SFR classes:
51

Security management (FMT), protection of TSF (FPT) and TOE access (FTA).
There are total 7 SFRs that support availability, which cover fault toleration, priority
of services, resource quota allocation and exported TSF data availability. It is hard to
define reusable SFR packages for availability since this objective is often satisfied by
independent SFR instead of a group of SFRs. Several observations on the use of SFR
from STs including availability are described in the next paragraph.
Although security products claim the availability is satisfied by SFRs in FMT,
such as management of security attributes (FMT_MSA) and security management
roles (FMT_SMR), it is not serious consideration for achieving availability. Around
44% of security products has requirement on the maximum quota of certain service(s)
that single user or a group of users can use (FRU_RSA.1), which address deny of
service (DoS) attacks. No security products has requirement on ensuring the
provision of minimum quantity of certain resource(s) to be available for single user
or a group of users (FRU_RSA.2), which can be considered as an advance protection
from DoS attacks. Very few products address that each access on resources should
be managed by the priority of the subject, e.g., users, services (FRU_PRS). Many
security products in IC and smart card domain have high requirement on fault
tolerance (FRU_FLT). 11 out of 13 security products ensure that all TOE
capabilities availability when certain failures occur are from IC and smart card
domain. However, most security products with FRU_FLT from other domains only
ensure the key part of TOE capabilities availability. Exported TSF data availability
(FTP_ITA) is selected by 4 security products out of the total 242 security products,
52

where they need to export TSF data such as encrypt key or audit data. It is not usual
to export TSF data to other remote trusted IT products unless the TOE works in a
distributed security system, where security products collaborate in security functions
by sharing the TSF data.

5.1.5 Non-Repudiation
Communication (FCO) targets on non-repudiation security objectives, where the
sender cannot deny the origin of the information (FCO_NRO) and the receiver
cannot deny the receipt of the information (FCO_NRR). SFRs from cryptographic
support (FCS) and/or identification & authentication (FIA), such as key management
(FCS_CKM), key operation (FCS_COP) and user identity (FIA_UID) should also be
included when the security product has non-repudiation requirement. There are total
11 SFRs that support non-repudiation. An important observation in this class is that
security products are more interested in verifying the origin of the information,
compared with verifying the receipt of the information. For example, customer may
want to verify the origin of certificate is from an authorized CA, not attackers. But
on the CA side, it does not need to verify whether customer has receipted the
certificate. All 23 security products that include FCO requirements select SFR in
FCO_NRO family, however, only 6 of them select SFR in FCO_NRR family. 5 out
of these 6 security products are messaging management systems, where the evidence
of sending and receiving messages are both important.

53

Besides the obvious reusable SFR packages with three rigor levels in FCO class,
we can also group SFRs in FCS and FIA into two levels as shown in the Table 17
and Table 18.
Level 1
FCO_NRO.1/FCO_NRO.1

Level 2
FCO_NRO.1, FCO_NRR.1

Level 3
FCO_NRO.2, FCO_NRR.2

Table 17: SFR Packages for Non-Repudiation (Part 1)

Level 1
FIA_UID.1/FIA_UID.2

Level 2
FIA.UID.1/FIA_UID.2, FCS_COP.1,
FCS_CKM.1, FCS_CKM.4

Table 18: SFR Packages for Non-Repudiation (Part 2)

The SFR set for non-repudiation can be a combination of one SFR package in table
and one SFR package in table. The variation of selecting SFRs in FCS class can be
referring to section 5.1.2.

5.1.6 Security Management

Security management provides users capabilities of management of TSF in several
aspects: TSF data, security attributes and functions. As shown in table 4, security
management security objective is satisfied by one specific CC SFR class, security
management (FMT). There are total 13 SFRs that support security management.
There is no clear reuse SFR package for this security objective because security
products have many choices in TSF management mechanisms. The rest of this
section discusses some observations on the used pattern of SFRs in FMT.

FMT_MTD addresses the aspect of managing TSF data (e.g., audit record or time
stamp). Around 62% security products choose requirements in this family.
Among these security products, more than 85% of them only choose the basic
54

requirement, which allows users with certain roles to manage the values of TSF
data (FMT_MTD.1). Around 10% of them also has requirement of management
of limits on TSF data (FMT_MTD.2). Around 5% of them also has requirement
on secure TSF data (FMT_MTD.3).

Management of security attributes (FMT_MSA), security attributes revocation

(FMT_REV) and security attributes expiration (FMT_SAE) address the aspect of
managing security attributes (e.g., users role, group that user belongs).
Management of security attributes (FMT_MSA.1) and static attribute
initialization (FMT_MSA.3) are included in around 70% of security products,
30% of which also has the requirement that the values assigned to security
attributes should remain TOE in a secure state (FMT_MSA.2). FMT_REV is
mainly used in security products in database and operating system domain, which
restricts the role to revoke security attributes associated with subjects/objects
under what conditions (e.g., the next login of user). Around 5% of security
products has requirement to enforce time limits for the validity of security
attributes (FMT_SAE), which also requires reliable time stamp (FPT_STM).

Management of functions in TSF (FMT_MOF) addresses the aspect of managing

TSF functions. It allows authorized users to switch on/off TSF functions and/or
modify TSF function behaviors. Around 50% security products use FMT_MOF.1.

Security management role (FMT_SMR) is defined as a dependency requirement

for any other SFRs in FMT. However, certain TOEs may not include FMT_SMR
55

because it only has one user role that is the authorized users. In this case, TOE
often physically protected and only an authorized user (the administrator) has
access to the TOE. Hence, for security products not including FMT_SMR
requirement, they also do not include requirement for authentication (FIA_UAU).

Specification of management functions (FMT_SMF) is new defined SFR in CC

version 2.3 [13] compared with CC version 2.1 [12]. It requires PP/ST author to
specify the management functions to be provided by the TSF in three aspects as
stated above. However, in authors opinion, it is more like a requirement for
documentation than a SFR.

5.1.7 Privacy
Privacy security objective also concerns on information disclosure and is directly
supported by FPR class in CC. There are total 10 SFRs in FPR class. The major
difference is the type of data being protected. FDP focuses on the user data and FTP
focuses on TSF data. FPR, however, focuses on the non-disclosure of user identity or
non-observability of user actions to other users/subjects and/or TSF. The use of SFRs
for privacy focuses on two aspects: Pseudonymity (FPR_PSE) and unobservability
(FPR_UNO). Pseudonymity is usually used in security products sit on network
boundary, which have requirement of hiding internal network address to outside
users/computers. Unobservability is usually used in security products in smart card
domain, which require the unboservability of functions such as cryptographic key
operation, access control functions by users through the use of security product.
56

5.1.8 Accountability
Audit (FAU) is directly mapping to accountability as shown in table 4. There are
total 11 SFRs in FAU. Audit provides tracking evidence on user behaviors and
system status, which can be also used in system performance analysis or intrusion
detection purposes. Hence it has indirectly contributions to other security objectives,
such as intrusion detection and response. Audit data can also be used as report to
users as evidence for successfully fulfilled actions.
Three levels of packages of SFR requirements are shown in Table 19:
Level 1
Level 2

Level 3

Audit data generation and review (FAU_GEN.1)

Audit review (FAU_SAR.1)
Audit data generation associated with user identity FAU_GEN.1,
FAU_GEN.2 Selectable audit review FAU_SAR.1, FAU_SAR.3
Protected audit data and prevention of data loss FAU_STG.1,
FAU_STG.4
Audit data generation associated with user identity FAU_GEN.1,
FAU_GEN.2 Selectable and restricted audit review FAU_SAR.1,
FAU_SAR.2, FAU_SAR.3 Protected audit data and prevention,
action of data loss FAU_STG.1, FAU_STG.2,
FAU_STG.3/FAU_STG.4

Table 19: SFR Packages for Accountability

5.1.9 Recoverability
Recoverability is a corrective security objective compared with preventive security
objectives such as authentication and authorization. There are total 10 SFRs satisfy
recoverability, which fall into two SFR classes: FDP and FPT.

57

Data
recoverability
TSF
recoverability

Rollback (FDP_ROL.1, FDP_ROL.2); stored data integrity

monitoring and action (FDP_SDI.2); inter-TSF exchange user
data recovery (FDP_UIT.2, FDP_UIT.3); inter-TSF TSF data
detection and correction of modification (FPT_ITI.2)
Failure with preservation of secure state (FPT_FLS.1) Trusted
recovery (FPT_RCV.1, FPT_RCV.2, FPT_RCV.3, FPT_RCV.4)

Table 20: SFR Packages for Recoverability

Table 20 lists the SFRs for data recoverability and SFRs for TSF recoverability.
There are correlations between integrity and data recoverability. Once the
compromise of integrity is detected, the correction actions to recover the integrity
belong to data recoverability. FDP_UIT and FPT_ITI address the recoverability of
user data and TSF data separately. In the aspect of TSF recoverability, the TSF shall
manually or automatically ensure TOE return to a secure state (FPT_RCV.1,
FPT_RCV.2). For stronger recoverability, the TSF shall not lose TSF/user data in the
recovery process (FPT_RCV.3). It also specifies requirement that TSF shall ensure
that a list of security functions should be either completed successfully or return to a
secure state when certain failures happen (FPT_RCV.4), such as physical damage,
power off, etc. Failure with preservation of secure date (FPT_FLS.1) provides a precondition for TSF to maintain in the valid mode without being compromised. TSF
self-testing (FPT_TST) is often used with FPT_RCV since it is required for testing
whether TSF is in secure state and TSF data is in a consistent state.

5.1.10 Intrusion Detection and Response

Intrusion detection and response is a detective security objective, which detects
potential attacks and abnormal system behaviors and makes manual or automatic
responses.
58

Table 21 lists the SFRs defined in CC that map to this security objective.
Intrusion
Detection
Intrusion
Response

Potential violation analysis, profile based anomaly detection and

simple/complex attack heuristics (FAU_SAA); passive detection
of physical attack (FPT_PHP.1); notification of physical attack
(FPT_PHP.2); replay detection (FPT_RPL);
Security audit automatic response (FAU_ARP); resistance to
physical attack (FPT_PHP.3); TSF or user initiated session
locking (FTA_SSL.1, FTA_SSL.2); TSF initiated session
termination (FTA_SSL.3), TOE session establishment
(FTA_TSE.1)

Table 21: SFR Packages for Intrusion Detection and Response

Intrusion detection and response (ID&R) is not a common security objective,
hence few security products have high requirement in ID&R except security products
in detection devices and systems domain. In this domain, most security products
include SFRs in an explicated defined SFR class called IDS (Intrusion detection
system

components

requirement),

which

contains

requirements

on

system/sensor/scanner data collection (IDS_SDC.1, IDS_COL.1, IDS_SCN.1),

analyser

analysis/react

(IDS_ANL.1,

IDS_RCT.1),

restricted

data

review

(IDS_RDR.1) and guarantee of system data (IDS_STG.1/2). Since these 8 SFRs are
explicitly stated, I dont count them into the total SFRs for ID&R except in the case
when the majority of security products in a particular domain select this class. An
example is Detection Devices domain, which will be discussed later in section 5.2.5.
As shown in table 17, there are also total 13 SFRs defined in CC for satisfying this
security objective. FAU_ARP and FAU_SAA, although they are from security audit
class (FAU), they are about security audit data analysis and automatic response,
hence are grouped into SFR package for intrusion detection and response. TSF
59

physical protection (FPT_PHP) detects and resists to physical attacks that launch on
TSF. Replay detection (FPT_RPL) is to detect a special type of attack: replay attack,
which tries to resend legal messages or service requests and portends that they are
sent from authorized users. Session locking from TOE access class (FTA_SSL) is to
lock or terminate user sessions when any attack is detected.

5.1.11 SFRs Correlations

Developers very seldom implement all SFRs in one single component because it
obviously has low cohesion for it. However, a much harder question is: Which SFRs
should be implemented in one component and which SFRs should be implemented in
different components? In this section, I will try to answer this question based on the
statistics analysis of SFRs in 242 security products.
Arc is a free statistical analysis tool for regression problems developed by
University of Minnesota [3]. I use this tool for all the regression analysis in this
research because it has enough functions for my purpose and is well used in the
academy world. I will skip the detailed input files and raw output from Arc, and only
show part of my input files as example and the formatted result from the raw output.
Please refer to [16] for instructions in using this tool.
The first step is to analysis the correlations among different SFR classes defined in
CC. Figure 11 shows the structure of the SFR classes dataset and part of the data,
which is used as input files for Arc. Each row represents a security product and 242
security products are included in this analysis. The Project column indicates the
60

domain of the security product. Each column from FAU to FTP represents the
number of SFRs in one SFR class (e.g., FAU) in a security product.
CaseNum
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Project
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
BPDS
BPDS
BPDS
BPDS
BPDS
BPDS
BPDS

FAU FCO FCS FDP FIA FMT FPR FPT FRU FTA FTP
0
0
1
3
3
6
0
2
0
0
1
0
0
1
3
3
4
0
2
0
0
1
1
0
0
0
5
1
0
3
0
1
0
6
0
6
4
10
8
0
3
0
0
1
6
0
0
2
0
4
0
0
0
0
0
0
0
8
4
2
6
0
0
0
0
0
0
0
0
2
2
1
0
3
0
0
0
6
0
0
3
7
6
0
5
0
2
0
7
0
0
2
6
6
0
0
0
0
0
6
0
1
3
5
4
0
2
0
0
0
3
1
0
2
3
4
0
7
0
0
0
2
0
0
4
0
8
0
1
0
0
0
6
0
0
6
3
9
2
3
0
0
0
5
0
0
4
3
4
0
3
0
0
0
3
0
0
5
3
5
0
3
0
0
0
5
0
0
8
0
14
0
1
0
0
0
5
0
0
8
0
9
0
0
0
0
0

Figure 11: Dataset 1: Number of SFRs by SFR Classes in STs

The correlation among SFR classes from Arc output is shown in Table 22:

FAU
FCO
FCS
FDP
FIA
FMT
FPR
FPT
FRU
FTA
FTP
Avg

FAU
1.00
-0.06
-0.12
0.10
0.32
0.38
0.02
0.15
0.11
0.30
-0.04
0.20

FCO FCS
-0.06 -0.12
1.00 0.15
0.15 1.00
0.35 0.54
0.31 0.34
0.12 0.34
0.27 0.24
0.17 0.37
0.09 0.09
0.05 0.09
0.15 0.41
0.24 0.31

FDP
0.10
0.35
0.54
1.00
0.47
0.45
0.41
0.57
0.17
0.08
0.52
0.42

FIA
0.32
0.31
0.34
0.47
1.00
0.51
0.28
0.42
-0.03
0.24
0.28
0.38

FMT FPR
0.38 0.02
0.12 0.27
0.34 0.24
0.45 0.41
0.51 0.28
1.00 0.21
0.21 1.00
0.32 0.38
0.12 0.16
0.43 -0.03
0.28 0.04
0.38 0.27

FPT
0.15
0.17
0.37
0.57
0.42
0.32
0.38
1.00
0.22
0.13
0.45
0.38

FRU FTA
0.11 0.30
0.09 0.05
0.09 0.09
0.17 0.08
-0.03 0.24
0.12 0.43
0.16 -0.03
0.22 0.13
1.00 0.21
0.21 1.00
0.11 0.10
0.20 0.24

FTP
-0.04
0.15
0.41
0.52
0.28
0.28
0.04
0.45
0.11
0.10
1.00
0.30

Table 22: Correlations Among SFR Classes

Some SFR classes with relatively high correlations are:
61

FDP vs. FCS: SFRs in FDP targets on user data confidentiality or integrity,
which requires encryption in some security products.

FDP vs. FIA: Access control SFRs in FDP require identification and sometimes
authentication.

FDP vs. FMT: Access control SFRs in FDP requires management of roles and
security attributes.

FDP vs. FPT: For security products with high expectation on data confidentiality,
SFRs in FPT such as domain separation (FPT_SEP_ and reference mediation
(FPT_RVM) are required.

FDP vs. FTP: For security products where there are communications from
remote users or other IT-trusted products, it is important to have secure
channels/path between for these communications.

FIA vs. FMT: Since password is one of the security attributes, SFRs in FIA class
such as authentication requirement also need requirement of security attributes
management in FMT.
The last row in the table shows the average correlation value for each SFR class.

Some SFR classes such as FAU, FCO, FPR, and FRU have relatively low correlation
compared with others. However, the correlation among different SFR classes is not
obvious since the highest correlation value is around 0.57. For developers that are
not familiar with CC, the correlations among SFR classes may look less meaningful.
62

Another observation is that most correlations are related with SFR class FDP. The
major reason is that the SFRs in FDP cover confidentiality, integrity and
recoverability of user data; hence it is more easily correlated with other SFR classes.
To discover the correlations among SFRs further, the second dataset is created based
on table in section 2.2.3.1. Instead of grouping SFRs as classes defined in CC, SFRs
are grouped for each security objective in this dataset. In Figure 12, each row and the
first two columns have the same meaning as which in Figure 11. Each column from
I&A to IDR represents the number of SFRs for each security objective (e.g.,
Identification and Authentication) that are included in a security product.
CaseNum
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Project
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
ACDS
BPDS
BPDS
BPDS
BPDS
BPDS
BPDS

I&A
3
3
5
10
0
2
2
7
6
5
3
0
3
3
3
0

Conf Integ Ava Non-R SM Priv Acc Rec IDR

8
3
0
0
6
0
0
0
0
8
3
0
0
4
0
0
0
0
3
0
0
0
1
0
2
0
0
15
8
0
0
8
0
8
0
0
2
0
0
0
4
0
4
0
2
13
0
0
0
6
0
0
0
0
5
0
0
0
1
0
0
0
1
6
0
0
0
6
0
8
0
1
3
0
0
0
6
0
8
0
0
7
3
0
0
4
0
7
0
0
7
2
0
3
4
0
3
1
0
5
2
0
0
8
0
1
0
1
9
0
0
0
9
2
7
0
0
7
0
0
0
4
0
4
0
2
8
0
0
0
5
0
4
0
0
9
2
0
0 14
0
4
0
1

Figure 12: Dataset 2: Number of SFRs by SO in STs

Several notes on the creation of this dataset are listed:

Identification & authentication, security management and privacy have one to

one relationship to FIA, FMT and FPR, hence data in this dataset for these three
63

security objectives are the same as those for FIA, FMT and FPR in the first
dataset.

Only SFRs that directly support each security objective are counted to obviate
the false-correlation.

Although reference mediation (FPT_RVM) and domain separation (FPT_SEP)

indirectly support all security objectives, they are more closely related with
confidentiality because they enforce security policies (Access control policies in
most cases) to be un-obviated and separate the part of TSF enforcing security
policies from other parts. Hence these two SFRs are included in the count of
number of SFRs for confidentiality.

There are 6 SFRs that do not directly support any of the security objectives,
hence are not included in this dataset: Abstract machine testing (FPT_AMT),
state synchrony protocol (FPT_SSP), limitation on scope of selectable attributes
(FTA_LSA), limitation on multiple concurrent sessions (FTA_MCS), TOE
access banners (FTA_TAB), TOE access history (FTA_TAH). These SFRs only
used in few security products, hence should not affect the overall accuracy of the
correlation observation result. The user of these SFRs will be discussed
specifically when exploring security requirement patterns in each security
product domain in section 6.
Since this dataset is not directly derived from the STs, the correctness of it needs to

be verified. Security objectives for security product can be found in section 3 of ST,
but they are represented very differently since CC does not provide a standard in
64

defining

security

objectives.

For

example,

one

security

product

has

O.Access_control, while the other has O.confidentiality. However, security objective

for each TOE still be able to derived based on the used keywords such as
identification, confidentiality and integrity in them. The result table is then compared
with the second dataset for the differences in selected security objectives. There is a
100% match for all the security objectives except for integrity,

FDP_ITT.1 and FPT_ITT.1 are SFRs mapping with both confidentiality and
integrity, because they protect inter TOE user/TSF data transfer from disclosure
or modification. However, some security products select FDP_ITT.1 or
FPT_ITT.1 only for confidentiality, which causes the mistakes in identifying
integrity as security objectives in some security products. There are around 15%
of security products are misidentified to include integrity as security objective. It
wont have big effect on the dataset since it only cause one SFR difference.
The correlations among security objectives are shown in table below:

I&A
CONF
INTEG
AVA
NON-R
SM
PRIV
ACC
REC
IDR
Avg

I&A
1.00
0.53
0.39
-0.05
0.34
0.51
0.28
0.29
0.38
0.22
0.39

CONF INTEG AVA

0.53
0.39
-0.05
1.00
0.87
0.16
0.87
1.00
0.21
0.16
0.21
1.00
0.43
0.46
0.09
0.53
0.39
0.09
0.38
0.38
0.12
-0.01 -0.13
0.04
0.60
0.58
0.13
0.26
0.29
0.09
0.48
0.44
0.19

NON-R
0.34
0.43
0.46
0.09
1.00
0.18
0.46
-0.11
0.36
0.11
0.33

SM
0.51
0.53
0.39
0.09
0.18
1.00
0.21
0.37
0.26
0.16
0.37

PRIV
0.28
0.38
0.38
0.12
0.46
0.21
1.00
-0.08
0.34
0.28
0.34

ACC
0.29
-0.01
-0.13
0.04
-0.11
0.37
-0.08
1.00
-0.13
0.06
0.13

REC
0.38
0.60
0.58
0.13
0.36
0.26
0.34
-0.13
1.00
0.30
0.38

IDR
0.22
0.26
0.29
0.09
0.11
0.16
0.28
0.06
0.30
1.00
0.28

Table 23: Correlations Among Security Objectives

65

We can see that there are some higher correlations among SFRs if they are
grouped by security objectives. With consideration in correlations among SFR
classes and security objectives, some rules for design can be derived as following:

In most cases, SFRs for access control are dependent on SFRs for identification&
authentication.

It is OK to have all SFRs support confidentiality implemented in one component.

However, when a security product needs to provide both confidentiality and
integrity, it should consider SFRs for encryption (FCS) since they support both
security objectives. In these cases, SFRs for encryption should be implemented in
the different component with other SFRs that support confidentiality or integrity.

Data recovery is one aspect of recoverability and can be satisfied by some

SFRs.that also support integrity. In the cases where security products include
both recoverability and integrity, SFRs for data recovery should be implemented
in a different component with SFRs for function recovery.

Security management SFRs can be implemented in the same component with

SFRs for confidentiality of integrity. It is true in most security products in our
dataset.

SFRs for availability, non-repudiation, privacy, accountability and intrusion

detection & response have relatively low correlation with other security
objectives, which matches with the previous correlation result for FAU, FCO,
66

FPR and FRU class. Hence SFRs for each of these security objectives can be
implemented in one component, without having many coupling relationship with
other components.
It is also interesting to see what the correlations among security objectives are for
different security product domains. For those domains with relatively large number
of security products, I ran the same analysis on them and got the results as shown in
the tables below:

I&A
CONF
INTEG
AVA
NON-R
SM
PRIV
ACC
REC
IDR

I&A
1.00
0.57
0.04
-0.13
0.00
0.15
-0.05
0.70
0.00
0.23

CONF INTEG AVA

0.57
0.04
-0.13
1.00
0.72
0.31
0.72
1.00
0.70
0.31
0.70
1.00
-0.04
0.05
-0.02
0.32
0.16
-0.01
0.05
-0.08 -0.03
0.42
-0.07 -0.11
-0.04
0.05
-0.02
0.46
0.33
-0.10

NON-R
0.00
-0.04
0.05
-0.02
1.00
-0.09
-0.03
-0.11
1.00
-0.10

SM
0.15
0.32
0.16
-0.01
-0.09
1.00
0.26
0.33
-0.09
0.16

PRIV
-0.05
0.05
-0.08
-0.03
-0.03
0.26
1.00
0.18
-0.03
0.11

ACC
0.70
0.42
-0.07
-0.11
-0.11
0.33
0.18
1.00
-0.11
0.24

REC
0.00
-0.04
0.05
-0.02
1.00
-0.09
-0.03
-0.11
1.00
-0.10

IDR
0.23
0.46
0.33
-0.10
-0.10
0.16
0.11
0.24
-0.10
1.00

Table 24: Correlations Among Security Objectives in BPDS

I&A
CONF
INTEG
AVA
NON-R
SM
PRIV
ACC
REC
IDR
Avg

I&A
1.00
0.78
0.73
-0.34
0.64
0.75
0.62
0.21
0.60
0.65
0.56

CONF INTEG AVA

0.78
0.73
-0.34
1.00
0.95
-0.08
0.95
1.00
0.03
-0.08
0.03
1.00
0.64
0.66
0.02
0.90
0.87
0.01
0.53
0.55
-0.21
0.10
0.11
0.38
0.81
0.82
0.08
0.49
0.44
-0.27
0.61
0.62
0.06

NON-R
0.64
0.64
0.66
0.02
1.00
0.55
0.63
0.17
0.49
0.18
0.50

SM
0.75
0.90
0.87
0.01
0.55
1.00
0.56
0.13
0.70
0.47
0.59

PRIV
0.62
0.53
0.55
-0.21
0.63
0.56
1.00
0.08
0.33
0.48
0.46

ACC
0.21
0.10
0.11
0.38
0.17
0.13
0.08
1.00
0.21
-0.01
0.24

REC
0.60
0.81
0.82
0.08
0.49
0.70
0.33
0.21
1.00
0.43
0.55

IDR
0.65
0.49
0.44
-0.27
0.18
0.47
0.48
-0.01
0.43
1.00
0.38

Table 25: Correlations Among Security Objectives in ICSCRS

67

I&A
CONF
INTEG
AVA
NON-R
SM
PRIV
ACC
REC
IDR
Avg

I&A
1.00
0.16
-0.06
0.21
-0.16
0.46
0.34
0.80
0.28
0.62
0.36

CONF
0.16
1.00
0.82
0.14
0.09
0.35
0.15
0.29
0.18
0.11
0.33

INTEG AVA
-0.06
0.21
0.82
0.14
1.00
0.00
0.00
1.00
0.18
-0.10
0.09
0.03
0.02
0.21
0.04
0.39
-0.03
0.79
-0.01
0.06
0.21
0.27

NON-R
-0.16
0.09
0.18
-0.10
1.00
0.13
-0.10
-0.03
-0.11
-0.11
0.08

SM
0.46
0.35
0.09
0.03
0.13
1.00
0.23
0.22
0.07
0.19
0.28

PRIV
0.34
0.15
0.02
0.21
-0.10
0.23
1.00
0.31
0.49
0.32
0.30

ACC
0.80
0.29
0.04
0.39
-0.03
0.22
0.31
1.00
0.35
0.56
0.39

REC
0.28
0.18
-0.03
0.79
-0.11
0.07
0.49
0.35
1.00
0.04
0.31

IDR
0.62
0.11
-0.01
0.06
-0.11
0.19
0.32
0.56
0.04
1.00
0.28

Table 26: Correlations Among Security Objectives in NNRDS

I&A
I&A
1.00
CONF 0.37
INTEG 0.30
AVA -0.45
SM
0.61
PRIV -0.17
ACC 0.66
REC 0.23
IDR
0.51
Avg
0.34

CONF INTEG AVA

0.37
0.30
-0.45
1.00
0.93
0.14
0.93
1.00
0.05
0.14
0.05
1.00
0.62
0.51
0.02
-0.08 -0.05
0.07
0.44
0.34
-0.21
0.03
-0.12
0.06
0.58
0.49
0.10
0.45
0.38
0.09

SM
0.61
0.62
0.51
0.02
1.00
-0.12
0.41
0.02
0.76
0.43

PRIV
-0.17
-0.08
-0.05
0.07
-0.12
1.00
-0.09
-0.12
-0.13
0.03

ACC
0.66
0.44
0.34
-0.21
0.41
-0.09
1.00
0.21
0.38
0.35

REC
0.23
0.03
-0.12
0.06
0.02
-0.12
0.21
1.00
0.45
0.20

IDR
0.51
0.58
0.49
0.10
0.76
-0.13
0.38
0.45
1.00
0.46

Table 27: Correlations Among Security Objectives in OS

In Table 27, there are no correlations between non-repudiation with other security
objectives because none of the security products in OS domain has non-repudiation
as security objective. Some observations are discussed as following:

The high correlation between confidentiality and integrity happens in every

domain, which matches our result with the previous correlation analysis result
using the whole dataset.

Accountability is used in a high percentage of security products in BPDS,

NNRDS and OS domains. Hence, in these domains, we can see a relatively high
correlation between identification& authentication and accountability, which
does not show in the previous correlation analysis result.
68

The high correlations from non-repudiation and recoverability are only shown in
ICSCRS, which is because they are used in many security products in this
domain. The high correlations between non-repudiation with confidentiality and
integrity do not seem reasonable for me since there is no theories support for
them.

The high correlation between recoverability and availability is shown in NNRDS

domain. Security products in this domain tend to have these two security
objectives at the same time.

5.2 SFR Patterns in Domains

5.2.1 Access Control Devices and Systems (ACDS)
Number of data points: 10
Security products in this domain mainly target on identity management,
authentication and access control functionalities. The primary and optional security
objectives for access control devices and systems are shown in table below:
Primary Security
Objectives
Optional Security
Objectives

Identification & authentication, confidentiality,

security management
Accountability, integrity, intrusion detection and
response, recoverability

Table 28: Security Objectives in ACDS

SFR Patterns for primary security objectives are shown in table below:
I&A
ATD.1,
UAU.1/UAU.2,
UID.1/UID.2

Confidentiality
FCS_COP.1,
FDP_ACC.1/2,
FDP_ACF.1, FPT_RVM.1

Security
Management
MSA.1, MSA.3,
MTD.1, REV.1,
SMR.1, SMF.1

Table 29: SFR Patterns for Primary Security Objectives in ACDS

69

Although majority security products include SFRs in FIA class to achieve

identification and authentication objective, there is exceptional case that security
product targets on cryptographic functions to achieve access control. Another
exceptional case is that security product requires users to provide smart card for
authentication purpose. Security pattern in confidentiality is relatively clear
comparing with other security objectives. Security product
60% of security products have accountability as one of their security objectives.
However, there are no clear patterns shown in the use of this security objective,
except all of them include audit data generation (FAU_GEN). Four security products
in this domain use the same SFRs (FCS_COP, FDP_ITT, FPT_ITT) to achieve
integrity with those to achieve confidentiality. One security product uses audit data
automatically analysis and response (FAU_ARP.1 and FAU_SAA.1). Two other
security products use physically protection (FPT_PHP). These SFRs support security
objective intrusion detection and response. For recoverability, only one security
product in this domain has requirement on failure with preservation of secure state
(FPT_FLS.1).

5.2.2 Boundary Protection Devices and Systems (BPDS)

Number of data points: 42
Security products in this domain sit on the boundary of network to provide
protection on resources inside the network. Examples of security products are
Firewall, email filter and secure switch/routers. Among 42 security products in this
70

domain, 40 of them are firewalls. 1 security products is designed for controlling

information flow, which can be treated as a very simplified firewall. 1 security
product is a mechanic switch that controls the connection between two separate
networks. Although some elder version of firewall may rely IT-environment or
physical environment for identification & authentication or security management,
identification & authentication is necessary for protecting security policies defined in
firewall. The primary and optional security objectives for firewall are shown in table:
Primary Security
Objectives
Optional Security
Objectives

Identification & authentication, confidentiality, security

management, accountability
Integrity, intrusion detection and response, availability,
recoverability, non-repudiation

Table 30: Security Objectives in BPDS

Considering the BBDS domain contains a relatively huge number of STs compared
with other domains, I am able to do multiple analyses on this dataset. Firstly, instead
of only analyzing the whole dataset, I randomly group 42 STs into three sets, each
set contain 14 STs. Pattern 1 is derived by set 1 plus set 2; pattern 2 is derived by set
2 plus set 3; and pattern 3 is derived by set 1 plus set 3. Because SFRs for optional
security objectives are only selected on minority of STs, there is no need to analysis
them using different sets. SFR patterns are explored in primary security objectives,
which are selected in majority of STs.

71

The results are shown in table below:

I&A

Confidentiality

Pattern
1

ATD.1,
UAU.1/UAU.2,
UID.1/UID.2

Pattern
2

AFL.1, ATD.1,
UAU.1/UAU.2,
UID.1/UID.2

Pattern
3

N/A

FDP_IFC.1,
FDP_IFF.1,
FPT_RVM.1,
FPT_SEP.1
FDP_IFC.1,
FDP_IFF.1,
FPT_RVM.1,
FPT_SEP.1
FDP_IFC.1,
FDP_IFF.1,
FPT_RVM.1,
FPT_SEP.1

Security
Management
MOF.1,
MSA.1,
MSA.3, SMR.1
MOF.1,
MSA.1,
MSA.3,
SMR.1, MTD.1
MOF.1,
MSA.1,
MSA.3,
SMR.1, MTD.1

Accountability
GEN.1, SAR.1,
SAR.3,
STG.3/STG.4,
FPT_STM.1
GEN.1, SAR.1,
SAR.3, STG.1,
STG.3/STG.4,
FPT_STM.1
FAU_GEN.1,
FAU_SAR.1,
FAU_SAR.3,
FPT_STM.1

Table 31: SFR Patterns for Primary Security Objectives in BPDS

Identification and Authentication: The big difference of SFR pattern for these sets is
because many STs in set 1 and set 3 are elder version of firewalls, which tend to rely
on IT-environment or physical protection for identification & authentication.
Firewall should have requirement of basic identification and authentication, and
maintain the list of security attributes of users.
Confidentiality: SFR patterns for confidentiality are consistent in three sets. Firewall
should

provide

information

flow

policy

and

function

to

control

the

inbound/outbound flow mediation. It also needs to ensure the non-bypassability of

the information flow functions. TSF needs to maintain a separate domain that
protects it from being compromised by un-trusted users.
Security Management: Management of functions in TSF, static initiation and
management of security attributes, management of security roles and management of
TSF data are required in this domain for security management.
72

Accountability: Audit generation without user identity, audit data selectable review
and reliable time stamps appear in patterns in all three sets. It is recommended to has
requirement of action in cases of audit data loss or prevention of audit data loss.
For SFR patterns in optional security objectives, this paragraph provides some
observations on them. Around 30% security products have basic requirement on
intrusion detection and response: Potential violation analysis (FAU_SAA.1) and
alarm response (FAU_ARP.1). Around 10% security products have basic
requirement on preventing compromise of integrity, which selects internal TOE
transfer (FDP_ITT.1) and/or internal TOE TSF data transfer (FPT_ITT.1). Less than
10% of security products have requirements in integrity by protecting data exchange
integrity from TSF and other trusted-IT products (FDP_UIT.1).

Availability,

recoverability, and non-repudiation are rare security objectives to be selected in

firewalls. Only one security product has availability, which requires the operation of
all TOE capabilities with certain failures (FRU_FLT.2). Only two security products
have requirement on failure with preservation of secure state (FPT_FLS.1), and one
of them also has requirement on automatically recovering to a secure state
(FPT_RCV.2). The same product also has the requirement that the decision part
needs to prove the origin of the message came from policy server (FCO_NRO.2),
because the firewall policy server sits on a different host with the part that makes
decisions. This security product obviously has stronger treatment than others on
threats that target on firewall itself instead of what the firewall protects.

73

For the 6 SFRs that are not covered by SFR packages for security objectives
defined in section 5, none of them are selected in this domain except that abstract
machine testing (FPT_AMT.1) is used in less than 3% of security products.

5.2.3 Database (DB)

Number of data points: 11
Security products in this domain facilitate the creation and maintenance of a
database or databases in a secured manner, and the execution of computer programs
using the database or databases. A Database is defined as a set of data that is required
for a specific purpose or is fundamental to a system, project, or enterprise. Security
products in this domain run as an application on operating system. The primary and
optional security objectives for database domain are shown in table:
Primary Security
Objectives
Optional Security
Objectives

Identification & authentication, confidentiality,

security management, accountability
Availability, recoverability

Table 32: Security Objectives in DB

SFR Patterns for primary security objectives are shown in table below:
I&A

Confidentiality

Security
Management
MSA.1,
ATD.1,
FDP_ACC.1/
MSA.3,
UAU.1/UAU.2, FDP_ACC.2,
MTD.1,
UID.1/UID.2,
FDP_ACF.1,
USB.1
FDP_RIP.1/ FDP_RIP.2, REV.1,
SMR.1, SMF.1
FPT_SEP.1,
FPT_RVM.1

Accountability
GEN.1,
GEN.2,
SAR.1,
SAR.3, SEL.1
STG.1,
STG.3/STG.4,

Table 33: SFR Patterns for Primary Security Objectives in DB

6 out of 11 security products has requirement on limitation on the maximum quota
of resources that subjects can use (FRU_RSA.1), which supports availability. For
74

recoverability, one product has requirement on basic rollback (FDP_ROL.1), which

allows rollback of operations with certain boundaries or limits. Another product has
stronger recoverability, where it includes advanced rollback (FDP_ROL.2), which
permits the rollback of all the operations on a certain list of objects, and function
recovery (FPT_RCV.4).
FAU_GEN.2 should be excluded if the system has privacy requirement of no
exposure of users identities. No clear pattern shown in audit data logging. However,
no security products in this domain choose FAU_STG.2, which guarantees of audit
data availability. FAU_SAR.2 should be excluded if any user can have read access to
part of the audit data if not all. Only one security product selects FDP_ITC and
FDP_ETC. It provides secured import and export operations that allow user to load
data to database, and extract data from database to a certain form of file.
FIA_AFL.1 (authentication failures) and FIA_SOS.1 (specification of secrets) are
optional requirements to increase strength of function when implementing user
authentication function. Only one security product does not have user identification
function, but it still implements FIA_ATD.1, which defines and maintains user
security attributes.
FMT_SMF.1 is a new SFR defined in CCv2.3. It allows TOE to provide the
specification of the management functions, security attribute management, TSF data
management, or security function management.

75

For the 6 SFRs that are not covered by SFR packages for security objectives
defined in section 5, none of them are selected in this domain except that basic
limitation on multiple concurrent sessions (FTA_MCS.1) is used in 5 security
products. Some security products also have requirement on relying TSF to deny the
session establishment based on certain criteria (FTA_TSE.1).

5.2.4 Data Protection (DP)

Number of data points: 16
Security products in this domain provide three main levels of protection for data:
Basic encryption, advanced encryption and secure erase. Basic encryption is mainly
used for protecting confidentiality of the existing data. Advanced encryption address
confidentiality and integrity of the existing data. Secure erase targets on the
confidentiality of data that is no longer in use hence it does not care about the
accessibility of data. Since encryption is included in many security products in this
domain, the major threats for them are highly related with the cryptographic keys:
Key disclosure, key derive, key distortion, crypto forgery (forge output data like
digital signature), incomplete overwrite, eavesdrop, etc. The primary and optional
security objectives for data protection domain are shown in table:
Primary Security
Objectives
Optional Security
Objectives

Identification & authentication, confidentiality, security

management
Integrity, availability, accountability, recoverability,
ID&R

Table 34: Security Objectives in DP

76

SFR Patterns for primary security objectives are shown in table below:
I&A
UAU.1/UAU.2,
UID.1/UID.2

Confidentiality
FCS_COP.1, FCS_CKM.1,
FCS_CKM.4, FDP_ACC.1/
FDP_ACC.2, FDP_ACF.1,

Security
Management
MOF.1, MSA.1,
MSA.2, MSA.3,
SMR.1

Table 35: SFR Patterns for Primary Security Objectives in DP

Most security products in this domain have basic requirements on identification&
authentication security objective. For around 30% of security products,
authentication failure handling (FIA_AFL.1), user attribute definition (FIA_ATD.1),
verification of secrets (FIA_SOS.1), and protected authentication feedback
(FIA_UAU.7) are also selected for identification& authentication for achieving
stronger security mechanisms. Confidentiality is mainly achieved by encryption
requirements in this domain as we can see in the table. Security management is
focused on management of security functions (FMT_MOF.1), security attributes
management (FMT_MSA) and management of security roles (FMT_SMR.1).
Around 20% security projects have accountability security objective, mainly
achieved by security audit data generation (FAU_GEN), security audit review
(FAU_SAR) and security audit event storage (FAU_STG). Around 30% security
projects have intrusion detection & response security objective, which is achieved by
TSF physical protection (FPT_PHP), replay detection (FPT_RPL) or user session
locking (FPT_SSL). Availability is seldom considered in security products in this
domain. Only two security products have availability, and they both select fail secure
(FPT_FLS) and fault tolerance (FRU_FLT) for achieving availability security
objective. Around 30% security products have recoverability security objective,
77

which is achieved by trusted recovery (FPT_RCV) and stored data integrity

monitoring and action (FDP_SDI.2). Integrity is chosen in around 50% security
products in this domain and is partly achieved by SFRs for confidentiality, such as
encryption SFRs: FCS_COP, FCS_CKM, and SFRs for recoverability, such as
FDP_SDI.2.
For the 6 SFRs that are not covered by SFR packages for security objectives
defined in section 5, abstract machine testing (FPT_AMT) is used by 25% of
security products. TOE access banners (FTA_TAB) and TOE access history
(FTA_TAH) are used in one security product to fulfill special application needs.

5.2.5 Detection Devices (DD)

Number of data points: 7
Security products in this domain emphasize on detecting attacks or abnormalities
by observing system behavior or collecting network packets. Security products
usually have two main functionalities: Collect security audit data and analyze
security audit data. The primary and optional security objectives for data protection
domain are shown in table below:
Primary Security
Objectives
Optional Security
Objectives

Identification & authentication, security management,

accountability, ID&R
Confidentiality, integrity, availability

Table 36: Security Objectives in DD

78

SFR Patterns for primary security objectives are shown in table below:
I&A

Security
Management
MOF.1, MTD.1,
SMR.1, SMF.1

Accountability

ID&R

IDS_SDC.1,
IDS_ANL.1,
IDS_RCT.1
Table 37: SFR Patterns for Primary Security Objectives in DD

UAU.1/UAU.2,
UID.1/UID.2

GEN.1, SAR.1,
SAR.2, SAR.3,
SEL.1

Most security products in this domain have basic requirements on identification&

authentication security objective. Around 30% security products have additional
SFRs for identification& authentication, which are authentication failure handling
(FIA_AFL.1) and user attribute definition (FIA_ATD.1). For security management,
all security products select management of security functions (FMT_MOF.1) and
management of TSF data (FMT_MTD.1). Most security products also have security
roles

management

(FMT_SMR.1)

and

security

management

functions

(FMT_SMF.1). Only one security product provides security attributes management

by selecting FMT_MSA requirements. Security audit data generation (FAU_GEN)
and security audit review (FAU_SAR) are selected by most security products to
provide functionalities of audit data collection and analysis. Selective audit
(FAU_SEL.1) is also selected by many security products to filter the irrelevant
events, hence to increase the efficient in detecting valid attacks. There is a special
case for intrusion detection& response security objective in this domain. It is
satisfied by an explicated SFR class IDS (Intrusion detection system components
requirement), which is not defined in CC as discussed in section 5.1.10. Most
security products select which contains requirements on system data collection

79

(IDS_SDC.1); analyser analysis (IDS_ANL.1) and analyzer react (IDS_RCT.1) for

achieving ID&R security objective.
Around 30% security products select availability. They want to satisfy a defined
availability metric for inter-TSF exported data (FPT_ITA.1). Around 50% security
products want to protect TSF data confidentiality and integrity by selecting some
SFRs in FPT class, such as confidentiality of exported TSF data (FPT_ITC.1), interTSF detection of modification (FPT_ITI.1), basic internal TSF data transfer
protection (FPT_ITT.1), non-bypassability of the TSP (FPT_RVM.1), TSF domain
separation (FPT_SEP.1) and reliable time stamps (FPT_STM.1).
For the 6 SFRs that are not covered by SFR packages for security objectives
defined in section 5, none of them are selected by security products in this domain.

5.2.6 ICs, Smart Cards & Related Services (ICSCRS)

Number of data points: 36
Security products in this domain are mostly smart cards, which are used to store
sensitive information, such as identification and authentication data. They usually are
portable devices, hence it is important to have some level of physical protection on
them. A well-known example of smart cards is credit card that we almost use
everyday. . The primary and optional security objectives for this domain are shown
in table below:
Primary Security
Objectives
Optional Security
Objectives

Confidentiality, integrity, security management, ID&R

Identification & authentication, availability, nonrepudiation, accountability, recoverability, privacy

Table 38: Security Objectives in ICSCRS

80

Since number of STs in this domain is relatively large, similarly with what I did in
BPDS domain, STs in this domain are grouped into 3 sets. Each set contains 12 STs.
Pattern 1 is derived by set 1 plus set 2; pattern 2 is derived by set 2 plus set 3; and
pattern 3 is derived by set 1 plus set 3. SFR Patterns for primary security objectives
for the combinations of sets are shown in table below:

Pattern
1

Pattern
2

Pattern
3

Confidentiality

Integrity

FCS_CKM.4,
FCS_COP.1,
FDP_ACC.1/2,
FDP_ACF.1,
FDP_IFC.1, FPT_SEP.1
FCS_CKM.1,
FCS_COP.1,
FDP_ACC.1/2,
FDP_ACF.1,
FDP_IFC.1, FPT_SEP.1
FCS_CKM.1,
FCS_CKM.4,
FCS_COP.1,
FDP_ACC.1/2,
FDP_ACF.1,
FDP_IFC.1, FPT_SEP.1

FCS_CKM.4,
FCS_COP.1,
FDP_SDI.1/2,
FPT_TST.1

Security
Management
MSA.1,
MSA.3,
MTD.1,
SMR.1

ID&R
FPT_PHP.3

FCS_CKM.1,
FCS_COP.1,
FDP_SDI.1/2,
FPT_TST.1

MSA.1,
MSA.3,
SMR.1

FPT_PHP.3

FCS_CKM.1,
FCS_CKM.4,
FCS_COP.1,
FDP_SDI.1/2,
FPT_TST.1

MOF.1,
MSA.1,
MSA.3,
MTD.1,
SMR.1

FAU_SAA.1,
FPT_PHP.3

Table 39: SFR Patterns for Primary Security Objectives in ICSCRS

Confidentiality: Three derived patterns for confidentiality all have the same
requirements on access control policies and functions, information flow policies, and
TSF domain separation. The difference is on crypto key management requirements,
whether the TOE has requirements on both crypto key generation and destruction, or
leave the key generation or destruction to the IT environment.
Integrity: SFR patterns for integrity is similar with what looks like in confidentiality.
They include the same SFRs except the difference in FCS_CKM requirement as
discussed in confidentiality.
81

Security Management: Three SFR patterns are quite different for security
management, although they have one commonality on security attributes
management and management of security roles. Pattern 1 has extra requirement on
management of TSF data compared with pattern 2. Pattern 3 has the strongest
security mechanisms among these three patterns, and it also has requirement on
management of TSF functions.
Intrusion Detection& Response: Three derived patterns all include requirement on
physical protection on TSF. Only difference is pattern 3 also includes requirement on
security audit data automatic analysis.
Security products in this domain cover all security objectives discussed in section
5. Besides the 4 primary security objectives that are chosen by majority of security
products, the rest 6 security objectives can be divided into three groups. The first
group includes identification& authentication and recoverability, which are selected
by around 70% of security products. The second group includes availability,
accountability and privacy, which are selected by around 45% of security products.
The third group includes only non-repudiation, which is selected by around 20% of
security products. For security products having identification& authentication, they
have medium to high requirement on it, by having authentication failure handling
(FIA_AFL.1),

unforgeable

authentication

(FIA_UAU.3)

and

single-use

authentication mechanisms (FIA_UAU.4). Recoverability is mostly achieved by

having failure with preservation of secure state (FPT_FLS.1) and TSF function
recovery (FPT_RCV). Security products in this domain have low requirements on
82

accountability, which having protected audit storage. Many security products in this
domain have requirements on high fault tolerance (FAU_FLT.2) and resource
maximum quotas (FAU_RSA.1). Unobservability (FPR_UNO.1) is also important in
many security products because they dont want users to gain extra information (e.g.,
crypto key) by observing the behaviors of some operations, such as encryption
operations. There are security products also provide the proof of origin for
transmitted information (FCO_NRO). For example, attackers may forge a credit card.
However, the security application is able to recognize that it is a forged one because
it cannot provide the proof of origin that will be accepted by the security application.
For the 6 SFRs that are not covered by SFR packages for security objectives
defined in section 5, abstract machine testing (FPT_AMT.1), limitation on scope of
selectable attributes (FTA_LSA.1) and default TOE access banners (FTA_TAB.1)
are selected by around 5% of security products.

5.2.7 Key Management (KM)

Number of data points: 13
Security products in this domain emphasize on crypto key generation, management,
store and/or assignment. The primary and optional security objectives for data
protection domain are shown in table below:
Primary Security
Objectives
Optional Security
Objectives

Identification & authentication, confidentiality, integrity,

security management, accountability
Availability, non-repudiation, recoverability, ID&R

Table 40: Security Objectives in KM

83

SFR Patterns for primary security objectives are shown in table below:
I&A

Confidentiality

AFL.1,
UAU.1/2,
UID.1/2

FDP_ACC.1/2,
FDP_ACF.1,
FPT_RVM.1

Integrity
N/A

Security
Management
MOF.1,
MTD.1

Accountability
GEN.1,
(GEN.2)

Table 41: SFR Patterns for Primary Security Objectives in KM

Security products in this domain are quite different with each other in selecting
SFRs. Although majority of the security products have the listed primary security
objective shown in the above table, they choose quite different SFRs to achieve them.
There are no clear patterns in these primary security objectives compared with other
domains, which will be shown in the SFR pattern effectiveness analysis in section 6.
For example, there are 10 out of 13 security products have security objective on
integrity. But none of these SFRs, such as stored data integrity monitoring
(FDP_SDI.1) and inter-TSF detection of modification (FPT_ITI.1), which are
selected for achieving integrity, are used by more than 50% of security products.
Security products in this domain achieve confidentiality in all three aspects: Access
control, encryption and residual protection, where access control is used by majority
of security products as shown in the above table.
There are around 50% security products have requirement on non-repudiation of
origin (FCO_NRO.1, 2). These security products have functionalities on assigning
keys; hence provide the evidence for the originator of the keys. Two security
products have TSF manual or automated recovery (FPT_RCV.1, 2) for recoverability.
Around 40% security products have requirement on intrusion detection& response
by selecting SFRs such as TSF physical protection (FPT_PHP.1), replay detection
84

(FPT_RPL.1) and session locking (FTA_SSL). Only one security product selects
failure with preservation of TSF secure state (FPT_FLS.1) and degraded fault
tolerance (FRU.FLT.1) for achieving availability security objective.
For the 6 SFRs that are not covered by SFR packages for security objectives
defined in section 5, only abstract machine testing (FPT_AMT.1) is used by one
security product with availability as security objective.

5.2.8 Network and Network Related Devices and Systems

(NNRDS)
Number of data points: 28
Security products in this domain are applications securing information and
communication over network, a good example of which is Virtual Private Network
(VPN). This domain has little overlap with two domains discussed before: Boundary
protection devices& systems domain and detection devices domain. Few products in
this domain are hardware-centered, such as router and switch with security
objectives, which is also ok to be included in the boundary protection devices&
systems domain. There are also several security products monitor the status and
events of network to detect potential misbehaviors or attacks, which can also be
grouped into detection devices domain. The rest of security products are like VPN,
which protect the confidentiality and/or integrity of transmitted information over a
public network.

85

The primary and optional security objectives for data protection domain are shown
in table below:
Primary Security
Objectives
Optional Security
Objectives

Identification & authentication, confidentiality,

security management, accountability
Integrity, availability, non-repudiation, recoverability,
ID&R, privacy

Table 42: Security Objectives in NNRDS

Since number of STs in this domain is relatively large, similarly with what I did
before, STs in this domain are grouped into 3 sets. First two sets contain 9 STs and
the third set contains 10 STs. Pattern 1 is derived by set 1 plus set 2; pattern 2 is
derived by set 2 plus set 3; and pattern 3 is derived by set 1 plus set 3. SFR Patterns
for primary security objectives for the combinations of sets are shown in table below:
I&A
Pattern
1
Pattern
2
Pattern
3

ATD.1,
UAU.1/2,
UID.1/2
ATD.1,
UAU.1/2,
UID.1/2
ATD.1,
UAU.1/2,
UID.1/2

Confidentiality
ACC.1/2, ACF.1,
IFC.1/2, IFF.1,
FPT_SEP.1
IFC.1/2, IFF.1,
FPT_RVM.1,
FPT_SEP.1
IFC.1/2, IFF.1,
FPT_RVM.1,
FPT_SEP.1

Security
Management
MOF.1, MSA.1,
MSA.3, MTD.1,
SMR.1
MOF.1, MSA.1,
MTD.1, SMR.1
MOF.1, MSA.1,
MSA.3, MTD.1,
SMR.1, SMF.1

Accountability
FAU_GEN.1,
FAU_SAR.1,
FPT_STM.1
FAU_GEN.1,
FAU_SAR.1,
FPT_STM.1
FAU_GEN.1,
FAU_SAR.1,
FPT_STM.1

Table 43: SFR Patterns for Primary Security Objectives in NNRDS

Identification& Authentication: Three patterns are identical in this security objective.
Requirements on basic identification& authentication and user attributes definition
are selected.
Confidentiality: Pattern 2 and 3 are identical with each other. Pattern 1 has two
differences with them. The first is having requirements on access control policy and
functions. The second is lacking requirement on non-bypassability of the TSP. The
86

major reason is because some security products that derive pattern 2 and 3 are in the
overlap range between this domain and the Boundary Protection Devices and
Systems (BPDS) domain. Hence pattern 2 and 3 for confidentiality in this domain
are identical to the derived patterns for confidentiality in BPDS domain.
Security Management: Three patterns are different with each other for this security
objective except the commonality on management of security functions behavior,
management of security attributes, management of TSF data and security roles
management. Pattern 1 also one more requirement on the static security attribute
initialization. Pattern 3 has the strongest requirement on security management
compared with the rest two patterns. It also includes requirement on specification of
management functions, which allows authorized users to define/modify the attributes
that control security-related operations.
Accountability: Three patterns are consistent in this security objective. Basic audit
data generation and review are selected. TSF also needs to provide a reliable
timestamp to ensure the validity of the generated audit data and add more
information onto it.
Besides the four primary security objectives, security products in this domain
cover all the rest six security objectives. Since security products in this domain are
network-related, it is possible that different parts of TSF are located on different
network nodes. For example, the part of TSF for collecting network information can
be allocated on several network nodes, and the part of TSF for analyzing network
87

information and making decisions is allocated on another network node. Both parts
need to secure the message communicated between them. For this kind of security
products, they often have requirements on inter-TSF user data integrity transfer
protection (FDP_UIT) and/or inter-TSF detection of modification of TSF data
(FPT_ITI). Around 30% of security products also choose cryptographic operations to
achieve integrity. Around 50% of security products have intrusion detection&
response as one of their security objectives. Intrusion detection is mainly achieved by
having requirements on audit data automatic analysis (FAU_SAA) and response
(FAU_ARP), and physical protection of TSF. Intrusion response is mainly achieved
by having requirements on TSF-initiated termination (FTA_SSL.3) and TOE session
establishment (FTA_TSE.1). Two security products select requirements defined in
IDS, which is an explicated SFR class and used by many products in detection
devices domain. Availability, non-repudiation, recoverability and privacy are each
selected by less than 15% of security products. Availability is achieved by selecting
inter-TSF availability within a defined availability metric (FPT_ITA.1), degraded
fault tolerance (FRU_FLT.1) and limited priority of service (FRU_PRS.1). There are
two security products that choose privacy. One has requirement on anonymity
(FPR_ANO.1). The other has requirement on pseudonymity (FPR_PSE.1). Security
products achieve recoverability by selecting basic rollback (FDP_ROL.1), failure
with preservation of secure state (FPT_FLS.1) and manual/automated TSF recovery
(FPT_RCV.1/2). There are two security products selecting enforced proof of origin
(FCO_NRO.2).
88

For the 6 SFRs that are not covered by SFR packages for security objectives
defined in section 5, abstract machine testing (FPT_AMT.1), basic limitation on
multiple concurrent sessions (FTA_MCS.1) and default TOE access banners
(FTA_TAB.1) are selected by few security products.

5.2.9 Operating Systems (OS)

Number of data points: 26
Security products in this domain are mainly different type of operating systems
(OS), such as Windows, Linux, Solaris, IBM i5/OS, etc. For a secure operating
system, one of the critical tasks is to handle user accounts and the privileges
associated with the account, such as file access and change OS configurations.
Accountability is also important for operating system to generate error message and
provide the administrator system log to track the errors. Besides manual detection of
attack by administrators, some operating systems may provide security schemes of
automatic detection of security attack. The primary and optional security objectives
for data protection domain are shown in table below:
Primary Security
Objectives
Optional Security
Objectives

Identification & authentication, confidentiality, security

management, accountability
Integrity, availability, recoverability, ID&R, privacy

Table 44: Security Objectives in OS

Since number of STs in this domain is relatively large, similarly with what I did
before, STs in this domain are grouped into 3 sets. First two sets contain 9 STs and
the third set contains 8 STs. Pattern 1 is derived by set 1 plus set 2; pattern 2 is

89

derived by set 2 plus set 3; and pattern 3 is derived by set 1 plus set 3. SFR Patterns
for primary security objectives for the combinations of sets are shown in table below:

Pattern
1

Pattern
2

Pattern
3

I&A

Confidentiality

ATD.1, SOS.1,
UAU.1/2,
UAU.7,
UID.1/2,
USB.1
ATD.1, SOS.1,
UAU.1/2,
UAU.7,
UID.1/2,
USB.1
ATD.1, SOS.1,
UAU.1/2,
UAU.7,
UID.1/2,
USB.1

FDP_ACC.1/2,
FDP_ACF.1,
FDP_RIP.1/2,
FPT_RVM.1,
FPT_SEP.1
FDP_ACC.1/2,
FDP_ACF.1,
FDP_RIP.1/2,
FPT_RVM.1,
FPT_SEP.1
FDP_ACC.1/2,
FDP_ACF.1,
FDP_RIP.1/2,
FPT_RVM.1,
FPT_SEP.1

Security
Management
MSA.1, MSA.3,
MTD.1, REV.1,
SMR.1, SMF.1
MSA.1, MSA.3,
MTD.1, REV.1,
SMR.1, SMF.1
MSA.1, MSA.3,
MTD.1, REV.1,
SMR.1, SMF.1

Accountability
FAU_GEN.1, 2,
FAU_SAR.1, 2, 3,
FAU_SEL.1,
FAU_STG.1, 3, 4,
FPT_STM.1
FAU_GEN.1, 2,
FAU_SAR.1, 2, 3,
FAU_SEL.1,
FAU_STG.1, 3, 4,
FPT_STM.1
FAU_GEN.1, 2,
FAU_SAR.1, 2, 3,
FAU_SEL.1,
FAU_STG.1, 3, 4,
FPT_STM.1

Table 45: SFR Patterns for Primary Security Objectives in OS

Identification& Authentication: Three patterns are identical in this security objective.
Security products in this domain have medium-high requirement on identification&
authentication by having user attribute definition, verification of secrets and
protected authentication feedback.
Confidentiality: Three patterns are identical in this security objective. Most security
products have access control and residual data protection for achieving
confidentiality. Around 25% of security products also provide encryption
functionalities. Non-bypassability of the TSP and TSF domain separation are also
selected by most of the security products because it is important for operating
systems to separate the running space of critical applications with other user
applications, and enforce the TSP to all the applications.
90

Security Management: Three patterns are identical in this security objective. Security
products in this domain have medium-high requirements on security management.
They need to provide many customizations ways for authorized users (E.g.,
administrator) to adjust the strength of security mechanisms. For example,
administrator may change the privileges of a particular group of users or turn off the
guest account.
Accountability: Three patterns are identical in this security objective. Security
products in this domain have two extremely choices on accountability. They either
do not have accountability as one of its security objectives, or have extremely strong
SFRs for achieving accountability. Security products with accountability as their
security objective have almost every SFRs that are discussed in section 5.1.8 except
guarantees of audit data availability, which is much harder and more expensive to
implement compared with other SFRs.
Integrity is considered in around 30% of security products, which include interTSF user data exchange integrity (FDP_UIT.1) and TSF self-testing (FPT_TST.1).
Encryption requirements are also used for integrity in some security products.
Around 25% of security products select degraded fault tolerance (FRU_FLT.1) or
resource maximum quotas (FRU_RSA.1), which achieve the basic level of
availability. Around 20% of security products have recoverability and intrusion
detection& response as their security objectives, mainly achieved by failure with
preservation of secure state (FPT_FLS.1) and TSF functional recovery (FPT_RCV),
session locking (FTA_SSL) and TOE session establishment (FTA_TOE.1). Only two
91

security products have unobservability, which prohibit the users from exceeding their
privileges by observing some operations, such as encryption operations.
For the 6 SFRs that are not covered by SFR packages for security objectives
defined in section 5, abstract machine testing (FPT_AMT.1) is used in many security
products that have availability or recoverability as their security objectives.
Limitation on scope of selectable attributes (FTA_LSA.1), basic limitation on
multiple concurrent sessions (FTA_MCS.1), default TOE access banners
(FTA_TAB.1), and TOE access history (FTA_TAH.1) are selected by only one or
two security products.

92

Chapter 6: Validation Approach

Validation in this research falls into two major parts:
1. Validation SFR packages and variations defined in section 5
2. Validation SFR patterns discussed in section 6

6.1 SFR Packages Validation

The validation of proposed SFR packages for security objectives is achieved in
section 5.1.11. The first step is to review section 4 in each ST for identifying security
objectives for each product. The result is then compared with the list of security
objectives generated by the proposed SFR packages for security objectives. The
second step of validation is to review the actual used SFR packages for security
objectives described in section 6 in each ST, and compare them with the SFR
packages proposed in section 5. Validations results show that there are no
inconsistencies except in the proposed SFR package for integrity. Basic internal user
data transfer protection (FDP_ITT.1) and basic TSF data internal transfer protection
(FPT_ITT.1) are considered in the proposed SFR packages for both confidentiality
and integrity. However, around 15% of security products only consider them for
confidentiality. Please refer 5.1.11 for the details.

93

6.2 SFR Patterns Validation

For domains containing relatively large number of security products (E.g., bigger
than 24), I group them into three sets. Security pattern is then generated using two of
these three sets, and is validated using the third set. Hence three security patterns are
generated for these domains. The effectiveness of these security patterns is evaluated
to help the decision. For domains containing relatively small number of security
products, security pattern is explored using the whole set of security products.
Effectiveness of the security pattern is evaluated as the quality metrics of it.
The effectiveness E is evaluated by checking the difference rate between the
explored security patterns for each security objective with the actual SFR package a
security product uses if it has the corresponding security objective. For example, the
explored pattern is (SFR.A, SFR.B, SFR.C). If the actual used set of SFRs is (SFR.A,
SFR.B) or (SFR.A, SFR.B, SFR.C, SFR.D), the difference D is 1. If the actual used
set of SFRs is (SFR.A, SFR, B, SFR.E), the difference D is 2. Effectiveness of the
SFR pattern for certain security objective can be calculated using the formula:
E j = (1-

i, j

/ (n j * m)) *100%

E j represents for the effectiveness of SFR pattern appears in jth security objective.
It is represented as a percentage number. Di, j represents the difference between this
SFR pattern with the actual used set of SFRs for security product i for security
objective j. nj represents the number of SFR components that are mapping with the jth

94

security objective as defined in section 5. m represents the total number of security

products that are included in this set.
Table shows the j and n that correspond to each security objective as defined in

Integrity

Availability

Non-repudiation

Privacy

Accountability

Recoverability

ID&R

10

14

36

24

11

13

10

11

11

13
(21)

Security
Management

Confidentiality

Identification
&Authentication

section 5.

Table 46: Number of Total SFRs for Supporting Security Objectives

Let us see an example for testing effectiveness of SFR pattern for accountability in
database domain. In database domain, the defined SFR pattern for accountability as
shown in section 5.2.3 is:
(GEN.1, GEN.2, SAR.1, SAR.3, SEL.1, STG.1, STG.3 /STG.4)
The next step is to compare each security products selected SFRs for
accountability with this derived pattern for difference. In security product No.1 in
database domain, the selected SFRs for accountability is:
(GEN.1, GEN.2, SAR.1, SAR.2, SAR.3, SEL.1, STG.1, STG.3)
From table, j = 8 for accountability. The difference between the selected SFRs and
the defined SFR pattern is only one SFR, which is SAR.2, hence D1, 8 = 1. Similarly,
95

I can get Di, 8 for the rest security products. There are total 11 security products in
database domain, hence m=11. The sum of D of all security products is:

i, 8 =

25. From table, we can see that n=11 for accountability security objective.
Now we can calculate E accountability = (1- 25/11/11) * 100%= 79.3%.

6.2.1 SFR Pattern Validation Result in BPDS Domain

For security patterns discovered in section 5.2.1 for BPDS domain, the
effectiveness E of them are shown in the table below:
Effectiveness
of Security
Pattern
Pattern 1
Pattern 2
Pattern 3

Test Set
Set 1+2
Set 3
Set 1+2+3
Set 2+3
Set 1
Set 1+2+3
Set 1+2
Set 2
Set 1+2+3

Identity &
Authenticatio
n
85.7%
84.7%
85.4%
85.2%
81.6%
84%
82.9%
77.5%
81.6%

Confiden
tiality

Security
Management

Accounta
bility

92%
91.5%
91.8%
91.8%
91.7%
91.8%
91.6%
92.3%
91.8%

85.2%
82.4%
84.2%
84.6%
81.9%
83.7%
83.8%
83.5%
83.7%

82.5%
82.5%
82.5%
85.1%
76%
82%
79.5%
77.3%
78.8%

Table 47: Effectivness of Security Patterns in BPDS

Security pattern 1 explored by set 1 and set 2 in BPDS domain should be chosen
since it has the best overall effectiveness compared with other two security patterns.

96

The percentages of security products that fit in different ranges of effectiveness are
shown in the table below:

Effectiveness of
Security Pattern
<=10%
<=20%
<=30%

Percentage of Security Products within Range of

Effectiveness
Identification& Confidentia
Security
Accounta
Authentication
lity
Management
bility
26.2%
69.0%
38.1%
52.4%
61.9%
97.6%
66.7%
73.8%
100.0%
100.0%
85.7%
85.7%

Table 48: Range of Effectiveness of BPDS Security Pattern

Confidentiality has the clearest SFR pattern compared with other primary security
objectives in this domain.

6.2.2 SFR Pattern Validation Result in ICSCRS Domain

This section validates the derived SFR patterns for ICs, Smart Cards & Related
Services (ICSCRS) domain in section 5.2.8 by evaluating the effectiveness E for
patterns.
Effectiveness
of Security
Pattern
Pattern 1
Pattern 2
Pattern 3

Test Set

Confiden
tiality

Integrity

Security
Management

Set 1+2
Set 3
Set 1+2+3
Set 2+3
Set 1
Set 1+2+3
Set 1+2
Set 2
Set 1+2+3

84.7%
82.9%
84.1%
91.9%
83.3%
89%
83.7%
85.2%
84.2%

85.4%
84.4%
85.1%
92.9%
83.7%
89.8%
85.1%
85.1%
85.1%

80.8%
78.8%
80.1%
90.1%
77.6%
85.9%
79.8%
80.8%
80.1%

Intrusion
Detection&
Response
92%
90.4%
91.5%
91.3%
91.7%
91.5%
91%
89.7%
90.6%

Table 49: Effectivness of Security Patterns in ICSCRS

Security pattern 2 explored by set 2 and set 3 in ICSCRS domain should be chosen
since it has the best overall effectiveness compared with other two security patterns.

97

The percentages of security products that fit in different ranges of effectiveness are
shown in the table below.

Effectiveness
of Security
Pattern
<=10%
<=20%
<=30%

Percentage of Security Products within Range of Effectiveness

Confidentia Integrity
Security
Intrusion Detection&
lity
Management
Response
16.7%
75%
100.0%

16.7%
83.3%
100%

13.9%
55.6%
72.2%

58.3%
91.7%
100%

Table 50: Range of Effectiveness of ICSCRS Security Pattern

Intrusion detection& response has the clearest pattern compared with other
primary security objectives in this domain.

6.2.3 SFR Pattern Validation Result in NNRDS Domain

This section validates the derived SFR patterns for Network and Network Related
Devices and Systems (NNRDS) domain in section 5.2.8 by evaluating the
effectiveness E for patterns. Since three derived SFR patterns for identification&
authentication and accountability are identical in NNRDS domain, we only calculate
effectiveness E once for each of these two security objectives using all 28 security
products in this domain:
Effectiveness of SFR Patterns
Pattern 1, 2, 3

Identity& Authentication
88.8%

Accountability
81.5%

Table 51: Effectiveness of Security Patterns for Two SOs

98

For confidentiality and security management, since three patterns are different, we
need to calculate effectiveness E once for each of them using different test set, as
shown in table below.
Effectiveness of
Security Pattern
Pattern 1
Pattern 2
Pattern 3

Test Set

Confidentiality

Set 1+2
Set 3
Set 1+2+3
Set 2+3
Set 1
Set 1+2+3
Set 1+2
Set 2
Set 1+2+3

85.2%
85%
85.1%
91.8%
81.5%
88.5%
86.1%
84.5%
85.1%

Security
Management
84.2%
79.2%
82.4%
89.5%
77.8%
85.7%
82.2%
82.1%
82.1%

Table 52: Effectiveness of Security Patterns in NNRDS

Security pattern 2 explored by set 2 and set 3 in BPDS domain should be chosen
since it has the best overall effectiveness compared with other two security patterns.
The percentages of security products that fit in different ranges of effectiveness are
shown in the table below.

Effectiveness of
Security Pattern
<=10%
<=20%
<=30%

Percentage of Security Products within Range of Effectiveness

Identification & Confidentia
Security
Accountabi
Authentication
lity
Management
lity
57.1%
32.1%
28.6%
25%
75%
78.6%
60.7%
39.3%
96.4%
100%
82.1%
75%

Table 53: Range of Effectiveness of NNRDS Security Pattern

Identification& authentication and confidentiality have the clearest security
patterns compared with other primary security objectives in this domain.

99

6.2.4 SFR Pattern Validation Result in OS Domain

This section validates the derived SFR patterns for Operating Systems (OS)
domain in section 5.2.9 by evaluating the effectiveness E for patterns. Since three
derived SFR patterns for all the primary security objectives are identical in OS
domain, we only calculate effectiveness E once for each of these four security
objectives using all 26 security products in this domain:
Effectiveness
of SFR
Patterns
Pattern 1, 2, 3

Identification
&
Authentication
88.5%

Confidentiality

Security
Management

Accountability

91.8%

84.9%

72.4%

Table 54: Effectivness of Security Patterns in OS

The percentages of security products that fit in different ranges of effectiveness are
shown in the table below.

Effectiveness of
Security Pattern
<=10%
<=20%
<=30%

Percentage of Security Products within Range of

Effectiveness
Identification & Confidentia
Security
Accounta
Authentication
lity
Management
bility
53.8%
65.4%
53.8%
53.8%
76.9%
92.3%
69.2%
61.5%
88.5%
100.0%
76.9%
65.4%

Table 55: Range of Effectiveness of OS Security Pattern

From the data shown in the table, the effectiveness of the primary security
objectives do not seem very good compared with other domains. However, there are
clear SFR patterns for these security objectives in OS domain. It is because some
security products in this domain have 0 SFR for the primary security objectives. For
those security products that have the listed primary security objectives, their
selections of SFRs are quite consistent with each other. Hence, it is important for

100

developers to think about whether to include any of these listed primary security
objectives when developing any security product from this domain.

6.2.5 SFR Pattern Validation in Other Domains

For security patterns discovered in section 5.2.1 for access control domain, the
effectiveness E of them are shown in the table below:

Effectiveness
of SFR Pattern

Identity &
Authentication

Confidentiality

Security
Management

81.4%

90%

75.4%

Table 56: Effectivness of Security Patterns in AC

For security patterns discovered in section 5.2.3 for database domain, the
effectiveness E of them are shown in the table below:
Identity &
Authentication

Confidentia
lity

Security
Management

Accountabi
lity

86.4%

94.9%

86%

79.3%

Effectiveness
of SFR Pattern

Table 57: Effectivness of Security Patterns in DB

For security patterns discovered in section 5.2.4 for data protection domain, the
effectiveness E of them are shown in the table below:
Identity &
Confidentiality
Authentication
Effectiveness
of SFR Pattern

86.2%

90.1%

Security
Management
80.8%

Table 58: Effectivness of Security Patterns in DP

101

For security patterns discovered in section 5.2.5 for detection devices domain, the
effectiveness E of them are shown in the table below:
Identity &
Authentication
91.8%

Accountability
71.4%

Security
Management
94.5%

Intrusion Detection&
Response
84.4%

Table 59: Effectivness of Security Patterns in DD

For security patterns discovered in section 5.2.7 for key management domain, the
effectiveness E of them are shown in the table below:
Identity &
Authentication
81.3%

Confidentiality
89.1%

Security
Management
75.7%

Accountability
81.8%

Table 60: Effectiveness of Security Patterns in KM

Some observations are drawn from above effectiveness analysis as following:

All the domains have security patterns on confidentiality except detection

devices domain.

All the domains have security patterns on identification& authentication

except IC and smart card domain.

Although there are total 36 SFRs support confidentiality, only few of them
are frequently used in security products, hence the effectiveness of SFR
pattern for confidentiality is usually higher than the others.

Effectiveness of SFR pattern for security management in different domains

differ a lot, which is because SFRs in FMT class do not have clear rigor level
difference like other SFR classes, such as FDP and FIA. Hence security
products in the same domain may still differ a lot in choosing SFRs for
security management. The only exceptions are domains with single main
102

functionality such as detection devices, which has clear and simple

requirement on security management.

103

Chapter 7: Contributions and Future Work

In this section, I will summarize the contributions of the SFR pattern analysis for
developing secure software and present some thoughts on the future research fields
related with this topic.

7.1 Contributions
The contributions of this thesis is listed as following:
1. This work builds up a database containing information of security functional
requirements, assurance level and other information of 242 security products
published on the common criteria portal website, which can be used for other
statistic analysis in the future.
2. This work provides a mapping scheme between SFRs and security objectives,
which is validated by the Security Target files of 242 security products. The
mapping scheme can save developers time by reduce the range of candidate
SFRs when they have the information on security objectives of the security
product.
3. This work shows the analysis result of correlations among SFR classes defined in
CC and correlations among security objectives. It also discusses what can be
derived from the analysis result, which can guide developers in designing the
architecture of security products.

104

4. This work shows the trend analysis between EAL and number of SFRs of the 242
security products in this dataset, which shows one aspect of the fact that leads to
a clear direction for further discussion and explorations in the future.
5. This work presents the SFR patterns for nine domains of security products and
provides a method of evaluating the effectiveness of patterns. Developers choose
the applicable patterns and customize them for the use on specific security
application.

7.2 Future Work

This thesis focuses on defining the mapping between SFRs and security objectives,
analyzing the correlations among security objectives and discovering SFR patterns
for difference security product domains. Several suggested areas of future work
include:
1. More detail analysis in different types (E.g., business application, military
application) of security products inside each domain to explore the suitable SFR
patterns.
2. Modifications on the current work to make it suitable for the newest version of
CC.
3. Keep expanding the dataset to include the newest published STs of security
products on common criteria portal website.
4. This thesis solves the path from security objectives to SFRs. In the future it is
valuable to explore a path from potential threats, security assumptions to security

105

objectives, which provides a more complete guidance in helping developers

select the right set of SFRs.
5. Research on presentation of this work to have a clearer input & output
parameters and format, which can help developers more efficiently use this work.

106

References
[1]

Alexander, C., The Timeless Way of Building. Oxford University Press,

1979

[2]

Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I.,
Angel, S., A Pattern Language: Towns-Buildings-Constructions, Oxford
University Press, 1977

[3]

Arc Software http://www.stat.umn.edu/arc/software.html

[4]

Boehm, B., et al., An Overview of the COCOMO 2.0 Software Cost Model,
Software Technology Conference, April 1995

[5]

Boehm, B., et al., Model-Based (System) Architecting and Software

Engineering (MBASE). Center for Software and System Engineering
(CSSE), University of Southern California, 1997

[6]

Boehm, B., Egyed, A., Kwan, J., Port, D., Shah, A., Madachy, R., Using the
WinWin Spiral Model: A Case Study, IEEE Computer, July 1998, Page: 3344

[7]

Boehm, B., Port, D., Balancing Discipline and Flexibility With the Spiral
Model and MBASE, CrossTalk, the Journal of Defense Software
Engineering, Vol 12 No. 12, December 2001

[8]

Brown, F. L. Jr., DiVietri, J., Villegas, G. D., Fernandez, E. D., The

Authenticator Pattern, In: Proceedings of Pattern Language of Programs
(PloP), August 1999

[9]

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern
Oriented Software Architecture: a System of Patterns, Wiley, Chichester
1996

[10] Chidamber, S. R., Kemerer, C. F., Towards a Metrics Suite for objectoriented Design, In Proceeding of OOPSLA '91, 1991
[11] Common Criteria for Information Technology Security Evaluation (CC),
version 1.0, January 1996
[12] Common Criteria for Information Technology Security Evaluation (CC),
version 2.1, August 1999
[13] Common Criteria for Information Technology Security Evaluation (CC),
version 2.3, ISO/IEC 15408:2005, August 2005
[14] Common Criteria for Information Technology Security Evaluation (CC),
version 3.1 Revision 1, September 2006
[15] Common Criteria Portal http://www.commoncriteriaportal.org/public/expert/
107

[16] Cook, R. D., Weisberg, S., Applied Regression Including Computing and
Graphics, ISBN 0-471-31711-X, John Wiley and Sons, Inc , August 1999
[17] Curphey, M., et.al., A Guide to Building Secure Web Applications, the Open
Web Application Security Project (OWASP), September 2002
[18] Evans, D. L., Bond, P. J., Bement, A. L., Standards for Security
Categorization of Federal information and Information Systems, National
Institute of Standards and Technology (NIST) Federal Information
Processing Standards (FIPS) 199, February 2004
[19] Fenton, N. E., Software Metrics - A Rigorous Approach, Chapman & Hall,
1992
[20] Fernandez, E. B., Sorgente, T., Larrondo-Petrie, M. M., Even more patterns
for secure operating systems, Conference on Pattern Languages of Programs
(PLoP), 2006
[21] Ferraiolo, D., Kuhn, R., Role-Based Access Control, 15th NIST-NCSC
National Computer Security Conference, 1992
[22] Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements
of Reusable Object-Oriented Software, Addison-Wesley-Longman, New
York 1995
[23] Gilliam, D. P., Wolfe, T. L., Sheirf, J. S., Software Security Checklist for the
Software Life Cycle. Proceedings of the 12th IEEE International Workshops
on Enabling Technologies: Infrastructure for Collaborative Enterprises
(WETICE), 2003
[24] Grance, T., Hash, J., Stevens, M., Security Considerations in the Information
System Development Life Cycle, National Institute of Standards and
Technology (NIST) Special Publication 800-64 Rev.1, June 2004
[25] Hayes R., B., Pfleger, K., Lalanda, P., Morignot, P., Balabanovic, M., A
domain-specific software architecture for adaptive intelligent systems, IEEE
Transactions on Software Engineering, Volume 21, Page 288--301, April
1995
[26] Herrmann, D. S., Using the Common Criteria for IT Security Evaluation,
ISBN 0-8493-1404-6, Auerbach Publications, 2002
[27] Information Technology Security Evaluation Criteria (ITSEC), Department
of Trade and Industry, London, June 1991
[28] Information Technology System Security Engineering Capability
Maturity Model, ISO/IEC 21827, March 2002
[29] INFOSEC Assurance Capability Maturity Model (IA-CMM), version 3.0,
INFOSEC, October 2003

108

[30] John H., et al., Integrating IT Security into the Capital Planning and
Investment Control Process, National Institute of Standards and Technology
(NIST) Special Publication 800-65, January 2005
[31] Kerth, N. L., Cunningham, W., Using Patterns to Improve Our Architectural
Vision, IEEE Software, 14(1): 53-59, January 1997
[32] Macro, A., Buxton, J., The Craft of Software Engineering, Addison-Wesley,
1987
[33] Meszaros, G., Doble, J., A pattern Language for Pattern Writing,
http://hillside.net/patterns/writing/patternwritingpaper.htm, 1996
[34] Romanosky, S., Enterprise Security Patterns, Information Systems Security
Association Journal, March 2003
[35] Schumacher, M., Security Engineering with Patterns: Origins, Theoretical
Model, and New Applications, LNCS 2754, Springer-Verlag Berlin
Heidelberg, New York, 2003
[36] Steel, C., Nagappan, R., Lai, R., Core Security Patterns: Best Practices and
Strategies for J2EE, Web Services, and Identity Management, ISBN-10: 013-146307-1, Prentice Hall PTR, October 2005
[37] Stoneburner, G., Goguen, A., and Feringa, A., Risk Management Guide for
Information Technology Systems, National Institute of Standards and
Technology (NIST) Special Publication 800-30, July 2002
[38] Swanson, M., Hash, J., Bowen, P., Guide for Developing Security Plans for
Federal Information Systems, National Institute of Standards and Technology
(NIST) Special Publication 800-18 Revision 1, February 2006
[39] Tracz, W., An Outline for a Domain-Specific Software Architecture
Engineering Process, In Fourth Annual Workshop on Software Reuse,
Reston, VA, 1991
[40] Tracz, W., DSSA (Domain-Specific Software Architecture): pedagogical
example, ACM SIGSOFT Software Engineering Notes, Volume 20 , Issue 3,
Pages: 49 62, July 1995
[41] Troy, D. A., Zweben, S. H., Measuring the Quality of Structured Designs.
Journal of Systems and Software, Vol. 2, 1981
[42] Trusted Computer System Evaluation Criteria (TCSEC), DoD 5200.28
STD, December 1985
[43] Wheeler, D. W., Secure Programming for Linux and Unix HOWTO,
http://www.dwheeler.com/secure-programs/, 2002
[44] Wilson, M., Hash, J., Building an Information Technology Security
Awareness and Training Program, National Institute of Standards and
Technology (NIST) Special Publication 800-50, October 2003
109

[45] Wu, D., Naeymi, R. I., Colbert, E., Extending MBASE to Support the
Development of Secure Systems, Accepted by Software Process Workshop
(SPW), Beijing, China, May 2005
[46] Yoder, J., Barcalow, J., Architectural patterns for enabling application
security, In Proceedings of the Pattern Languages of Programming (PLoP)
Workshop, September 1997
[47] Yourdon, E., Constantine, L., Structured Design: Fundamentals of a
Discipline of Computer Program and Systems Design, Prentice-Hall,
Yourdon Press, 1979

110

Appendices
SFR abbreviations and full names
Requirement Class Name
(Abbreviation)

Requirement Family Name (Abbreviation)

Security audit (FAU)

Security audit automatic response (FAU_ARP)

Security audit data generation (FAU_GEN)
Security audit analysis (FAU_SAA)
Security audit review (FAU_SAR)
Security audit event selection (FAU_SEL)
Security audit event storage (FAU_STG)

Communication (FCO)

Non-repudiation of origin (FCO_NRO)

Non-repudiation of receipt (FCO_NRR)

Cryptographic support (FCS)

Cryptographic key management (FCS_CKM)

Cryptographic operation (FCS_COP)

User data protection (FDP)

Access control policy (FDP_ACC)

Access control functions (FDP_ACF)
Data authentication (FDP_DAU)
Export to outside TSF control (FDP_ETC)
Information flow control policy (FDP_IFC)
Information flow control functions (FDP_IFF)
Import from outside TSF control (FDP_ITC)
Internal TOE transfer (FDP_ITT)
Residual information protection (FDP_RIP)
Rollback (FDP_ROL)
Stored data integrity (FDP_SDI)
111

Requirement Class Name

(Abbreviation)

Requirement Family Name (Abbreviation)

Inter-TSF user data confidentiality transfer
protection (FDP_UCT)
Inter-TSF user data integrity transfer protection
(FDP_UIT)

Identification
authentication (FIA)

and Authentication failures (FIA_AFL)

User attribute definition (FIA_ATD)
Specification of secrets (FIA_SOS)
User authentication (FIA_UAU)
User identification (FIA_UID)
User-subject binding (FIA_USB)

Security management (FMT)

Management of functions in TSF (FMT_MOF)

Management of security attributes (FMT_MSA)
Management of TSF data (FMT_MTD)
Revocation (FMT_REV)
Security attribute expiration (FMT_SAE)
Security management roles (FMT_SMR)

FPR: Privacy

Anonymity (FPR_ANO)
Pseudonymity (FPR_PSE)
Unlinkability (FPR_UNL)
Unobservability (FPR_UNO)

Protection of the TSF (FPT)

Underlying abstract machine test (FPT_AMT)

Fail secure (FPT_FLS)
Availability of exported TSF data (FPT_ITA)
Confidentiality of exported TSF data (FPT_ITC)
Integrity of exported TSF data (FPT_ITI)
112

Requirement Class Name

(Abbreviation)

Requirement Family Name (Abbreviation)

Internal TOE TSF data transfer (FPT_ITT)
TSF physical protection (FPT_PHP)
Trusted recovery (FPT_RCV)
Replay detection (FPT_RPL)
Reference mediation (FPT_RVM)
Domain separation (FPT_SEP)
State synchrony protocol (FPT_SSP)
Time stamps (FPT_STM)
Inter-TSF TSF data consistency (FPT_TDC)
Internal TOE TSF data replication consistency
(FPT_TRC)
TSF self test (FPT_TST)

Resource utilization (FRU)

Fault tolerance (FRU_FLT)

Priority of service (FRU_PRS)
Resource allocation (FRU_RSA)

TOE access (FTA)

Limitation on scope of selectable attributes

(FTA_LSA)
Limitation on multiple concurrent sessions
(FTA_MCS)
Session locking (FTA_SSL)
TOE access banners (FTA_TAB)
TOE access history (FTA_TAH)
TOE session establishment (FTA_TSE)

Trusted path/channels (FTP)

Inter-TSF trusted channel (FTP_ITC)

Trusted path (FTP_TRP)

113