Security Target: st_vid3012

Security Target: st_vid3012
Security Target, Version 1.11
for
XTS-400, Version 6
December 2004
Unclassified
Prepared By: BAE Systems Information
Technology, LLC
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
© 2004 BAE Systems Information Technology, LLC. All rights reserved.
“Linux” is a registered trademark of Linus Torvalds.
“Red Hat” and “RPM” (Red Hat Package Manager) are registered trademarks of Red Hat
Software, Inc. in the United States and other countries.
“STOP”, “SAGE”, “XTS-300” and “XTS-400” are trademarks of BAE Systems Information
Technology, LLC.
“Intel” and “Pentium” are registered trademarks of the Intel corp. “Xeon” is a trademark of the
Intel Corp.
"Netscape” is a registered trademark of Netscape Communications Corporation in the U.S. and
other countries.
“UNIX” is a registered trademark of The Open Group.
“Apache” is a trademark of the Apache Software Foundation.
All other product names mentioned herein are trademarks of their respective owners.
The TCP/IP software contained in this release is derived from material which is copyright
Regents of the University of California. The following paragraph applies to that software in its
original form as provided by U.C.:
“1. Redistribution of source code must retain the above copyright notice, this list of
conditions and the following disclaimer. 2. Redistribution in binary form must reproduce the
above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution. 3. All advertising
materials mentioning features or use of this software must display the following
acknowledgment: ‘This product includes software developed by the University of California,
Berkeley and its contributors.’ 4. Neither the name of the University nor the names of its
contributors may be used to endorse or promote products derived from this software without
specific prior written permission.”
Various STOP application programs may use or link to one or more libraries, including
uClibc, which are licensed under Version 2.1 of the GNU Lesser General Public License
("LGPL") available at http://www.gnu.org/copyleft/lesser.html. In accordance
with the LGPL, the source code for all linked libraries is provided free of charge on the
Applications CD. BAE Systems Information Technology, LLC claims no interest or ownership,
including copyrights, in any of the linked libraries licensed under the LGPL.
RESTRICTED RIGHTS LEGEND. If this product is acquired by the U.S. Government; use,
reproduction, duplication or disclosure by the U.S. Government is subject to restrictions as set
forth in Alternate III, subparagraph (g)(3)(i) of the Rights in Data clause at FAR 52.227-14 for
civilian agencies; and subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.227-7013 for the Department of Defense. BAE Systems
Information Technology, LLC, 2525 Network Place, Herndon, VA 20171, reserves all rights
under the copyright laws of the United States.
ii
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Table of Contents
1
INTRODUCTION..................................................................................................... 7
1.1
SECURITY TARGET IDENTIFICATION .................................................................... 7
1.2
SECURITY TARGET OVERVIEW ............................................................................ 8
1.2.1
XTS-400 Background and History .............................................................. 8
1.3
CC CONFORMANCE CLAIM ................................................................................ 11
1.4
CONVENTIONS ................................................................................................... 16
1.5
TERMINOLOGY ................................................................................................... 18
2
TOE DESCRIPTION ............................................................................................. 21
2.1
PRODUCT DESCRIPTION ..................................................................................... 21
2.1.1
Software Overview .................................................................................... 21
2.1.2
Hardware Overview.................................................................................. 22
2.1.3
TOE Definition.......................................................................................... 26
2.2
GENERAL TOE FUNCTIONALITY ........................................................................ 27
2.2.1
Security Features ...................................................................................... 27
2.2.2
Other characteristics of compliant TOEs ................................................. 27
3
TOE SECURITY ENVIRONMENT..................................................................... 29
3.1
3.2
3.3
4
SECURITY OBJECTIVES ................................................................................... 37
4.1
4.2
5
SECURE USAGE ASSUMPTIONS........................................................................... 29
SECURITY THREATS ........................................................................................... 32
SECURE USAGE POLICIES ................................................................................... 35
SECURITY OBJECTIVES FOR THE TOE ................................................................ 37
SECURITY OBJECTIVES FOR THE ENVIRONMENT ................................................ 41
IT SECURITY REQUIREMENTS....................................................................... 43
5.1
TOE SECURITY FUNCTIONAL REQUIREMENTS ................................................... 45
5.1.1
Security audit (FAU)................................................................................. 45
5.1.2
User data protection (FDP)...................................................................... 48
5.1.3
Identification and authentication (FIA) .................................................... 59
5.1.4
Security management (FMT) .................................................................... 62
5.1.5
Protection of the TOE Security Functions (FPT) ..................................... 70
5.1.6
TOE Access (FTA) .................................................................................... 71
5.1.7
Trusted path/channels (FTP) .................................................................... 71
5.2
END NOTES ........................................................................................................ 73
5.3
TOE SECURITY ASSURANCE REQUIREMENTS .................................................... 82
5.4
STRENGTH OF TOE SECURITY FUNCTIONAL REQUIREMENTS ............................ 84
6
TOE SUMMARY SPECIFICATION ................................................................... 85
iii
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
6.1
MEASURES USED TO MEET IT SECURITY FUNCTIONS ........................................ 85
6.1.1
Audit Generation – AUDGEN .................................................................. 93
6.1.2
Audit Review – AUDREV.......................................................................... 94
6.1.3
Discretionary Access Control – DACENF ............................................... 94
6.1.4
Mandatory Access Control – MACENF ................................................... 95
6.1.5
Mandatory Integrity Control – MICENF.................................................. 96
6.1.6
Residual Information Protection – RIPENF............................................. 96
6.1.7
Identification and Authentication – IDNAUT ........................................... 97
6.1.8
Security Management – SECMGT ............................................................ 98
6.1.9
Security Function Protection – SECFPR.................................................. 98
6.1.10
Trusted Path – TRUPTH......................................................................... 104
6.2
ASSURANCE MEASURES ................................................................................... 106
6.3
IT SECURITY FUNCTIONS REALIZED BY PROBABILISTIC OR PERMUTATIONAL
MECHANISMS ............................................................................................................... 108
7
PP CLAIMS........................................................................................................... 109
7.1
7.2
7.3
8
PP REFERENCE................................................................................................. 109
PP REFINEMENTS, SELECTIONS, AND ASSIGNMENTS ....................................... 109
PP ADDITIONS ................................................................................................. 109
RATIONALE ........................................................................................................ 111
8.1
SECURITY OBJECTIVES RATIONALE ................................................................. 111
8.2
SECURITY REQUIREMENTS RATIONALE ........................................................... 121
8.2.1
Functional Security Requirements Rationale ......................................... 121
8.2.2
Assurance Security Requirements Rationale .......................................... 125
8.2.3
Rationale that IT Security Requirements are Internally Consistent ....... 126
8.3
FUNCTIONAL REQUIREMENTS GROUNDING IN OBJECTIVES ............................. 128
8.4
PP CLAIMS RATIONALE ................................................................................... 133
8.5
STRENGTH-OF-FUNCTION RATIONALE ............................................................. 133
8.6
RATIONALE FOR INCLUSION OF HARDWARE IN THE TOE................................. 135
9
APPENDIX A – LIST OF SUBJECTS ............................................................... 141
9.1
SUBJECTS ......................................................................................................... 141
9.1.1
Subject Attributes .................................................................................... 141
9.1.2
Subject Creation and Destruction........................................................... 141
10
APPENDIX B – LIST OF OBJECTS ............................................................. 143
10.1 INFORMATION AND OBJECTS ............................................................................ 143
10.1.1
Semaphores ............................................................................................. 143
10.1.2
Processes................................................................................................. 144
10.1.3
Devices.................................................................................................... 144
10.1.4
Sockets..................................................................................................... 145
10.1.5
File System Objects................................................................................. 145
iv
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
10.1.6
Memory Objects ...................................................................................... 147
11
APPENDIX C – TSF COMMANDS ............................................................... 149
12
APPENDIX D – USER COMMANDS............................................................ 154
13
APPENDIX E – AUDITABLE EVENTS ....................................................... 157
14
APPENDIX F – SELECTABLE AUDIT EVENTS....................................... 161
15
APPENDIX G - ACRONYMS......................................................................... 163
16
APPENDIX H – FUNCTIONAL REQUIREMENTS REQUIRED BY
EXISTING XTS-400 CUSTOMERS........................................................................... 165
v
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
List of Tables
Table - 5-1 Security Functional Requirements
Table - 5-2 Assurance Requirements: EAL5 Augmented
Table - 6-1 Security Functions and the SFRs They Implement
Table - 6-2 SFRs and the Security Functions that Satisfy Them
Table - 6-3 Security Assurance Requirements and the Security Measures
That Meet Them
Table - 8-1 Mapping the TOE Security Environment to Security
Objectives
Table - 8-2 Tracing of Security Objectives to the TOE Security
Environment
Table - 8-3 Functional Component to Security Objective Mapping
Table - 8-4 Requirements to Objectives Mapping
Table - 8-5 LSPP Objectives to ST Objectives Mapping
vi
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
1 Introduction
1.1 Security Target Identification
Title:
Security Target for XTS-400, Version 6.
Keywords:
MAC, DAC, MIC, Mandatory Access Control, Discretionary Access
Control, Mandatory Integrity Control, Authentication, Trusted Path,
MLS
This Security Target (ST) has been prepared by BAE Systems Information Technology,
LLC (hereinafter, BAE – IT), 2525 Network Place, Herndon, VA 22171. This ST
supports the Target of Evaluation (TOE) as implemented within the XTS-400, Version 6
(hereafter referred to simply as Version 6). Development of this ST was guided by
specifications detailed in the following documents:
1. Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and general model, August 1999, Version 2.1
2. Common Criteria for Information Technology Security Evaluation, Part 2:
Security functional requirements, August 1999, Version 2.1
3. Common Criteria for Information Technology Security Evaluation, Part 3:
Security assurance requirements, August 1999, Version 2.1
7
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
1.2 Security Target Overview
This Security Target (ST) is for the BAE - IT supplied “XTS-400”, and specifies security
requirements for obtaining an EAL5+ security evaluation. XTS-400 is a combination of
an operating system, Secure Trusted Operating Program (STOP) revision 6, with BAE IT-supplied hardware.
Operating systems evaluated against this ST will:
•
Associate sensitivity labels with all objects and all its users will have an
associated clearance level identifying the maximum security level of data that
they may access.
•
Allow simultaneous use of the system by multiple users, all with different
clearances and needs-to-know.
•
Allow simultaneous network connectivity to networks of differing
sensitivities/classifications.
•
Provide mandatory integrity protection of files.
•
Provide an untrusted operating environment that includes common Linux
commands and tools.
•
Provide an Application Programming Interface/Application Binary Interface
which is suitable for running most Linux applications in their binary format (no
recompilation required).
1.2.1 XTS-400 Background and History
XTS-200, XTS-300, STOP 3.1.E, STOP 3.2.E, STOP 4.1, and STOP 5.2.E are
descendants of the Secure Communications Processor (SCOMP) [13], a system also
developed by a predecessor of BAE - IT, which was evaluated by the National Computer
Security Center (NCSC) in 1984 and received an A1 rating. The hardware base is
fundamentally different from the SCOMP's, and the software has undergone significant
further development. Development of STOP 3.1 on the DPS6 PLUS began in 1987 and
continued through 1989. During that time, the combination of the software and hardware
became known as XTS-200.
In contrast to the hardware on which the SCOMP was based (the DPS6), the DPS6 PLUS
and DPS 6000 incorporated virtual memory and ring-protection techniques from the
Multics [12] system, so no additional hardware modification was required. The salient
differences between the operating system employed by SCOMP and XTS-200 were that
STOP 3.1 incorporated complete file system support within the TSF, that it was
considerably restructured to improve its use of layering and other software engineering
principles, that it was general-purpose, and that it provided a Unix-like untrusted
8
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
operating environment. In addition, XTS-200 supported multiprocessor configurations.
Development on STOP 3.2.E began in June 1992 and was completed in June 1993.
The essential differences between the XTS-300 and XTS-200 resulted from the change in
hardware base, primarily to employ the functions provided by the Intel processor.
Memory management, ring protection logic, and process management were updated in
the XTS-300. In addition, I/O functions moved from TSF System Services (TSS) into the
kernel. The user interface of the XTS-300 changed little from that of XTS-200.
Development on STOP 4.1 began in November 1992 and was completed in October
1994. Development continued through STOP 5.2.E, which was completed in April 2000.
Development for the XTS-400 of STOP revision 6 began June 2000. STOP, revision 6
implements the same Application Program Interface as Red Hat® Linux® Version 8
(GLIB-C Version 6.0/2.1). Other changes to the OS were:
•
Switch to the use of the more modern GCC Compiler
•
Trusted programs support is now in Ring 3 versus previous support in Ring 2
•
Commodity Application System Services (CASS) is renamed Operating System
Services (OSS) and now included in the TSF.
The XTS-400 with STOP 6 provides a general purpose computer system with a
UNIX/Linux interface. The system includes trusted utilities to perform system
maintenance and security administration functions. The XTS-400 is commodity software
provided under scrupulous Configuration Management control. The system is distributed
with an Installation and Setup Manual to show the user how to set up the hardware and
with a Software Release Bulletin to show how to install/reinstall and configure the
operating system. Additional user’s manuals, both for operations and administrative
functions, are also provided.
BAE - IT has other software products to augment the XTS-400 product. These other
products are not part of the TOE addressed by this ST. Installation of these products may
invalidate the security rating for the TOE due to the presence of privileged software, but
these products are designed to be secure and have previously been accredited. Available
as optional and separately priced items are:
1
A Software Development Environment (SDE) package that allows programming
of trusted and untrusted applications for use on the XTS. Frequently, initial
programming and debug is done on a “real” Linux system and the binary copied
to the XTS for execution. The SDE includes library functions to allow the
security enforcing XTS API (separate from the Linux API used for UNIX
functions).
2
A middle-ware package called Secure Automated Guard Environment (SAGE)
which provides transaction processing support for many of the tasks common to
9
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
file-oriented filtering applications. SAGE reduces the risk and expense of
developing custom applications by providing pre-written and pre-tested functions
so the application developer can focus on the “security filter” logic.
3
Turn-key applications programmed by BAE - IT to provide specific filtering
capability.
Evaluated at the same time as this XTS-400 evaluation was an application developed
using the SDE and SAGE to solve a specific customer’s mail filtering needs. The
applications specific functionality related to that application was the subject of a separate
Security Target.
10
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
1.3 CC Conformance Claim
The TOE is Part 2 conformant and Part 3 conformant EAL5 augmented (Evaluation
Assurance Level 5+), as defined in the "Common Criteria for Information Technology
Security Evaluation Version 2.1" (CC). This ST conforms with applicable interpretations
in effect as of 1 March 2003.
This ST claims conformance with the Certified Protection Profiles entitled “Labeled
Security Protection Profile (Version 1.b)” and “Controlled Access Protection Profile
(Version 1.d)”, and is generally significantly more demanding in its functionality.
Because foreign countries are not required by the mutual recognition agreement to accept
evaluation certificates for products exceeding EAL4 assurance, the intent is for XTS-400
will receive two certificates, one at EAL4+ (XTS-400 version 6.0.E) for International
recognition use and one at EAL5+ (XTS-400 version 6.1.E) for US use. Text which is
relevant only to the EAL5+ version of the product is followed by the symbol “†”.
All international and U.S. interpretations that are final as of March 1, 2003 shall apply to
this ST. Interpretations that were superceded, too new, or not relevant to the CC itself, or
not relevant to the requirements claimed in this ST have been weeded out. Interpretations
that affect the wording of this ST are marked with “*”. The international interpretations
(CCIMB) that exist and are relevant to the TOE are:
Interpretation Effective
Number
Date
Title
CC Reference
003
Unique
identification of
CC Part 3, Section
02/11/2002 configuration items
8.2 (ACM_CAP)
in the configuration
list
004
ACM_SCP.*.1C
11/12/2001 requirements
unclear
006
10/15/2000
008
Augmented and
07/31/2001 Conformant
overlap
009
04/13/2001
Virtual machine
description
Definition of
Counter
CEM Reference
CC Part 3, Section CEM, Section 8.4.3
8.3 (ACM_SCP) (ACM_SCP.2)
CC Part 3, Section
10.2 (ADV_HLD)
CC Part 1, Section CEM, Section 4.4.3
5.4
(ASE_INT.1)
CC Part 3, Section
1
11
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
013
Multiple SOF
claims for multiple
10/15/2000
domains in a single
TOE
016
02/11/2002
CC Part 3, Section
5.6 (ASE_REQ),
CC Part 3, Section
14.3 (AVA_SOF)
Objective for
ADO_DEL
CC Part 3, Section CEM, Section 6.5.1
9.1 (ADO_DEL) (ADO_DEL.1)
Assurance
Iterations
CC Part 2, Section
2.1.4, CC Part 1,
Section 4.4.1, CC
Part 3, Section
2.1.4
019
02/11/2002
027
CC Part 3, Section
02/16/2001 Events and actions 11.1
(AGD_ADM)
031
(Rev. 1)
10/25/2002
Obvious
vulnerabilties
CEM, Section 6.9.2
(AVA_VLA.1),
CEM, Section
CC Part 3, Section 7.10.3
14.4 (AVA_VLA) (AVA_VLA.1),
CEM, Section
8.10.3
(AVA_VLA.2)
CC Part 1, Annex
C, CC Part 3,
Section 5.8
(ASE_TSS)
032
Strength of
10/15/2000 Function Analysis
in ASE_TSS
037
02/16/2001
ACM on Product
or TOE?
CC Part 3, Section
2.6.1 ACM
043
Meaning of
02/16/2001 "clearly stated" in
APE/ASE_OBJ.1
CC Part 3, Section
4.4 (APE_OBJ),
CC Part 3, Section
5.4 (ASE_OBJ)
049
02/16/2001
Threats met by
environment
CC Part 1, Annex
B.2.5, CC Part 1,
Annex C.2.5, CC
Part 3, Section 4.4
(APE_OBJ), CC
Part 3, Section 5.4
(ASE_OBJ)
12
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
051
(Rev. 1)
Use of
documentation
10/25/2002
without C & P
elements.
CEM, Section 6.9.2
(AVA_VLA.1),
CC Part 3, Section CEM, Section
9.2 (ADO_IGS), 7.10.3
CC Part 3, Section (AVA_VLA.1),
14.4 (AVA_VLA) CEM, Section
8.10.3
(AVA_VLA.2)
055
Incorrect
Component
CC Part 2, Annex
10/15/2000 referenced in Part 2
J.8 (FPT_RCV)
Annexes,
FPT_RCV
058
07/31/2001
064
Apparent higher
standard for
02/16/2001
explicitly stated
requirements
CC Part 3, Section
4.6 (APE_SRE),
CC Part 3, Section
5.7 (ASE_SRE)
*065
No component to
call out security
07/31/2001
function
management
CC Part 2, Class
FMT
067
10/15/2000
085
SOF Claims
02/11/2002 additional to the
overall claim
095
02/16/2001
SCP Dependency
in ACM_CAP
CC Part 3, Section
8.2 (ACM_CAP)
098
02/11/2002
Limitation of
refinement
CC Part 1, Section
4.4.1
138
CEM, Section 3.4.5
Iteration and
CC Part 2, Section (APE_REQ.1),
06/05/2002
narrowing of scope 2.1.4
CEM, Section 4.4.6
(ASE_REQ.1)
Confusion over
refinement
Application notes
missing
CC Part 1, Annex
B.2.6, CC Part 1,
Annex C.2.6
CC Part 1, Annex
C
CC Part 3, Section
4.5 (APE_REQ),
CC Part 3, Section
5.6 (ASE_REQ)
13
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
The international interpretations (CCIMB) that exist and are not relevant to TOE
functionality, but which are relevant to the evaluation process for the TOE are:
Interpretation
Number
Effective
Date
Title
CC
Reference
CEM Reference
024
COTS product in TOE
01/16/2001
providing security
CEM, Section 8.6
(ADV), CEM, Section
8.4 (ACM)
074
Duplicate informative
10/15/2000 text for ATE_COV.2-3
and ATE_DPT.1-3
CEM, Section 7.9.2
(ATE_COV.2), CEM,
Section 7.9.3
(ATE_DPT.1)
075
Duplicate informative
10/15/2000 text for different work
units
CEM, Section 8.9.4
(ATE_FUN.1), CEM,
Section 8.9.5
(ATE_IND.2)
084
Aspects of objectives
02/16/2001 in TOE and
environment
CEM, Section 3.4.5
(APE_REQ.1), CEM,
Section 4.4.6
(ASE_REQ.1)
116
Indistinguishable work
07/31/2001
units for ADO_DEL
CEM, Section 7.5.1
(ADO_DEL.1), CEM,
Section 8.5.1
(ADO_DEL.2)
120
07/31/2001
Sampling of process
expectations unclear
CEM, Annex B.2
10/25/2002
Work unit not at the
right place
CEM, Section 4.4.8
(ASE_TSS.1)
11/15/2002
Coverage of the
Delivery Procedures
CEM, Section 8.5.1
(ADO_DEL.2)
10/25/2002
Consistency analysis in
AVA_MSU.2
CEM, Section 8.10.1
(AVA_MSU.2)
127
(Rev. 1)
128
(Rev. 1)
133
(Rev. 1)
The following NIAP interpretations were applied to this ST.
•
•
•
•
*I-0347: Including Sensitive Information In Audit Records
I-0420: Attribute Inheritance/Modification Rules Need To Be Included In Policy
I-0459: CM Systems May Have Varying Degrees Of Rigor And Function
I-0350: Clarification Of Resources/Objects For Residual Information Protection
14
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I-0381: Relationship Between FPT_PHP And FMT_MOF
*I-0415: User Attributes To Be Bound Should Be Specified
*I-0407: Empty Selections Or Assignments
*I-0409: Other Properties In FMT_MSA.3 Should Be Specified By Assignment
*I-0410: Auditing Of Subject Identity For Unsuccessful Logins
I-0414: Site-Configurable Prevention Of Audit Loss
I-0429: Selecting One Or More
I-0412: Configuration Items In The Absence Of Configuration Management
I-0421: Application Notes In Protection Profiles Are Informative Only
I-0427: Identification Of Standards
*I-0375: Elements Requiring Authentication Mechanism
*I-0389: Recovery To A Known State
I-0393: A Completely Evaluated ST Is Not Required When TOE Evaluation
Starts
I-0395: Security Attributes Include Attributes Of Information And Resources
*I-0406: Automated Or Manual Recovery Is Acceptable
I-0411: Guidance Includes AGD_ADM, AGD_USR, ADO, And ALC_FLR
I-0352: Rules Governing Binding Should Be Specifiable
I-0405: American English Is An Acceptable Refinement
I-0417: Association Of Information Flow Attributes W/Subjects And Information
*I-0423: Some Modifications To The Audit Trail Are Authorized
*I-0416: Association Of Access Control Attributes With Subjects And Objects
I-0418: Evaluation Of The TOE Summary Specification: Part 1 Vs Part 3
*I-0422: Clarification Of ``Audit Records''
I-0424: FPT_SEP.2 And FPT_SEP.3 Are Not Hierarchical
*I-0425: Settable Failure Limits Are Permitted
I-0426: Content Of PP Claims Rationale
15
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
1.4 Conventions
The notation, formatting, and conventions used in this security target (ST) are consistent
with version 2.1 of the Common Criteria for Information Technology Security
Evaluation. Font style and clarifying information conventions were developed to aid the
reader.
The CC permits four functional component operations: assignment, iteration, refinement,
and selection to be performed on functional requirements. These operations are defined in
Common Criteria, Part 2, paragraph 2.1.4 as:
•
assignment:
allows the specification of an identified parameter;
•
refinement:
allows the addition of details or the narrowing of requirements;
•
selection:
allows the specification of one or more elements from a list; and
•
iteration:
operations.
allows a component to be used more than once with varying
This ST indicates which text is affected by each of these operations in the following
manner:
•
Assignments specified by the ST author are in bold text.
•
Selections completed by the ST author are underlined.
•
Refinements are identified with "Refinement:" right after the short name.
Additions to the CC text are specified in bold. Deletions of the CC text are
identified in the “End Notes” with a bold number after the component (8).
•
Iterations are identified with a number inside parentheses ("(#)"). These follow
the short family name and allow components to be used more than once with
varying operations.
In the case of an assignment contained within a selection the text will be both bold and
underlined. For example, [selection: change, modify, [assignment: other options may
apply]] would be represented as; modify, create.
Interpretations are identified by adding “-NIAP-####” or –CCIMB-### to the end of the
component short name. The original CC text modified by the interpretation is not denoted
nor explained.
Application Notes are used to provide the reader with additional requirement
understanding or to clarify the author's intent. These are italicized and usually appear
following the element needing clarification.
Text which is relevant only to the EAL5+ version of the product (vs. the EAL4+ version
of the product) is followed by the symbol “†”.
16
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
17
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
1.5 Terminology
This security target uses the terms described in this section to aid in the application of the
requirements.
Access - A specific type of interaction between a subject and an object that results in the
flow of information from one to the other.
Authorized administrator - An authorized user who has been granted the authority to
manage the TOE. These users are expected to use this authority only in the
manner prescribed by the guidance given to them.
Authorized user - A user who has been uniquely identified and authenticated. These
users are considered legitimate users of the TOE.
Clearance - The users maximum authorization composed of a combination of sensitivity
level and integrity level.
Component - The smallest selectable set of elements that may be included in a PP, an ST,
or a package.
Critical Security Parameters (CSP) - Security-related information (e.g., authentication
data such as passwords and pins) appearing in plaintext or otherwise unprotected
form and whose disclosure or modification can compromise the security of the
information protected by the module.
Discretionary Access Control (DAC) - A means of restricting access to objects based on
the identity of subjects and/or groups to which they belong. The controls are
discretionary in the sense that a subject with a certain access permission is capable
of passing that permission (perhaps indirectly) on to any other subject.
Element - Individual requirements within a CC component; cannot be selected
individually for inclusion in a PP, ST, or package.
Evaluation Assurance Level (EAL) - A package consisting of assurance components from
CC, part 3 that represents a point on the CC predefined assurance scale.
Enclave - An environment that is under the control of a single authority and has a
homogeneous security policy, including personnel and physical security and
therefore protected from other environments. Local and remote elements that
access resources within an enclave must satisfy the policy of the enclave.
Enclaves can be specific to an organization or a mission and may contain multiple
networks. They may be logical, such as an operational area network (OAN) or be
based on physical location and proximity.
Integrity label - A security attribute that represents the integrity level of a subject or an
object. Integrity labels are used by the TOE as the basis for mandatory integrity
control decisions.
Integrity level - The combination of a hierarchical level and an optional set of nonhierarchical categories that represent the integrity of the information.
Level of Robustness - The characterization of the strength of a security function,
mechanism, service or solution, and the assurance (or confidence) that it is
implemented and functioning correctly to support the level of concern assigned to
18
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
a particular information system. DoD has three levels of robustness:
a. High: security services and mechanisms that provide the most stringent
available protection and rigorous security countermeasures.
b. Medium: security services and mechanisms that provide for layering of
additional safeguards above the DoD minimum (Basic).
c. Basic: security services and mechanisms that equate to good commercial
practices.
Mission Category - Reflects the importance of information relative to the achievement of
DoD goals and objectives, particularly the war fighter’s combat mission. Mission
categories are primarily used to determine requirements for availability and
integrity services. DoD has three mission categories:
a. Mission critical. Systems handling information which is determined to be
vital to the operational readiness or mission effectiveness of deployed and
contingency forces in terms of both content and timeliness.
b. Mission support. Systems handling information that is important to the
support of deployed and contingency forces; must be absolutely accurate,
but can sustain minimal delay without seriously affecting operational
readiness or mission effectiveness.
c. Administrative. Systems handling information, which is necessary for the
conduct of day-to- day business, but does not materially affect support to
deployed or contingency forces in the short term.
Mandatory Access Control (MAC) - A means of restricting access to objects based on
subject and object sensitivity labels. The Bell LaPadula model is an example of
Mandatory Access Control.
Mandatory Integrity Control (MIC) - A means of restricting access to objects based on
subject and object integrity labels. The Biba integrity model is an example of
Mandatory Integrity Control.
Multilevel system (MLS) - A system that can simultaneously handle (e.g., share, process)
multiple levels of data. It allows users at different sensitivity levels to access the
system concurrently. The system permits each user to access only the data to
which they are authorized access.
Named Object - An object that exhibits all of the following characteristics:
- The object may be used to transfer information between subjects of differing
user identities within the TSF.
- Subjects in the TOE must be able to request a specific instance of the object.
- The name used to refer to a specific instance of the object must exist in a context
that potentially allows subjects with different user identities to request the
same instance of the object.
- The intended use of the object is for sharing of information across user identities.
Object - An entity within the TOE security functions scope of control (TSC) that contains
or receives information and upon which subjects perform operations.
Operating Environment - The total environment in which an information system operates.
19
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
It includes the physical facility and controls, procedural and administrative
controls, and personnel controls.
Public Object - An object for which the TSF unconditionally permits all subjects “read”
access. Only the TSF or privileged subjects may create, delete, or modify the
public objects. No discretionary access checks or auditing is required for “read”
accesses to such public objects. Attempts to create, delete, or modify such objects
shall be considered security-relevant events, and, therefore, controlled and
auditable. Objects that all subjects can read (e.g., the system clock) must be,
implicitly, system low.
Protection Profile (PP) - An implementation-independent set of security requirements for
a category of TOEs that meet specific consumer needs.
Security attributes - TSF data that contains information about subjects and objects and
upon which access control decisions are based.
Security level - The combination of a hierarchical classification and a set of nonhierarchical categories that represent the sensitivity on the information.
Security Target (ST) - A set of security requirements and specifications to be used as the
basis for evaluation of an identified TOE.
Sensitive information - Information that, as determined by a competent authority, must be
protected because its unauthorized disclosure, alteration, loss, or destruction will
at least cause perceivable damage to someone or something.
Sensitivity label - A security attribute that represents the security level of an object and
that describes the sensitivity (e.g. Classification) of the data in the object.
Sensitivity labels are used by the TOE as the basis for mandatory access control
decisions.
Subject - An entity within the TSC that causes operations to be performed. Subjects can
come in two forms: trusted and untrusted. Trusted subjects may be exempt from
part or all of the TOE security policies. Untrusted subjects are bound by all TOE
security policies.
Target of Evaluation (TOE) - An IT product or system and its associated administrator
and user guidance documentation that is the subject of an evaluation.
TOE Security Functions (TSF) - A set consisting of all hardware, software, and firmware
of the TOE that must be relied upon for the correct enforcement of the TSP.
Unauthorized user - A user who may obtain access only to system provided public objects
if any exist.
User - A term used to include both authorized and unauthorized entities (human user or
external IT entity) outside the TOE that interacts with the TOE.
20
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
2
TOE Description
2.1 Product Description
This Security Target specifies Common Criteria requirements for the XTS-400, Version
6.
2.1.1 Software Overview
This section provides a general description of STOP, Version 6. STOP is a multitasking
operating system.
The system supports both a mandatory sensitivity policy and a mandatory integrity
policy. It provides 16 hierarchical sensitivity levels, 64 non-hierarchical sensitivity
categories, eight hierarchical integrity levels, and 16 non-hierarchical integrity categories.
Some of the hierarchical integrity levels are used by the system to provide role
separation, and the others are available to users. The combination of mandatory
sensitivity hierarchical and non-hierarchical levels is called the Mandatory Access
Control (MAC) label. The combination of mandatory integrity hierarchical and nonhierarchical levels is called the Mandatory Integrity Control (MIC) label. The system
also supports a discretionary access control policy.
2.1.1.1 Software Components
The Security Kernel software occupies the innermost and most privileged ring and
performs all Mandatory Access Control (MAC), and Mandatory Integrity Control (MIC).
The kernel provides a virtual process environment, which isolates one process from
another. The kernel implements a variation of the reference monitor concept. When a
process requests access to an object, the kernel performs the access checks, and, given
that the checks pass, maps the object into the process' address space. Subsequent accesses
are mediated by the hardware. The Security Kernel also provides I/O services and an
Inter-process Communication (IPC) message mechanism. The Security Kernel is part of
every process' address space and is protected by the ring structure supported by the
hardware.
The TSS software executes in Ring 1. TSS provides trusted system services required by
both trusted and untrusted processes. The Kernel, TSS and OSS have the responsibility
for creation and loading of both trusted and untrusted programs, respectively, in
XTS-400, Version 6. TSS software enforces the Discretionary Access Control (DAC)
policy to file system objects.
OSS executes in Ring 2. OSS provides a UNIX-like Linux interface for user-written and
trusted and untrusted software applications. The purpose of OSS is to make the multilevel
21
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
security execution environment hidden to software running in the Application Domain
(Ring 3).
Ring 3 is the Application Domain, in which all applications, both trusted and untrusted,
execute. Software is considered trusted in XTS-400, Version 6 if it performs functions
upon which the system depends to enforce the security policy (e.g., the establishment of
user authorization). This determination is based on integrity level and privileges.
Untrusted software runs at il3 or lower. Some processes require privileges to perform
their functions. An example of a process that requires privileges is the Secure Server,
which needs access to the User Access Authentication database, kept at system high
access level, while establishing a session for a user at another security level.
The multilevel secure XTS-400, Version 6 is designed to provide a high level of security
for many environments, which includes applications that may filter the information
according to rules based upon the security policies required by the site. The system
supports both a mandatory sensitivity policy and a mandatory integrity policy. It provides
hierarchical sensitivity levels, non-hierarchical sensitivity categories, hierarchical
integrity levels, and non-hierarchical integrity categories. The system provides for user
identification and authentication used for policy enforcement through user identifiers and
passwords, and individual accountability through its auditing capability. Data scavenging
is prevented through the control of object reuse. The trusted path mechanism is provided
by the implementation of a Secure Attention Key (SAK). The separation of administrator
and operator roles is enforced through integrity protected operations.
2.1.2 Hardware Overview
The TOE includes only standard-PC, commercial off-the-shelf (COTS) components.
There are two primary configurations: “Model 500” and “Model 2800”. The Model 500
is built around an Intel Pentium III CPU and Intel L440GX motherboard. The Model
2800 is built around an Intel Xeon (P4) CPU and Intel SW7501 motherboard. Within
each primary configuration, there are different form factor solutions (tower, 6U, 5U, 3U,
2U, etc.) and optional add-on hardware.
The minimal evaluated configuration is:
Component
CPU
Specific Kinds included in
the Evaluation
Intel Pentium III, Intel
Xeon(P4) “Prestonia”
22
UNCLASSIFIED
Notes
Intel IA-32 architecture, Intel
Architecture Software
Developer’s Manual (Volumes
1 through 3)
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Component
Hard Disk (SCSI-3,
ANSI X3T9.2/85-52)
Motherboard
Floppy Drive
Tape Drive
SCSI Host Adapter
(SCSI-3, ANSI
X3T9.2/85-52)
Video controller (onboard or add-on)
CD-ROM/DVD
Drive (ANSI
X3T9.2/85-52)
Monitor
Specific Kinds included in
the Evaluation
IBM “Daytona”
Seagate “Cheetah X15”
Seagate “Cheetah 10K.6”
Seagate “Cheetah 10K.7”
Intel L440GX, Intel SW7501
3.5”, MFM encoding, 1.44
Mbyte (capable of reading
standard density diskettes)
Teac FD-235HF series
Wangdat Tecmar TS3400D01, HP C1554C
Adaptec AIC7890, AIC7892,
and AIC7896
Cirrus Logic CL-GD5480, ATI
Rage XL
Toshiba XXM6401B, Toshiba
SD-M171lS
VGA, SVGA. CRT or flat
panel.
23
UNCLASSIFIED
Notes
additional hard disks can
optionally be connected
includes:
• PCI 2.1 or 2.2 system bus
• ISA bus
• 512Mbytes – 2Gbytes of
main memory
• up to two 16550-compatible
UARTs (serial controllers)
• IEEE 1284 ECP parallel
controller
• 8254-compatible PIT
• MC146818-compatible
RTC
• 8259-compatible PIC
• 8237-compatible DMA
• 87077A-compatible floppy
controller
SCSI, 4mm, ANSI X3T9.2/8552, DAT DDS-2, DAT DDS-3
On the motherboard board or
add-ons. At most 3 total in a
Model 500, 2 total in a Model
2800.
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Component
Keyboard
Mouse or Touchpad
Specific Kinds included in
the Evaluation
101-key or 104-key standard
or laptop style, PS/2
PS/2
Notes
<SysRq> key must generate
scancode 84
The optional, evaluated add-on hardware is:
Component
PC Card Reader
(PCMCIA)
2/4 port Ethernet
Card (IEEE 802.3)
Printer
Serial terminal
Specific Kinds included in
the Evaluation
Spyrus MCDISK-E
Adtron SDDS
Litonic 2108
Zynx ZX-34nQ, ZX-37n
Notes
multiple can be connected
up to 4 cards per system
HP 4000 series (supports PCL- parallel connection only
5)
Any ASCII-only printer that:
• does not support graphics
modes;
• does not support special
initialization sequences;
• uses XON/XOFF flow
control.
Must meet the requirements set
forth in the section Serial
Terminal Characteristics
below.
The processor incorporates its own ring protection mechanism supporting four rings,
descriptor privilege levels, gate descriptors, segment attributes (read, write, execute), and
call/return instruction. The privilege level (PL) protection mechanism ranges from PL0
(the most privileged) to PL3 (the least privileged).
STOP supports only single-processor hardware with Hyper-Threading disabled.
Other hardware that is not part of the TOE, but is an optional part of an XTS-400 system
includes:
•
APC Smart-UPS uninterruptible power supply
•
Mission Support Cryptographic Unit (MSCU)
24
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
This optional hardware has been reviewed by BAE - IT, but is not part of this evaluation
and might have to be subject to certification and accreditation efforts. The MSCU is a
proprietary PCI board that supports type 1 cryptography and has been separately
scrutinized by the U.S. National Security Agency. The software to support the MSCU is
part of the TOE and the evaluation.
Power, cooling, mechanical, and form factors are irrelevant.
2.1.2.1 Serial Terminal Characteristics
Any terminal connected to the XTS-400 system must provide, at a minimum, a keyboard
for providing input to the system, and a video display or printing device for transmitting
system output to the user in human-readable form. A video display must be capable of
displaying at least 24 lines at one time. The terminal must operate in full duplex (i.e.,
non-local echoing) mode.
Any terminal connected to the XTS-400 system must provide a correct association
between the user’s actions of depressing keyboard keys and transmitting the ASCII
representations of those keys via the communication interface. Any terminal connected to
the XTS-400 system must provide a correct association between the ASCII characters
transmitted from the system and their displayed or printed human-readable printed
representations at the terminal.
Any terminal connected to the XTS-400 system must provide a direct means of generating a serial BREAK signal through the terminal keyboard. Also, it must be impossible for
the terminal to generate the BREAK signal in response to any sequence of signals sent
from the system to it, and impossible for any sequence of signals sent from the system to
inhibit the terminal’s ability to generate the BREAK signal from the keyboard.
Any terminal connected to the XTS-400 system must provide a means of setting either
the Data Set Ready or the Carrier Detect signals, and a means of clearing both of these
signals. This means can be provided either by the terminal itself (such as turning the
terminal’s power off and on) or by an external mechanism between the terminal and the
XTS system.
Any terminal connected to the XTS-400 system must provide a means for the terminal
user to clear any internal (e.g., screen display, programmable function keys, buffer
memory) or external storage (e.g., printer paper, local disk) associated with the terminal
between user sessions.
If it is possible to reprogram, either under user or system control, any characteristics of a
terminal (such as the correspondence between keystrokes and transmitted characters), it
25
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
must be possible, at any time, for the terminal user to return all programmable
characteristics of the terminal to a default or well-known state.
2.1.3 TOE Definition
The TOE consists of:
a) the Kernel, TSS, OSS, and Trusted Software components
mentioned above;
b) some BAE - IT-written untrusted software to ease use of the
untrusted environment;
c) some third-party untrusted software that is shipped with XTS
systems to customers by BAE - IT to ease installation by the
customer and to provide the look and feel of a Linux system;
d) BIOS software to perform certain kinds of hardware
configuration or diagnostics;
e) hardware, as defined in the previous section.
The TOE also includes the optional XTS-400 AutoStart feature†. This feature activates
code that is already part of the TSF.
The TOE is not a distributed system, though it can be attached to multiple Ethernet
10baseT and 100baseT networks concurrently.
The TOE is not an embedded system.
The TOE does not provide a particular trusted application out-of-the-box, but is a
general-purpose system that can support many kinds of highly trusted applications. BAE
- IT and its customers have written a number of trusted applications which rely on the
security features provided by the XTS-400. These applications are not part of the TOE
addressed by this ST. Installation of these applications could invalidate the security rating
of the TOE due to the presence of privileged software, but they are designed to be secure
and some of them have been accredited.
The TOE is based on standard PC hardware, but can support concurrent use by multiple
users and can support multiple concurrent printer, terminal, and network connections.
26
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
2.2 General TOE Functionality
The conformant operating system includes the following security features:
2.2.1 Security Features
•
Identification and Authentication which mandates authorized users to be uniquely
identified and authenticated before accessing information stored on the system;
•
Discretionary Access Control (DAC) which restricts access to objects based on
the identity of subjects and/or groups to which they belong, and allows authorized
users to specify protection for objects that they control;
•
Mandatory Access Control (MAC) which enforces the U.S. DoD data sensitivity
classification model (i.e., Unclassified, Secret, Top Secret) on all authorized users
and all TOE resources;
•
Mandatory Integrity Control (MIC) which enforces an integrity policy on all
authorized users and TOE resources to prevent malicious entities from corrupting
data;
•
Audit services, which allow authorized administrators to detect and analyze
potential security violations.
•
Trusted path, which allows a user to be should s/he is interacting directly with the
TSF during sensitive operations.
•
Isolation, of the TSF code and data files from the activity of untrusted users and
processes.
•
Separation, of processes from one another (so that one process/user can not
tamper with the internal data and code of another process).
2.2.2 Other characteristics of compliant TOEs
•
the ability to process multiple security levels of information in a multilevel
environment,
•
an untrusted operating environment that includes most common Linux commands
and tools,
•
a programming API that allows most common Linux applications to run “out-ofthe-box”,
•
simultaneous network connectivity to at least 4 100baseT LANs,
27
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
•
the inability to provide mechanisms or services to ensure availability of data
residing on the TOE. [If availability requirements exist, the environment must
provide the required mechanisms (e.g., mirrored/duplicated data)], and
28
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
3 TOE Security Environment
3.1 Secure Usage Assumptions
A.Acc_to_Comms:
Physical protection of communications
Physical protection of the communications to the system is adequate to guard
against unauthorized access or malicious modification by users.
A.Admin_Docs:
Documentation for administrators
System Administrators follow the policies and procedures defined in the TOE
documentation for secure administration of the TOE.
A.Admin_Errors:
Potential for administrator errors
System administrators are fallible and occasionally make errors that compromise
security.
A.Clearance:
Authorization procedures
Procedures exist for granting users authorization for access to specific security
levels. This includes procedures for establishing one of more operators and
administrators.
A.Competent_Admin:
Competent system administrators
System administrators are competent to manage the TOE and the security of the
information it contains.
A.Coop_User:
Cooperative users
Users cooperate with those responsible for managing the TOE to maintain TOE
security, follow TOE user guidance, protect TOE secrets, and follow site
procedures.
A.Dispose_User_Data:
Disposal of user data
System Administrators properly dispose of user data after access has been
removed (e.g., due to job termination, change in responsibility).
A.Handling_of_Data:
Data handling procedures
Procedures exist for how sensitive, classified, and high-integrity data and secrets
are to be handled when they are in possession of an authorized user. Procedures
also exist for pick-up and distribution of hardcopy output at multi-user or multilevel printers.
A.No_Abuse_By_Admin:
No abusive system administrators
System Administrators are trusted not to abuse their authority.
29
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
A.Outsider_Hi:
Expert threat agents
The TOE is subject to deliberate attack by experts with advanced knowledge of
security principles and concepts employed by the TOE. These experts are
assumed to have substantial resources and high motivation.
A.Password_Management:
Password management promoting user compliance
System Administrators follow password management policies and procedures to
ensure users comply with password policies.
A.Peer:
Connectivity to other systems
Any other systems with which the TOE communicates are assumed to be under
the same management control and operate under the same security policy
constraints.
A.Phys_Acs_to_Out:
Physical access
The TOE is located within controlled access facilities that prevent unauthorized
physical access by outsiders.
A.Protect_From_Out:
TOE protection from outsiders
The TOE involved in security policy enforcement will be physically protected
from unauthorized modification by potentially hostile outsiders.
A.Review_Audit_Log:
Administrators review audit logs
System Administrators review audit logs regularly.
A.Secure_Term:
Terminal procedures
Procedures exist for how to restrict other system users, or non-system users, from
viewing terminal output on an authorized user’s terminal. This includes
considerations such as “looking over the shoulder”, an authorized user leaving his
or her terminal unattended, and terminal-specific instructions to erase terminallocal data following a logout.
A.Sensitivity:
Procedures for setting levels and marking
Procedures exist for establishing the security attributes of all information
imported into the system, for establishing the security attributes for all peripheral
devices (e.g., printers, tape drives, disk drives) attached to the TOE, and marking
a sensitivity label on all hardcopy output generated.
A.Trusted_User:
Trusted users
Authorized users are trusted not to compromise security.
A.User_Mistakes:
Mistakes by users
Users are fallible and occasionally make errors that compromise security.
30
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
A.Physical
Secure Physical Location
It is assumed that appropriate physical security is provided within the domain for
the value of the IT assets protected by the operating system and the value of the
stored, processed, and transmitted information.
A.No_Trusted_Network
Network Security Levels
Networks are single-level and unlabeled at layers 3 and below.
31
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
3.2 Security Threats
T.Admin_Err_Commit:
Administrative errors of commission
An administrator commits errors that directly compromise organizational security
objectives or change the technical security policy enforced by the system or
application.
T.Admin_Err_Omit:
Administrative errors of omission
The system administrator fails to perform some function essential to security. This
could leave user data open to unauthorized disclosure, modification, or deletion;
could allow an attack in progress to continue (which could jeopardize the TSF
itself); or could allow a user to continue to use the system with a clearance or
capabilities that have been determined to be too lenient.
T.Admin_Hostile_Modify:
Hostile administrator modification of user or system
data
An administrator maliciously obstructs organizational security objectives or
modifies the system's configuration to allow security violations to occur.
T.Covert_Channel†:
Covert channel allows MAC bypass
A hacker bypasses the MAC policy by use of covert channels. This could lead to
disclosure of sensitive user data to unauthorized users.
T.Dev_Flawed_Code:
Software containing security-related flaws
A system or applications developer delivers code that does not perform according
to specifications or contains security flaws. This could lead to arbitrary
compromise of user and TSF data, corruption of the TSF itself, and unauthorized
use of the system.
T.Hack_AC:
Hacker undetected system access
A hacker gains undetected access to a system due to missing, weak and/or
incorrectly implemented access control causing potential violations of integrity,
confidentiality.
T.Hack_Phys:
Exploitation of vulnerabilities in the physical
environment of the system
A hacker physically interacts with the system to exploit vulnerabilities in the
physical environment, resulting in arbitrary security compromises.
T.Hack_Social_Engineer:
Social engineering
A hacker uses social engineering techniques to gain information about system
entry, system use, system design, or system operation.
32
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
T.Insecure_Start:
Insecure startup after a system crash
After a system crash, the information used by the system is in an inconsistent state
that causes a TOE malfunction or allows circumvention of policy.
T.Malicious_Code:
Malicious code exploitation
An authorized user, IT system, or hacker downloads and executes malicious code,
which causes abnormal processes that violate the integrity or confidentiality of
system assets.
T.Objects_Not_Clean:
Residual data left in object
Residual information is left in an object and when reallocated to another subject,
the information is still viewable.
T.Power_Disrupt:
Unexpected disruption of system or component
power
A human or environmental agent disrupts power causing the system to lose
information or security protection.
T.Spoofing:
Legitimate system services are spoofed
An attacker tricks users into interacting with spurious system services. This could
allow disclosure of the users’ data to the attacker, unauthorized modification of
the users’ data by the attacker, and general circumvention of the user
identification and DAC mechanisms.
T.User_Improper_Export:
Hostile user acts cause confidentiality breaches
A user collects sensitive or proprietary information and removes it from the
system.
T.User_Abuse:
User abuses authorizations
User abuses granted authorizations to improperly collect sensitive or securitycritical data; to improperly change or destroy sensitive or security-critical data; or
to improperly send sensitive or security-critical data.
T.User_Error:
User errors cause security breaches
A user commits errors that cause information to be delivered to the wrong place
or wrong person; accidentally deletes user data or changes system data rendering
user data inaccessible; or commits errors that induce erroneous actions by the
system and/or erroneous statements by its users.
T.Trusted_User_Error:
Trusted user errors undermine the system's security
features
A trusted user commits errors that cause the system or one of its applications to
undermine the system's security features.
33
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
T.Audit_Corrupt
Corrupt Audit Records
A malicious trusted process or trusted user may cause audit records to be lost or
modified, or prevent future records from being recorded by taking actions to
exhaust audit storage capacity, thus masking an attacker’s actions.
T.Config_Corrupt
Corrupt Configuration Data
A malicious trusted process or trusted user may cause configuration data or other
trusted data to be lost or modified.
T.Improper_Installation
Installation Errors
Operating system may be delivered insecurely by the developer, or installed or
configured, by the operator, in a manner that undermines security.
T.Poor_Design
Design Errors
Unintentional or intentional errors in requirement specification, design or
development of the IT operating system, on the part of the developer, may occur.
T.Poor_Implementation
Implementation Errors
Unintentional or intentional errors in implementing the design of the IT operating
system, on the part of the developer, may occur.
T.Poor_Test
Inadequately Tested
Incorrect system behavior may result from inability, on the part of the system
operator, to demonstrate that all functions and interactions within the operating
system operation are correct.
T.Replay
Replay
A malicious process or user may gain access by replaying authentication (or
other) information. This could allow unauthorized use of the system and allow
unauthorized access to user data (as the attacker could operate with the identity
and clearance of the user whose authentication information was copied).
T.Sysacc
Unauthorized Admin Access
A malicious process or user may gain unauthorized access to the administrator
account, or that of other trusted personnel. This could allow unauthorized use of
the system and unauthorized access to both user and TSF data (as the attacker
could operate with the identity and clearance of the trusted user whose account
was used).
T.Unattended_Session
Unauthorized Session Access
A malicious process or user may gain unauthorized access to an unattended
session. This could allow unauthorized use of the system and allow unauthorized
access to user data (as the attacker could operate with the identity and clearance of
the user whose session was taken).
34
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
T.Unauth_Modification
Unauthorized Modifications
Unauthorized modification or use of IT operating system attributes and resources,
by a malicious user or process, may occur.
T.User_Corrupt
Corrupt User Data
User data may be lost or tampered with by other users.
3.3 Secure Usage Policies
P.Accountability
Individual Accountability
Individuals shall be held accountable for their actions.
P.Authorities
Authorities Notified of Threats
Appropriate authorities shall be immediately notified of any threats or
vulnerabilities impacting systems that process their data.
P.Authorized_Use
Authorized Use of Information
Information shall be used only for its authorized purpose(s)
P.Authorized_Users
Authorized Use of System
Only those users who have been authorized to access the information within the
system may access the system.
P.Availability
Availability of Information
Information shall be available to satisfy mission requirements.
P.Classification
Access must be limited by sensitivity
The system must limit the access to information based on sensitivity, as
represented by a label, of the information contained in objects, and the formal
clearance of users, as represented by subjects, to access that information. The
access rules enforced prevent a subject from accessing information which is of
higher sensitivity than it is operating at and prevent a subject from causing
information from being downgraded to a lower sensitivity.
P.Guidance
Installation and Use Guidance
Guidance shall be provided for the secure installation and use of the system.
P.Information_AC
Information Access
Information shall be accessed only by authorized individuals and processes.
35
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
P.Integrity
Information Integrity
Information shall retain its content integrity.
P.Marking
Information Marking and Labeling
Information shall be appropriately marked and labeled.
P.Need_to_Know
Users must have a need to know
The system must limit the access to and modification of the information in
protected resources to those authorized users which have a “need to know” for
that information.
P.Physical_Control
Information Physically Protected
Information shall be physically protected to prevent unauthorized disclosure,
destruction, or modification.
36
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
4 Security Objectives
Listed below are the objectives for the TOE and for the IT environment. Objectives
marked with “*” map to objectives of the LSPP, to which this ST claims conformance.
4.1 Security Objectives for the TOE
O.AC_Admin_Limit:
Limitation of administrative access control
Design administrative functions in such a way that administrators do not
automatically have access to user objects, except for necessary exceptions. For an
accounts administrator, the necessary exceptions include allocation and deallocation of storage. For an audit administrator, the necessary exceptions include
observation of audited actions. In general, the exceptions tend to be role specific.
O.Audit_Gen_User*
Individual accountability
Provide individual accountability for audited events. Uniquely identify each user
so that auditable actions can be traced to a user.
O.Access*
User authorized access
The IT operating system will ensure that users gain only authorized access to it
and to its resources that it controls.
O.Access_History
Authorized user access history
The system will display information (to authorized users) related to previous
attempts to establish a session.
O.Admin_Role
Isolate administrative actions
The operating system will provide an administrator role to isolate administrative
actions.
O.Admin_Trained*
Trained administrators
The IT operating system will provide authorized administrators with the necessary
information for secure management.
O.Audit_Generation*
Audit generation
The IT operating system will provide the capability to detect and create records of
security relevant events associated with users.
O.Audit_Protection
Protect audit
The IT operating system will provide the capability to protect audit information.
37
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
O.Audit_Review*
Selectively view audit
The IT operating system will provide the capability to selectively view audit
information.
O.Authorities
Authorities notified of threats
The system vendor will have a flaw remediation mechanism in place such that
appropriate authorities shall be notified of any threats or vulnerabilities impacting
the TOE.
O.Config_Mgmt*
Configuration management
All changes to the operating system and its development evidence will be tracked
and controlled.
O.Discretionary_Access*
Discretionary access control
The IT operating system will control accesses to resources based upon the identity
of users and groups of users.
O.Discretionary_User_Control*
Discretionary user access
The IT operating system will allow authorized users to specify which resources
may be accessed by which users and groups of users.
O.Display_Banners
Sensitivity banner display
The system will display an advisory warning regarding use of the TOE.
O.Install*
Installation guidance
The IT operating system will be delivered with the appropriate installation
guidance to establish and maintain IT security.
O.Manage*
Administrator support management
The IT operating system will provide all the functions and facilities necessary to
support the authorized administrators in their management of the security of the
IT system.
O.Mandatory_Access*
Mandatory access control
The IT operating system will control accesses to resources based upon the
security levels of users and resources and the “need to know” of the users. User
use of covert channels will be limited also†.
O.Mandatory_Integrity
Mandatory integrity control
The IT operating system will control accesses to resources based upon the
integrity levels of users and resources and the “need to know” of the users.
O.Markings
Sensitivity markings
The IT operating system will provide the capability to mark printed output with
accurate sensitivity labels.
38
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
O.Protect
Data and resource protection
The IT operating system will provide means to protect user data and resources.
O.Recovery
Assured recovery
Procedures and/or mechanisms will be provided to assure that recovery is
obtained without a protection compromise, such as from system failure or
discontinuity.
O.Residual_Information*
Residual information
The IT operating system will ensure that any information contained in a protected
resource is not released when the resource is reallocated.
O.Self_Protection
Self protecting system
The operating system will maintain a domain for its own execution that protects
itself and its resources from external interference, tampering, or unauthorized
disclosure.
O.Sound_Design*
Practice sound design
The design of the IT operating system will be the result of sound design principles
and techniques, which are accurately documented.
O.Sound_Implementation*
Sound implementation
The implementation of the IT operating system will be an accurate instantiation of
its design.
O.Testing
Testing of TOE code
The IT operating system will be tested functionally, with moderate levels of depth
and coverage, tested independently, and subjected to penetration testing.
O.Trained_Users
User training
The IT operating system will provide authorized users with the necessary
guidance for secure operation.
O.Trusted_Path
Trusted path
The operating system will provide a means to ensure users are not communicating
with some other entity pretending to be the operating system.
O.Trusted_System_Operation*
Trusted system operation
The IT operating system will function in a manner that maintains IT security.
O.User_Authentication
Verify user identity
The operating system will verify the claimed identity of the user.
O.User_Identification
Unique user identity
The operating system will uniquely identify users.
39
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
O.Vulnerability_Analysis
Vulnerability analysis
The TOE shall undergo a comprehensive vulnerability analysis as described in the
assurance requirements.
40
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
4.2 Security Objectives for the Environment
OE.Admin
Administators competent
Individuals given the role of administrator are competent and trustworthy with
regard to managing the TOE and the security aspects of the users and information
associated with the TOE. These individuals understand the TOE administrative
guidance and site-specific procedures and follow that guidance and those
procedures.
OE.Clearance
Procedures to establish authorizations
Procedures will be provided to determine the “trust” (in terms of MAC and MIC
clearance, group membership, XTS capabilities, and access to the console), and
needs-to-know, for each system user.
OE.Handling_of_Data*
Data handling procedures
Procedures will be provided for how sensitive, classified, and high-integrity data
and secrets are to be handled when they are in possession of an authorized user.
Procedures also will be provided for pick-up and distribution of hardcopy output
at multi-user or multi-level printers.
OE.Network_Mgmt
Network management
If the TOE is connected to a network, all equipment on the network must be under
a common management to ensure that all connections to the TOE are at a
particular MAC and MIC level.
OE.Physical*
Physical security
Physical security will be provided within the domain for the value of the IT assets
protected by the operating system and the value of the stored, processed, and
transmitted information.
OE.Secure_Term:
Terminal procedures
Procedures will be provided for how to restrict other system users, or non-system
users, from viewing terminal output on an authorized user’s terminal. This
includes considerations such as “looking over the shoulder”, an authorized user
leaving his or her terminal unattended, and terminal-specific instructions to erase
terminal-local data following a logout.
OE.Sensitivity:
Procedures for setting levels and marking
Procedures will be provided for establishing the security attributes of all
information imported into the system, for establishing the security attributes for
all peripheral devices (e.g., printers, tape drives, disk drives) attached to the TOE,
and marking a sensitivity label on all hardcopy output generated.
41
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
OE.User
Users competent
Individuals given access to the TOE are competent with regard to understanding
the TOE user guidance and site-specific procedures and trustworthy with respect
to following the guidance and procedures. Users given additional clearance, group
membership, capabilities, or access to the console are competent to understand the
security ramifications and trusted to use those “powers” safely.
42
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5 IT Security Requirements
This section defines the functional requirements with in the ST that are the basis of the
TOE Functional Requirements. The sub-sections contained in this section will define
each functional requirement from the CC part 2 as they relate to the TOE. In some cases,
the requirements allow for assignment, selection, or refinement of specific parameters or
variables. The assignments, selections, and refinements (and iterations) of these
requirements are represented as described in section 1.4 Conventions.
These security functional requirements are summarized in Table 5-1. Requirements that
are part of the LSPP (to which this ST claims conformance) are denoted with “*” in the
table.
Table 5-1 Security Functional Requirements
Class Name
Security
Audit
Functional Family
FAU_GEN.1*
FAU_GEN.2*
FAU_SAA.1
FAU_SAR.1*
FAU_SAR.2*
FAU_SAR.3*
FAU_SEL.1-NIAP-0407*
User Data
Protection
FAU_STG.2-NIAP-0422
FAU_STG.3*
FAU_STG.4*
FDP_ACC.2
FDP_ACF.1-NIAP-0407*
FDP_ETC.1*
FDP_ETC.2*
FDP_IFC.2
FDP_IFF.2-NIAP-0417*
Dependencies
FPT_STM.1
FAU_GEN.1,
FIA_UID.1
FAU_GEN.1
FAU_GEN.1
FAU_SAR.1
FAU_SAR.1
FAU_GEN.1,
FMT_MTD.1
FAU_GEN.1
FAU_STG.1
FAU_STG.1
FDP_ACF.1
FDP_ACC.1,
FMT_MSA.3
{FDP_ACC.1
or FDP_IFC.1}
{FDP_ACC.1
or FDP_IFC.1}
FDP_IFF.1
FDP_IFC.1,
FMT_MSA.3
43
UNCLASSIFIED
Hierarchical to
None
None
None
None
None
None
None
FAU_STG.1*
None
FAU_STG.3
FDP_ACC.1*
None
None
None
FDP_IFC.1*
FDP_IFF.1
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Functional Family
FDP_ITC.1*
FDP_ITC.2-NIAP-0407*
Identification
and
Authenticatio
n
Security
Management
FDP_RIP.2*
FIA_AFL.1-NIAP-0425
FIA_ATD.1*
FIA_SOS.1*
FIA_UAU.2
FIA_UAU.4
FIA_UAU.7*
FIA_UID.2
FIA_USB.1-NIAP-0415*
FMT_MOF.1
FMT_MSA.1*
FMT_MSA.2
FMT_MSA.3-NIAP-0409*
FMT_MTD.1*
FMT_MTD.2
FMT_REV.1*
FMT_SAE.1
FMT_SMF.1
Dependencies
FMT_MSA.3,
{FDP_ACC.1
or FDP_IFC.1}
FPT_TDC.1,
{FDP_ACC.1
or
FDP_IFC.1},
{FTP_ITC.1
OR
FTP_TRP.1}
None
FIA_UAU.1
None
None
FIA_UID.1
None
FIA_UAU.1
None
FIA_ATD.1
FMT_SMR.1,
FMT_SMF.1
FDP_ACC.1,
FDP_IFC.1,
FMT_SMR.1,
FMT_SMF.1
ADV_SPM.1,
FMT_MSA.1,
FMT_SMR.1
{FDP_ACC.1
or FDP_ICF.1}
FMT_MSA.1,
FMT_SMR.1
FMT_SMR.1,
FMT_SMF.1
FMT_MTD.1,
FMT_SMR.1
FMT_SMR.1
FMT_SMR.1,
FPT_STM.1
None
44
UNCLASSIFIED
Hierarchical to
None
None
FDP_RIP.1
None
None
None
FIA_UAU.1*
None
None
FIA_UID.1*
None
None
None
None
None
None
None
None
None
None
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Protection of
the TOE
Security
Functions
TOE Access
Trusted
Path/Channel
s
Functional Family
FMT_SMR.1*
FMT_SMR.3
FPT_AMT.1*
FPT_RCV.2-NIAP-406
FPT_RVM.1*
FPT_SEP.1*
FPT_STM.1*
FPT_TST.1
FTA_SSL.3
FTA_TAB.1
FTA_TAH.1
FTP_TRP.1
Dependencies
FIA_UID.1
FMT_SMR.1
None
FPT_TST.1,
AGD_ADM.1,
ADV_SPM.1
None
None
None
FPT_AMT.1
None
None
None
None
Hierarchical to
None
None
None
FPT_RCV.NIAP-0389-1
None
None
None
None
None
None
None
None
5.1 TOE Security Functional Requirements
5.1.1 Security audit (FAU)
5.1.1.1 Audit data generation (FAU_GEN.1)
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following
auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the basic level of audit;
c) all auditable events listed in Appendix F.
Application Note: Records of the start-up and shutdown of audit functions can be
indirect, e.g., the system startup and shutdown records imply start and stop of auditing. It
is assumed that auditing continues to function even through system reboots and has to be
actively disabled. Enabling and disabling of audit functions can be marked with a record
showing use of an administrative command that performs those functions. Enabling and
disabling of the audit functions may not actually take effect until the system is rebooted.
FAU_GEN.1.2-NIAP-0347 The TSF shall record within each audit record at least the
following information:
45
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
a) Date and time of the event, type of event, subject identity (if applicable),
and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, the MAC (sensitivity) and
MIC levels of the process, effective owner and group of the process,
effective privileges of the process; and the following specific
information for the following kinds of events:
Audit Event
Those associated with particular
objects or information
All requests to perform an
operation on an object covered
by the SFP (FDP_ACF.1-NIAP0407)
All use of the user identification
mechanism, including the
identity provided during
successful attempts (FIA_UID.2)
All modifications of the values of
TSF data, including audit data
(FMT_MTD.1)
Modifications to the group of
users that are part of a role and
every use of the rights of a role
(FMT_SMR.3)
Additional Information in
Audit Record
the sensitivity level of the
object or information
the identity of the object
The origin of the attempt (e.g.,
terminal identification)
The new value of the TSF data
The role and origin of the
request
5.1.1.2 User identity association (FAU_GEN.2-NIAP-0410)
FAU_GEN.2.1 For audit events resulting from actions of identified users, The the TSF
shall be able to associate each auditable event with the identity of the user that caused the
event.
5.1.1.3 Potential Violation Analysis (FAU_SAA.1)
FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the audited
events and based upon these rules indicate a potential violation of the TSP.
FAU_SAA.1.2-NIAP-0407 The TSF shall enforce the following rules for monitoring
audited events:
46
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
a) Accumulation or combination of failed login attempts known to indicate a
potential security violation;
b) No additional rules
5.1.1.4 Audit review (FAU_SAR.1)
FAU_SAR.1.1 The TSF shall provide authorized administrator with the capability to
read Size of the audit record; Type of event being audited; Time the audit record is
generated; Process ID of the process causing the audit event; MAC label of the
process; Effective privileges of the process; Real user ID; Real group ID from the
audit records.
FAU_SAR.1.2 Refinement: The TSF shall provide the audit records in a manner suitable
for the authorized administrator to interpret the information using a tool to access the
audit trail.
5.1.1.5 Restricted audit review (FAU_SAR.2)
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except
those users that have been granted explicit read-access.
5.1.1.6 Selectable Audit review (FAU_SAR.3)
FAU_SAR.3.1 The TSF shall provide the ability to perform searches of audit data based
on the following attributes:
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
m)
n)
audit event
device name
file name
process ID
start date
stop date
trusted editor name
trusted editor request
user ID
group ID
semaphore ID
shared memory ID
object MAC (sensitivity) and MIC level
subject sensitivity level
Application Note: Attribute selection may be any or all that are searchable.
5.1.1.7 Selective audit (FAU_SEL.1-NIAP-0407)
FAU_SEL.1.1-NIAP-0407 The TSF shall be able to include or exclude auditable events
from the set of audited events based on the following attributes:
47
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
a) event type, user identity;
b) object MAC (sensitivity) and MIC level;
c) subject sensitivity level.
Application Note: Appendix G provides a list of all of the audit events that are selectable
(as displayed by the help function of the param_edit command).
5.1.1.8 Guarantees of audit data availability (FAU_STG.2-NIAP-0422)
FAU_STG.2.1 -NIAP-0422 The TSF shall protect the stored audit records in the audit
trail from unauthorized deletion.
FAU_STG.2.2 -NIAP-0423 The TSF shall be able to prevent unauthorized
modifications to the audit records in the audit trail.
FAU_STG.2.3 The TSF shall ensure that all audit records will be maintained when the
following conditions occur: audit storage exhaustion.
Application Note: When audit storage exhaustion occurs, the system may shutdown, or
with operator notice, transition to a maintenance mode of operation.
5.1.1.9 Action in case of possible audit data loss (FAU_STG.3)
FAU_STG.3.1 The TSF shall take generate an alarm to the authorized administrator
if the audit trail exceeds a configured number of recent audit files.
Application Note: The alarm may be a text message to the system console. An
administrator can configure a value for the number of new audit files.
5.1.1.10 Prevention of audit data loss (FAU_STG.4)
FAU_STG.4.1 The TSF shall prevent auditable events, except those taken by the
authorized user with special rights and cause the system to shutdown if the audit trail is
full.
Application Note: Disk space available for audit files is based upon the size of the hard
drive.
5.1.2 User data protection (FDP)
5.1.2.1 Complete Access Control (FDP_ACC.2)
FDP_ACC.2.1 The TSF shall enforce the Discretionary Access Control policy on all
subjects and all named objects and all operations among subjects and objects covered
by the SFP.
48
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Application Note: The TOE supports only one subject type: a process (see Appendix B). A
discussion of TOE supported objects is in Appendix C.
FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in the TSC
and any object within the TSC are covered by an access control SFP.
5.1.2.2 Access Control Functions (FDP_ACF.1-NIAP-0407)
FDP_ACF.1.1-NIAP-0407 The TSF shall enforce the Discretionary Access Control
policy to objects based on the following types of subject and object security attributes:
a) For all subjects and objects:
• owner’s UID and the allowed and denied operations for that
user;
• owner’s group and the allowed and denied operations for that
group;
• other listed users and/or groups and the allowed and denied
operations for those users and/or groups; and
• the allowed and denied operations for other unlisted users
and/or groups;
b) For all subjects, the “real” (originating) owner and group;
c) For shared memory and semaphore objects, the creating owner.
Application Note: The owner and group for some objects, such as TCP/IP sockets and
anonymous memory, may be implicit in the process which created the object (and which
must have the object mapped for the entire life of the object).
Application Note: The allowed operations for the owner and group for some objects, such
as TCP/IP sockets and anonymous memory, may be implicitly set and unchangeable.
Application Note: This requirement includes only implementations where access control
attributes are associated with objects rather than subjects. This implementation becomes
critical when satisfying FMT_MTD.1.1 and FMT_REV.1.1(1) .
FDP_ACF.1.2 Refinement: The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled named objects is allowed:
a) The appropriate access permissions are selected by the following
rules:
• The owning user is compared with the active user. If they match,
the access permissions for the owning user are used.
•
If the owning user does not match the active user, the ACL is
examined to determine if there are any ACL entries that match
the active user requesting access. If an entry is found that matches
(the first one found is used), the access permissions associated with
that ACL entry are used.
49
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
•
If no match is found for the active user in the ACL, the owning
group is then compared against the active group. If this
comparison is successful, the access permissions for the owning
group are used.
•
If the owning group does not match the active group, the ACL is
examined to find the first entry (if any) that matches the active
group. If such an entry is found, the access permissions associated
with that entry are used.
•
If no match is found for the active group in the ACL, the “others"
access permissions are used.
b) Once a match is found, the permissions are examined to determine if
the requested mode of access is one of the allowed access modes for
that subject.
Application note: There are three allowed access mode bits in the owner and group
permission and in each ACL entry; any combination is syntactically valid (although it
may have no semantic meaning). These bits are:
• read: If this bit is set, the user or group is allowed read access to the
object (if allowed by the other access and information flow policies).
•
write: If this bit is set, the user or group is allowed write access to the
object (if allowed by the other access and information flow policies).
This also allows append and deletion, though deletion of file system
objects depends not on the object’s permissions, but on the
permissions of the containing directory.
•
execute: If this bit is set, the user or group is allowed “execute” access
to the object (if read access is allowed by the other access and
information flow policies). This bit may be ignored or be meaningless
for certain types of objects (for example: devices, named First-In
First-Out (FIFOs), processes). For directory file system objects, this
bit is not interpreted as “execute," but as “search."
If the particular bit for that type of access is not set, the corresponding user or group is
denied that mode of access. Hence, to deny access to a given user or group, the bits for
all types of access would not be set.
FDP_ACF.1.3-NIAP-0407 Refinement: The TSF shall explicitly authorize access of
subjects to named objects based on the following additional rules:
The TSF shall allow the overriding of discretionary access controls by an
authorized administrator when integrity is set to administrator levels or
as operator when particular trusted commands within the TSF are
executed at integrity level of at least “operator”.
50
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Application Note: This element allows specifications of additional rules for authorized
administrators to bypass the Discretionary Access Control policy for system management
or maintenance (e.g., system backup).
FDP_ACF.1.4-NIAP-0407 The TSF shall explicitly deny access of subjects to objects
based on the following rules: no additional explicit denial rules.
5.1.2.3 Export of User Data Without Security Attributes (FDP_ETC.1)
FDP_ETC.1.1 The TSF shall enforce the Mandatory Access Control, Mandatory
Integrity Control and Discretionary Access Control policies when exporting user data,
controlled under the SFPs, outside of the TSC.
FDP_ETC.1.2 Refinement: The TSF shall export the unlabeled user data without the
user data’s associated security attributes and shall enforce the following rules when
unlabeled user data is exported from the TSC:
a) Devices used export data without security attributes cannot be used to
export data with security attributes unless the change in device state is
performed manually and is auditable;
b) The devices used for export do have MAC, MIC, and DAC attributes
and these are implicitly the attributes of the exported information;
c) Normal MAC, MIC, and DAC policy rules govern access from
subjects to any export device and such access will be auditable;
d) Only an operator or administrator can modify the MAC or MIC
attributes of a device and only the owner of a device can modify the
device’s DAC attributes;
e) All changes to device security attributes are auditable;
f) Devices which are in use by the TSF can not simultaneously be used
for export of unlabeled user data.
Application Note: Includes tar files, network devices and cpio files.
5.1.2.4 Export of User Data with Security Attributes (FDP_ETC.2)
FDP_ETC.2.1 Refinement: The TSF shall enforce the Mandatory Access Control,
Mandatory Integrity Control, and Discretionary Access Control policies when
exporting labeled user data, controlled under the SFPs, outside of the TSC.
FDP_ETC.2.2 Refinement: The TSF shall export the labeled user data with the user
data’s associated security attributes.
FDP_ETC.2.3 Refinement: The TSF shall ensure that the security attributes, when
exported outside the TSC, are unambiguously associated with the exported labeled user
data.
51
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
FDP_ETC.2.4 Refinement: The TSF shall enforce the following rules when labeled user
data is exported from the TSC:
a. When data is exported in hardcopy form:
• The first (“banner”) page and last page shall be marked with a
printed representation of the “least upper bound” sensitivity label
of all data exported to the page;
• By default, this marking shall also appear on both the top and
bottom of each printed page, though a user whom has been
granted a special capability by a user administrator can override
this default (and the override is auditable);
• An authorized administrator can modify the printed
representation of sensitivity labels, though the system provides a
sensible default.
b. If a device is capable of maintaining data security attributes, and the
device is being managed by the TSF, the security attributes shall be
exported with the data and the device shall completely and
unambiguously associate the security attributes with the
corresponding data.
c. Devices used to export data with security attributes cannot be used to
export data without security attributes unless the change in device
state is performed manually and is auditable
d. The security attributes of exported data shall include Mandatory
Access Controls, Mandatory Integrity Controls, and Discretionary
Access Controls. This applies to mounted file systems and tape
backups.
Application Note: This does not apply to tar files, or cpio. Additionally, data transferred
via network will be exported at the level of the process writing to a socket, however, the
data itself will possess no MAC or MIC information. Files may possess DAC information
(files sent using FTP for instance). Printed hardcopy is the only exported, labeled
information that is “human-readable”.
5.1.2.5 Complete Information flow control (for Mandatory Access Control Policy)
(FDP_IFC.2(1))
FDP_IFC.2.1(1) Refinement: The TSF shall enforce the Mandatory Access Control
policy on all subjects and all objects, and all operations that cause that information to
flow to and from subjects covered by the MAC policy.
FDP_IFC.2.2(1) The TSF shall ensure that all operations that cause any information in
the TSC to flow to and from any subject in the TSC are covered by an information flow
control SFP.
52
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.2.6 Complete Information flow control (for Mandatory Integrity Control
Policy) (FDP_IFC.2(2))
FDP_IFC.2.1(2) The TSF shall enforce the Mandatory Integrity Control policy on all
subjects and all objects, and all operations that cause that information to flow to and
from subjects covered by the SFP.
Application Note: The TOE supports only one subject type: a process (see Appendix B). A
discussion of TOE supported objects is in Appendix C. The information for subjects and
objects is provided in the appendices so that it is more readily accessible for updating the
information.
Application Note: The Mandatory Integrity Control policy is based upon trustworthiness:
subjects with a low degree of trustworthiness cannot change data of a higher degree of
trustworthiness. A subject with a high degree of trustworthiness cannot be forced to rely
on data of a low degree of trustworthiness.
FDP_IFC.2.2(2) The TSF shall ensure that all operations that cause any information in
the TSC to flow to and from any subject in the TSC are covered by an information flow
control SFP.
Application Note: The TOE supports only one subject type: a process (see Appendix B).
The information for subjects is provided in the appendices so that it is more readily
accessible for updating the information.
5.1.2.7 Hierarchical Security Attributes (for Mandatory Access Control)
(FDP_IFF.2-NIAP-0417(1))
FDP_IFF.2.1-NIAP-0417(1) The TSF shall enforce the Mandatory Access Control
policy based on the following types of subject and information security attributes:
a) For all subject types (see Appendix B) and objectinformation types (see
Appendix C): a sensitivity label (current MAC level), consisting of at least 16
site definable hierarchical levels and a set of 64 site definable nonhierarchical categories;
b) For all subjects: the users’s maximum MAC level (which is also a sensitivity
label) and the effective user ID;
c) For all information types: the owner ID.
Application Note: The implementation of sensitivity labels does not need to store labels in
a format that has the components of the label explicitly instantiated, but may use some
form of tag which maps to a level and category set.
Application Note: The sensitivity labels of TCP/IP sockets and anonymous memory
objects may be implicit in that it is the same as the subject that created it (and that must
always have the object mapped while the object exists).
53
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
FDP_IFF.2.2(1) Refinement: The TSF shall permit an information flow among subjects
and objects based on the following rules:
a) If the sensitivity label of the subject is greater than (see FDP_IFF.2.7NIAP-0417) or equal to the sensitivity label of the object, then the flow
of information from the object to the subject is permitted (a read
operation);
b) If the sensitivity label of the object is greater than or equal to the
sensitivity label of the subject; then the flow of information from the
subject to the object is permitted (a write operation);
Application Note: where the label of the object is greater than the label of the subject,
this is a blind append (i.e., write does not imply a read).
c) If the information flow is between objects, the sensitivity label of the
destination object must be greater than (see FDP_IFF.2.7) or equal to
the sensitivity label of the source object.
FDP_IFF.2.3-NIAP-0407(1) The TSF shall enforce the following information flow
control rules:
a) subjects can not operate at mandatory levels above, create objects at
mandatory levels above, or change the mandatory level of an object to
a level above, the clearance of the owning user;
b) writes to file system and device objects must be at the level of the
object (write-up is not allowed);
c) reads to socket device objects must be at the level of the object (readdown is not allowed).
FDP_IFF.2.4-NIAP-0407 (1) The TSF shall provide the following:
a) each user must be assigned a clearance by an authorized
administrator where the clearance is within the mandatory range
allowed by the system;
b) a user can disable per-page security markings on hardcopy output, if
s/he has been granted that capability by an authorized administrator;
c) a user can not upgrade nor downgrade the mandatory level of an
object, unless s/he has been granted those capabilities by an
authorized administrator.
54
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
FDP_IFF.2.5(1) Refinement: Authorized users may bypass MAC by setting their
integrity level to “admin” and executing certain TSF commands. Some commands
may also require a user to posses a capability added to their account by the system
administrator.
Application Note: See Appendix D for a list of TSF commands, and Appendix E for a list
of User commands.
Application Note: These rules regulate the behavior for each of the roles identified under
FMT_SMR.
FDP_IFF.2.6-NIAP-0407 (1) The TSF shall explicitly deny an information flow based on
the following rules: no explicit denial rules.
FDP_IFF.2.7(1) Refinement: The TSF shall enforce the following relationships for any
two valid sensitivity labels:
a) There exists an ordering function that, given two valid security attributes,
determines if the security attributes are equal, if one security attribute is
greater than the other, or if the security attributes are incomparable; and
1) Sensitivity labels are equal if the hierarchical level of both labels
are equal and the non-hierarchical category sets are equal;
2) Sensitivity label A is greater than sensitivity label B if one of the
following conditions exist:
i. If the hierarchical level of A is greater than the hierarchical
level of B, and the non-hierarchical category set of A is equal to
the non-hierarchical category set of B.
ii. If the hierarchical level of A is equal to the hierarchical level of
B, and the non-hierarchical category set of A is a proper superset of the nonhierarchical category set of B.
iii. If the hierarchical level of A is greater than the hierarchical
level of B, and the non-hierarchical category set of A is a
proper super-set of the non-hierarchical category set of B.
3) Sensitivity labels are incomparable if they are not equal and
neither label is greater than the other.
b) There exists a “least upper bound” in the set of sensitivity labels, such
that, given any two valid sensitivity labels, there is a valid sensitivity
label that is greater than or equal to the two valid sensitivity labels; and
c) There exists a “greatest lower bound” in the set of sensitivity labels, such
that, given any two valid sensitivity labels, there is a valid sensitivity
label that is not greater than the two valid sensitivity labels.
55
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Application Note: “Sensitivity labels” are equivalent to MAC security attributes.
5.1.2.8 Hierarchical Security Attributes (for Mandatory Integrity Control)
(FDP_IFF.2-NIAP-0417(2))
FDP_IFF.2.1-NIAP-0417(2) The TSF shall enforce the Mandatory Integrity Control
policy based on the following types of subject and security information attributes:
a) For all subject types (see Appendix B) and information types (see
Appendix C): an integrity label (current MIC level) containing at least
8 site-definable hierarchical levels and at least 16 non-hierarchical
categories;
b) For all subjects: the user’s maximum MIC level (which is also an
integrity label) and the effective user ID;
c) For all information types: the owner ID.
Application Note: Example of such integrity labels are those cited in the Biba Integrity
policy.
Application Note: For this family (FDP_IFF) the term “security attributes” refers only to
the integrity labels of subject and objects.
FDP_IFF.2.2(2) Refinement: The TSF shall permit an information flow among subjects
and objects based on the following rules:
a) If the integrity label of the subject is greater than or equal to the
integrity label of the object, then a write (the flow of information from
the subject to the object) is permitted;
b) If the integrity label of the object is greater than or equal to the
integrity label of the subject; then a read (the flow of information
from the object to the subject) is permitted;
c) If the information flow is between objects, the integrity label of the
source object must be greater than or equal to the sensitivity label of
the destination object.
FDP_IFF.2.3-NIAP-0407(2) The TSF shall enforce the following information flow
control rules:
a) subjects can not operate at integrity levels below, create objects at
integrity levels below, or change the integrity level of an object to a
level below, the clearance of the owning user;
b) writes to file system and device objects must be at the level of the
object (write-down is not allowed);
c) reads to socket device objects must be at the level of the object (readup is not allowed).
56
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
FDP_IFF.2.4-NIAP-0407(2) The TSF shall provide the following:
a) each user must be assigned a clearance by an authorized
administrator where the clearance is within the integrity range
allowed by the system;
b) a user can not upgrade nor downgrade the integrity level of an object,
unless s/he has been granted those capabilities by an authorized
administrator.
FDP_IFF.2.5(2) Refinement: Authorized users may bypass MIC by setting their
integrity level to “admin” and executing certain TSF commands. Some commands
may also require a user to posses a capability added to their account by the system
administrator.
Application Note: See Appendix D for a list of TSF commands, and Appendix E for a list
of User commands.
Application Note: These rules regulate the behavior for each of the roles identified under
FMT_SMR.
FDP_IFF.2.6-NIAP-0407(2) The TSF shall explicitly deny an information flow based on
the following rules: no explicit denial rules.
FDP_IFF.2.7(2) Refinement: The TSF shall enforce the following relationships for any
two valid MIC security attributes:
a) There exists an ordering function that, given two valid security attributes,
determines if the security attributes are equal, if one security attribute is
greater than the other, or if the security attributes are incomparable; and
b) There exists a “least upper bound” in the set of security attributes, such
that, given any two valid security attributes, there is a valid security
attribute that is greater than or equal to the two valid security attributes;
and
c) There exists a “greatest lower bound” in the set of security attributes, such
that, given any two valid security attributes, there is a valid security
attribute that is not greater than the two valid security attributes.
5.1.2.9 Import of User Data without Security Attributes (FDP_ITC.1)
FDP_ITC.1.1 Refinement: The TSF shall enforce the Mandatory Access Control,
Mandatory Integrity Control, and Discretionary Access Control policies when
importing unlabeled user data, controlled under the SFP, from outside the TSC.
FDP_ITC.1.2 Refinement: The TSF shall ignore any security attributes associated with
the unlabeled user data when imported from outside the TSC.
57
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
FDP_ITC.1.3 Refinement: The TSF shall enforce the following rules when importing
unlabeled user data controlled under the SFP from outside the TSC:
a. The TSF shall label the data with the MAC and MIC labels of the
device by which the data is imported;
b. When importing data, the data is to be given the effective owner and
group attributes of the importer of the data;
c. Devices used to import data without security attributes cannot be used
to import data with security attributes unless the change in device
state is performed manually and is auditable.
5.1.2.10 Import of User Data with Security Attributes (FDP_ITC.2-NIAP-0407)
FDP_ITC.2.1 Refinement: The TSF shall enforce the Mandatory Access Control,
Mandatory Integrity Control, Discretionary Access Control policies, when importing
labeled user data, controlled under the SFP, from outside the TSC.
FDP_ITC.2.2 Refinement: The TSF shall use the security attributes associated with the
imported labeled user data.
FDP_ITC.2.3 Refinement: The TSF shall ensure that the protocol used provides for the
correct unambiguous association between the imported security attributes and the
imported, labeled user data.
FDP_ITC.2.4 Refinement: The TSF shall ensure that interpretation of the security
attributes of the imported user data is as intended by the source of the labeled user data.
FDP_ITC.2.5-NIAP-0407 Refinement: The TSF shall enforce the following rules when
importing labeled user data controlled under the SFP from outside the TSC:
a. Devices used to import data with security attributes cannot be used to
import data without security attributes unless the change in device state
is performed manually and is auditable;
b. Sensitivity label, consisting of the following:
• A hierarchical level; and
• A set of non-hierarchical categories.
Application Note: Applies only to filesystems and saves on removable media.
5.1.2.11 Full residual information protection (FDP_RIP.2)
FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is
made unavailable upon the allocation of the resource to all objects.
Application Note: To implement “allocation of the resource to” an object, the TOE may
remove the previous content of the resource any time after it was deallocated.
Deallocation of a resource may mean that all subjects sharing it have deallocated it.
Allocation of a resource to an object may not have meaning until at least one subject
accesses the object or brings the object into its address space.
58
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.3 Identification and authentication (FIA)
5.1.3.1 Authentication failure handling (FIA_AFL.1-NIAP-0425)
FIA_AFL.1.1-NIAP-0425 The TSF shall detect when an authorized administrator
configurable integer of unsuccessful authentication attempts occur related to user logins.
Application Note: The default for the number of unsuccessful authentication attempts is 5
(five).
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been
met or surpassed, the TSF shall lock the terminal by ignoring the SAK.
Application Note: Additional login attempts are ignored until an administrator unlocks
the terminal.
5.1.3.2 User attribute definition (FIA_ATD.1)
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging
to individual users:
a) The real user and group identifiers;
b) The clearance of the user (which implicitly specifies which roles the
user can operate in);
c) The default Mandatory Access Control (MAC) level;
d) The default Mandatory Integrity Control (MIC) level;
e) Capabilities;
f) The default group;
g) Group membership;
h) Authentication data.
Application Note: Group membership may be expressed in a number of ways: a list per
user specifying to which groups the user belongs, a list per group which includes which
users are members, or implicit association between certain user identities and certain
groups.
Application Note: A TOE may have two forms of user and group identities, a text form
and a numeric form, which have a unique mapping between the representations.
5.1.3.3 Verification of secrets (FIA_SOS.1)
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet:
a) For each attempt to use the authentication mechanism, the probability
that a random attempt will succeed is less than one in 300,000,000;
b) For multiple attempts to use the authentication mechanism during a
one minute period, the probability that a random attempt during that
minute will succeed is less than one in 100,000; and
59
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
c) Any feedback given during an attempt to use the authentication
mechanism will not reduce the probability below the above metrics.
Application Note: The TOE uses passwords as the secrets. Users are authenticated at
login time based on the user name and password they type in at a terminal.
5.1.3.4 User authentication before any action (FIA_UAU.2)
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
5.1.3.5 Single-use authentication mechanisms (FIA_UAU.4)
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to first time
boot of a new system, and initial login by a new user.
5.1.3.6 Re-authenticating (FIA_UAU.6)
FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions user attempts
to change his own password.
5.1.3.7 Protected authentication feedback (FIA_UAU.7)
FIA_UAU.7.1 The TSF shall provide only obscured feedback and notice of
authentication failure to the user while the authentication is in progress.
Application Note: “Obscured feedback” implies the TSF does not produce a visible
display of any authentication data entered by a user (such as the echoing of a password),
although an obscured indication of progress may be provided (such as an asterisk for
each character). It also implies that the TSF does not return any information during the
authentication process to the user, which may provide any indication of the
authentication data.
5.1.3.8 User identification before any action (FIA_UID.2)
FIA_UID.2.2 The TSF shall require each user to identify itself before allowing any other
TSF-mediated actions on behalf of that user.
5.1.3.9 User-subject binding (FIA_USB.1-NIAP-0415)
FIA_USB.1.1-NIAP-0415: The TSF shall associate the appropriate following user
security attributes with subjects acting on behalf of that user:
a. The user identity which is associated with auditable events;
b. The user identity or identities which are used to enforce the
Discretionary Access Control Policy;
c. The group membership or memberships used to enforce the
Discretionary Access Control Policy;
60
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
d. The sensitivity label used to enforce the Mandatory Access
Control Policy, which consists of the following:
i. A hierarchical level; and
ii. A set of non-hierarchical categories.
e. The integrity label used to enforce the Mandatory Integrity
Control Policy, which consists of the following:
i. A hierarchical level; and
ii. A set of non-hierarchical categories.
f. MAC and MIC clearance;
g. Capabilities.
FIA_USB.1.2 Refinement: The TSF shall enforce the following rules on the initial
association of user security attributes with subjects acting on the behalf of a user:
a) The sensitivity label associated with a subject shall be within the
clearance range of the user;
b) The integrity label associated with a subject shall be within the
clearance range of the user;
c) The group associated with the subject shall be one for which the user
is currently a member;
d) The user identities which are associated with auditable events and
which are used to enforce the Discretionary Access Control Policy
shall be the same and shall be that of the user which logged in.
FIA_USB.1.3 Refinement: The TSF shall enforce the following rules governing
changes to the user security attributes associated with subjects acting on the behalf
of a user:
a) Subjects can not change their MAC and MIC levels, but can start
other subjects at an upgraded MAC/MIC level (within the user’s
clearance);
b) Only privileged subjects can change the user ID associated with
auditing to a value other than a set-ID program has used in the
subject’s history (and all ID changes are auditable);
c) The user and group IDs used for DAC policy checks can only be
changed by (and after) starting a program which an administrator
has specified as a “set ID” program;
d) Only administrators can change the clearance, capabilities, and group
membership of a user;
e) Users can change their default level (within their clearance) and their
default group (with their group membership).
61
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.4 Security management (FMT)
5.1.4.1 Management of Security Functions Behavior (FMT_MOF.1(1))
FMT_MOF.1.1(1) The TSF shall restrict the ability to determine the behavior of the
functions access change requests for devices to the authorized administrators.
5.1.4.2 Management of Security Functions Behavior (FMT_MOF.1(2))
FMT_MOF.1.1(2) The TSF shall restrict the ability to modify the behavior of the
function frequency of audit space threshold warnings (see FAU_STG.4.1) to the
authorized administrators.
5.1.4.3 Management of Security Functions Behavior (FMT_MOF.1(3))
FMT_MOF.1.1(3) The TSF shall restrict the ability to enable the functions printing
hard-copy (see FDP_ETC.2.4) to the authorized operators and administrators.
5.1.4.4 Management of Security Functions Behavior (FMT_MOF.1(4))
FMT_MOF.1.1(4) The TSF shall restrict the ability to disable or enable the functions set
the “class” of a disk partition (see FDP_ITC.1.3) to the authorized operators and
administrators.
5.1.4.5 Management of Security Functions Behavior (FMT_MOF.1(5))
FMT_MOF.1.1(5) The TSF shall restrict the ability to enable the functions restore from
save tape (see FDP_ITC.2.5-NIAP-0407) to the authorized operators and
administrators.
5.1.4.6 Management of Security Functions Behavior (FMT_MOF.1(6))
FMT_MOF.1.1(6) The TSF shall restrict the ability to modify the behavior of the
functions authentication failure handling (see FIA_AFL.1.1-NIAP-0425 and 1.2) to
the authorized administrators.
5.1.4.7 Management of Security Functions Behavior (FMT_MOF.1(7))
FMT_MOF.1.1(7) The TSF shall restrict the ability to determine the behavior of and
modify the behavior of the functions verification of secrets (see FIA_SOS.1.1) to the
authorized administrators.
5.1.4.8 Management of Security Functions Behavior (FMT_MOF.1(8))
FMT_MOF.1.1(8) The TSF shall restrict the ability to disable and enable the functions
mounting and unmounting of file systems (see FDP_ITC.2.5-NIAP-0407)to the
authorized administrators and operators.
62
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.4.9 Management of Security Functions Behavior (FMT_MOF.1(9))
FMT_MOF.1.1(9) The TSF shall restrict the ability to determine the behavior of the
functions serial terminal support to the authorized administrators.
5.1.4.10 Management of Security Functions Behavior (FMT_MOF.1(10))
FMT_MOF.1.1(10) The TSF shall restrict the ability to determine the behavior of the
functions management of conditions under which abstract machine tests occur, such
as during initial start-up, regular intervals, or under specific constraints (see
FPT_AMT.1.1) to the authorized administrators.
5.1.4.11 Management of security attributes (for Mandatory Integrity Control)
(FMT_MSA.1(1))
FMT_MSA.1.1(1) The TSF shall enforce the Mandatory Integrity Control policy to
restrict the ability to modify, delete, and add the security attributes set of users with
read access rights to the audit records (i.e., users whose clearance includes both
maximum security and maximum integrity) (see FAU_SAR.1.1) to authorized
administrators.
5.1.4.12 Management of Security Attributes (for Discretionary Access Control)
(FMT_MSA.1(2))
FMT_MSA.1.1(2) The TSF shall enforce the Discretionary Access Control policy to
restrict the ability to modify the security attributes group membership of users to
authorized administrators.
5.1.4.13 Management of security attributes (for Discretionary Access Control)
(FMT_MSA.1(3))
FMT_MSA.1.1(3) Refinement: The TSF shall enforce the Discretionary Access
Control policy to restrict the ability to modify the access control attributes associated
with a named object (see FDP_ACF.1.1-NIAP-0407) to authorized administrators
and owners of the object.
5.1.4.14 Management of Security Attributes (for Mandatory Access Control)
(FMT_MSA.1(4))
FMT_MSA.1.1(4) The TSF shall enforce the Mandatory Access Control policy to
restrict the ability to modify the security attributes value of the sensitivity label
associated with an object (see FDP_IFF.2.1-NIAP-0417(1)) to authorized
administrators or owners with the required capability.
63
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.4.15 Management of Security Attributes (for Mandatory Integrity Control)
(FMT_MSA.1(5))
FMT_MSA.1.1(5) The TSF shall enforce the Mandatory Integrity Control policy to
restrict the ability to modify the security attributes value of the integrity label
associated with an object (see FDP_IFF.2.1-NIAP-0417(2)) to authorized
administrators or owners with the required capability.
5.1.4.16 Management of security attributes (FMT_MSA.1(6))
FMT_MSA.1.1(6) The TSF shall enforce the Discretionary Access Control policy to
restrict the ability to modify the security attributes default group for a user to
authorized administrators.
5.1.4.17 Management of security attributes (FMT_MSA.1(7))
FMT_MSA.1.1(7) The TSF shall enforce the Mandatory Access Control policy to
restrict the ability to modify the security attributes default values for a user’s MAC
level to authorized administrators or that user.
5.1.4.18 Management of security attributes (for Default Values for Access Control
Policies) (FMT_MSA.1(8))
FMT_MSA.1.1(8) The TSF shall enforce the Mandatory Integrity Control policy to
restrict the ability to change default and modify the security attributes default values for
a user’s MIC level (see FMT_MSA.3.1-NIAP-0409) to authorized administrators or
that user.
5.1.4.19 Management of security attributes (FMT_MSA.1(9))
FMT_MSA.1.1(9) The TSF shall enforce the Mandatory Integrity Control policy to
restrict the ability to change default the security attributes allowable MIC range of a
new file system to authorized administrators and operators.
5.1.4.20 Management of security attributes (FMT_MSA.1(10))
FMT_MSA.1.1(10) The TSF shall enforce the Mandatory Access Control policy to
restrict the ability to change default the security attributes) allowable MAC range of a
new file system to authorized administrators and operators.
5.1.4.21 Management of security attributes (for Roles) (FMT_MSA.1(11))
FMT_MSA.1.1(11) The TSF shall enforce the Mandatory Integrity Control policy to
restrict the ability to delete and add the security attributes users who are a member of a
role (see FMT_SMR.1.1) to authorized administrators.
64
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.4.22 Management of security attributes (for Time) (FMT_MSA.1(12))
FMT_MSA.1.1(12) The TSF shall enforce the Mandatory Integrity Control policy to
restrict the ability to change default and modify the security attributes time kept by the
TOE (see FPT_STM.1.1) to authorized administrators.
5.1.4.23 Management of security attributes (for TSF-initiated Session Termination)
(FMT_MSA.1(13))
FMT_MSA.1.1(13) The TSF shall enforce the Mandatory Integrity Control policy to
restrict the ability to change default and modify the security attributes maximum time of
user inactivity prior to automatic termination of the session (see FTA_SSL.3.1) to
authorized administrators.
5.1.4.24 Secure Security Attributes (FMT_MSA.2)
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security
attributes.
Application Note: “Secure values” are those defined in the associated guidance
documentation. The identity attributes are listed in FDP_IFC.2, and FIA_ATD.1.
5.1.4.25 Static Attributes Initialization (FMT_MSA.3-NIAP-0409(1))
FMT_MSA.3.1-NIAP-0409(1) Refinement: The TSF shall enforce the Discretionary
Access Control policy to provide restrictive default values for security attributes that are
used to enforce the Discretionary Access Control policy.
FMT_MSA.3.2(1) The TSF shall allow the authorized administrator to specify
alternative initial values to override the default values when an object or information is
created.
5.1.4.26 Static Attributes Initialization (FMT_MSA.3-NIAP-0409(2))
FMT_MSA.3.1-NIAP-0409(2) Refinement: The TSF shall enforce the Mandatory
Access Control policy to provide restrictive default values for security attributes that are
used to enforce the Mandatory Access Control policy.
FMT_MSA.3.2(2) The TSF shall allow the authorized administrator to specify
alternative initial values to override the default values when an object or information is
created.
Application Note: The TOE must provide protection by default for all objects at creation
time. This may be accomplished through the enforcement of a restrictive default access
on objects, or through requiring the user to explicitly specify the desired access controls
upon the object at its creation, provided that there is no window of vulnerability through
which unauthorized access may be gained to newly-created objects.
65
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.4.27 Management of TSF data (for general TSF data) (FMT_MTD.1(1))
FMT_MTD.1.1(1) The TSF shall restrict the ability to change_default, query, modify,
delete, clear, and create the security-relevant TSF data except for audit records, user
security attributes, authentication data, and security parameters to the authorized
administrator.
Application Note: The restrictions for audit records, user security attributes,
authentication data, and critical security parameters are specified below.
5.1.4.28 Management of TSF Data (for audit data) (FMT_MTD.1(2))
FMT_MTD.1.1(2) The TSF shall restrict the ability to query the audit records to
authorized administrators.
5.1.4.29 Management of TSF Data (for audit parameters) (FMT_MTD.1(3))
FMT_MTD.1.1(3) The TSF shall restrict the ability to modify or observe the set of
audited events to authorized administrators.
5.1.4.30 Management of TSF Data (for user security attributes) (FMT_MTD.1(4))
FMT_MTD.1.1(4) The TSF shall restrict the ability to create, delete, and clear the audit
trailto authorized administrators.
5.1.4.31 Management of TSF Data (for user security attributes, other than
authentication data) (FMT_MTD.1(5))
FMT_MTD.1.1(5) The TSF shall restrict the ability to modify and initialize the user
security attributes, other than authentication data, to authorized administrators.
Application Note: Users can modify their own authentication data.
5.1.4.32 Management of TSF Data (for authentication data) (FMT_MTD.1(6))
FMT_MTD.1.1(6) The TSF shall restrict the ability to modify the authentication data to
authorized administrators and users authorized to modify their own authentication
data.
5.1.4.33 Management of TSF Data (for authentication data) (FMT_MTD.1(7))
FMT_MTD.1.1(7) The TSF shall restrict the ability to initialize the authentication data
to authorized administrators.
66
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.4.34 Management of TSF Data (for critical security parameters)
(FMT_MTD.1(8))
FMT_MTD.1.1(8) The TSF shall restrict the ability to create and delete the users and
groups to authorized administrators.
5.1.4.35 Management of limits on TSF data (FMT_MTD.2)
FMT_MTD.2.1 The TSF shall restrict the specification of the limits for critical security
parameters to the authorized administrator or operators.
FMT_MTD.2.2 The TSF shall take the following actions, if the TSF data are at, or
exceed, the indicated limits: shut down the system.
Application Note: An example of this would be the amount of audit records exceeding a
specified percentage of available hard disk space.
5.1.4.36 Revocation (to authorized administrators) (FMT_REV.1(1))
FMT_REV.1.1(1) The TSF shall restrict the ability to revoke security attributes
associated with the users within the TSC to authorized administrators.
Application Note: The term “revoke security attributes” means “change attributes so
that access is revoked”.
FMT_REV.1.2(1) The TSF shall enforce the rules:
a) The revocation of security-relevant authorizations shall be enforced at
the next login attempt, trusted command use, or subject creation.
Application Note: Security-relevant authorizations include the ability of authorized users
to log in or perform privileged operations. An example of revoking a security-relevant
authorization is the deletion of a user account upon which system access is immediately
terminated).
5.1.4.37 Revocation (to owners and authorized administrators) (FMT_REV.1(2))
FMT_REV.1.1(2) The TSF shall restrict the ability to revoke security attributes
associated with objects within the TSC to owners and authorized administrators.
Application Note: The term “revoke security attributes” means “change attributes so
that access is revoked”.
FMT_REV.1.2(2) The TSF shall enforce the rules:
a) A change in MAC or MIC level of an object will be enforced the next
time any subject attempts an access to the object;
b) A change in DAC attributes of an object will be enforced the next time
any subject attempts to “open” the object. Subjects which already
have the object open will be allowed to continue accessing the object.
67
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
c) An owner of an object will only be allowed to change the MAC or
MIC level of an object if s/he possesses the appropriate user
capability.
Application Note: The state where access checks are made determines when the access
control policy enforces revocation. The access control policy may include immediate or
delayed revocation. The access rights are considered to be revoked when all subsequent
access control decisions made by the TSF use the new access control information. In
cases where a previous access control decision was made to permit an operation, it is not
required that every subsequent operation make an explicit access control decision.
5.1.4.38 Time-Limited Authorization (FMT_SAE.1)
FMT_SAE.1.1 The TSF shall restrict the capability to specify an expiration time for
passwords to the authorized administrator.
FMT_SAE.1.2 For each of these security attributes, the TSF shall be able to lock out the
associated authorized user account after the expiration time for the indicated security
attribute has passed.
5.1.4.39 Specification of Management Functions (FMT_SMF.1-CCIMB-65)
FMT_SMF.1.1 The TSF shall be capable of performing the following security
management functions:
1)
2)
3)
4)
5)
mounting and unmounting of file systems;
configure serial lines as login terminals;
view and change the threshold for audit space warnings;
view and change the password criteria;
set or change the password of another user and force another user to change
his or her own password;
6) create new users and groups;
7) view the set of users and groups;
8) add and remove users from groups;
9) view, initialize or change the MAC and MIC clearance of a user;
10) view, initialize or change the MAC and MIC ranges of a device;
11) view, set or change the capabilities of a user;
12) view and change the maximum inactivity time on a terminal before logout of
the user’s session;
13) display and change the MAC, MIC, and DAC attributes of file system objects
owned by other users;
14) save and restore multi-level data to tape;
15) set the class of disk devices;
16) view or modify the auditing parameters (enabled events, users, levels);
17) set the system time;
18) search the audit trail for specific kinds of records;
68
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
19) remove audit files;
20) startup the hardcopy printing subsystem;
21) initialize, view, and change the default group, MAC level, and MIC level of
any user;
22) create new file systems and specify their MAC and MIC range;
23) display and change the number of allowed authentication failures before a
terminal lockout;
24) display and change the length of time of a terminal lockout;
25) configure daemons to automatically run abstract machine self-tests.
5.1.4.40 Security Roles (FMT_SMR.1)
FMT_SMR.1.1 The TSF shall maintain the roles:
a. authorized administrator;
b. users authorized by the Mandatory Access Control Policy to modify
object security attributes;
c. users authorized to modify their own authentication data
d. operator;
e. user (with no additional authorizations).
Application Note: Any user that is authorized to bypass the MAC, MIC, or DAC policy is,
by definition, a trusted user. Operators, as well as administrators, are trusted users, but
operators do not have as many authorizations as administrators and their ability to
bypass policy is limited by settings controlled by administrators. Otherwise untrusted
users may be granted a “capability” by an administrator to modify the MAC and MIC
levels of objects s/he owns (within his or her clearance) or may be granted a capability to
change their own authentication data. There is no capability to allow a user to modify the
DAC attributes of objects which s/he does not own and that function is limited to
administrators. The TOE may provide multiple administrator roles (audit administrator,
security administrator, etc).
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
5.1.4.41 Assuming Roles (FMT_SMR.3)
FMT_SMR.3.1 The TSF shall require an explicit request to assume the following roles:
a) authorized administrator;
b) Operator;
c) User.
69
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.1.5 Protection of the TOE Security Functions (FPT)
5.1.5.1 Abstract Machine Testing (FPT_AMT.1)
FPT_AMT.1.1 Refinement: The TSF shall run a suite of tests at the request of an
authorized administrator or operator to demonstrate the correct operation of the
security assumptions provided by the abstract machine that underlies the TSF.
Application Note: The TSF may include hardware. In the case that there is no underlying
abstract machine upon which the TSF relies to implement required functions, this
requirement is met “vacuously” and testing of hardware may fall under FPT_TST.1.
Application Note: The test suite need only cover aspects of the underlying abstract
machine on which the TSF relies to implement required functions, including domain
separation.
5.1.5.2 Recovery from Failure (FPT_RCV.2-NIAP-406)
FPT_RCV.2.1-NIAP-0406 For no failures/service discontinuities, the TSF shall ensure
the return of the TOE to a secure state using automated procedures.
FPT_RCV.2.2-NIAP-0406 When automated recovery from a failure or service
discontinuity is not possible, the TSF shall enter a maintenance mode where the ability to
return the TOE to a secure state is provided.
5.1.5.3 Non-Bypassability of the TSF (FPT_RVM.1)
FPT_RVM.1.1 The TSF shall ensure that TSP enforcement functions are invoked and
succeed before each function within the TSC is allowed to proceed.
5.1.5.4 SFP Domain Separation (FPT_SEP.1)
FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution that
protects it from interference and tampering by untrusted subjects.
FPT_SEP.1.2 The TSF shall enforce separation between the security domains of subjects
in the TSC.
5.1.5.5 Reliable time stamps (FPT_STM.1)
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use.
5.1.5.6 TSF Testing (for TSF) (FPT_TST.1)
FPT_TST.1.1 The TSF shall run a suite of self tests during the initial start-up or at the
request of an authorized administrator or operator to demonstrate the correct
operation of the TSF.
70
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
FPT_TST.1.2 Refinement: The TSF shall provide authorized administrators and
operators with the capability to verify the integrity of TSF data.
FPT_TST.1.3 Refinement: The TSF shall provide authorized administrators and
operators with the capability to verify the integrity of stored TSF executable code.
5.1.6 TOE Access (FTA)
5.1.6.1 TSF-Initiated Termination (FTA_SSL.3)
FTA_SSL.3.1 The TSF shall terminate an interactive session after an administrator
configurable time interval of inactivity.
5.1.6.2 Default TOE Access Banners (FTA_TAB.1)
FTA_TAB.1.1 Refinement: Before establishing a user session, the TSF shall display an
advisory notice and consent warning message regarding unauthorized use of the TOE.
5.1.6.3 TOE Access History (FTA_TAH.1)
FTA_TAH.1.1 Refinement: Upon successful session establishment, the TSF shall
display the date, time, and location of the last successful session establishment to the
session user.
FTA_TAH.1.2 Upon successful session establishment, the TSF shall display the date, and
time of the last unsuccessful attempt to session establishment and the number of
unsuccessful attempts since the last successful session establishment.
FTA_TAH.1.3 The TSF shall not erase the access history information from the user
interface without giving the user an opportunity to review the information.
5.1.7 Trusted path/channels (FTP)
5.1.7.1 Trusted path (FTP_TRP.1)
FTP_TRP.1.1 The TSF shall provide a communication path between itself and local users
that is logically distinct from other communication paths and provides assured
identification of its end points and protection of the communicated data from
modification or disclosure.
Application Note: This “distinct” path is merely invoked for the duration of its being
needed (e.g., for reauthenticating the user); it need not be invoked for the duration of the
user’s session.
FTP_TRP.1.2 The TSF shall permit local users to initiate communication via the trusted
path.
71
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
FTP_TRP.1.3 The TSF shall require the use of the trusted path for initial user
authentication and user identification, changing of roles, changing of current group,
changing of password, changing of session level.
72
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.2 End Notes
This section records the functional requirements where deletion of Common Criteria text
was performed.
1. FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for
the user to interpret the information.
A deletion of CC text was performed in FAU_SAR.1.2. Rationale: The word
"user" was deleted to replace it with the defined role of "authorized
administrator". This is necessary because only the administrator should be
allowed to handle audit records.
FAU_SAR.1.2 Refinement: The TSF shall provide the audit records in a manner
suitable for the authorized administrator to interpret the information using a
tool to access the audit trail.
2. FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed:
[assignment]
A refinement of CC text was performed in FDP_ACF.1.2. Rationale: The only
type of objects that can have security attributes such as MAC levels assigned to
them are named objects. Unnamed objects may be created by processes and have
MAC level equivalent to that of the process (subject).
FDP_ACF.1.2 Refinement: The TSF shall enforce the following rules to
determine if an operation among subjects and controlled named objects is
allowed: [assignment]
3. FDP_ACF.1.3-NIAP-0407 The TSF shall explicitly authorize access of subjects
to objects based on the following additional rules: [assignment]
A refinement of CC text was performed in FDP_ACF.1.3-NIAP-0407. Rationale:
The only type of objects that can have security attributes such as MAC levels
assigned to them are named objects. Unnamed objects may be created by
processes and have MAC level equivalent to that of the process (subject).
FDP_ACF.1.3-NIAP-0407 Refinement: The TSF shall explicitly authorize access
of subjects to named objects based on the following additional rules:
[assignment]
4. FDP_ETC.1.2 The TSF shall export the user data without the user data’s
associated security attributes.
A refinement of CC text was performed in FDP_ETF.1.2. Rationale: The LSPP
writes the requirement this way to make it clear that data being exported without
security attributes has no label and to allow the explicit rules to be specified, as is
73
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
done for FDP_ETC.2 and FDP_ITC.1.
FDP_ETC.1.2 Refinement: The TSF shall export the unlabeled user data without
the user data’s associated security attributes and shall enforce the following
rules when unlabeled user data is exported from the TSC:
a) Devices used export data without security attributes cannot be used to
export data with security attributes unless the change in device state is
performed manually and is auditable;
b) The devices used for export do have MAC, MIC, and DAC attributes
and these are implicitly the attributes of the exported information;
c) Normal MAC, MIC, and DAC policy rules govern access from
subjects to any export device and such access will be auditable;
d) Only an operator or administrator can modify the MAC or MIC
attributes of a device and only the owner of a device can modify the
device’s DAC attributes;
e) All changes to device security attributes are auditable;
f) Devices which are in use by the TSF can not simultaneously be used
for export of unlabeled user data.
5. FDP_ETC.2.1 The TSF shall enforce the [assignment] when exporting user data,
controlled under the SFP(s), outside of the TSC.
A refinement of CC text was performed in FDP_ETF.2.1. Rationale: The LSPP
writes the requirement this way to make it clear that data being exported with
security attributes has a label.
FDP_ETC.2.1 Refinement: The TSF shall enforce the [assignment] when
exporting labeled user data, controlled under the SFP(s), outside of the TSC.
6.
FDP_ETC.2.2 The TSF shall export the user data with the user data’s associated
security attributes.
A refinement of CC text was performed in FDP_ETF.2.2. Rationale: The LSPP
writes the requirement this way to make it clear that data being exported with
security attributes has a label.
FDP_ETC.2. Refinement: The TSF shall export the labeled user data with the
user data’s associated security attributes.
7. FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exported
outside of the TSC, are unambiguously associated with the exported user data.
A refinement of CC text was performed in FDP_ETF.2.3. Rationale: The LSPP
74
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
writes the requirement this way to make it clear that data being exported with
security attributes has a label.
FDP_ETC.2.3 Refinement: The TSF shall ensure that the security attributes,
when exported outside of the TSC, are unambiguously associated with the
exported labeled user data.
8. FDP_ETC.2.4 The TSF shall enforce the following rules when user data is
exported from the TSC: [assignment].
A refinement of CC text was performed in FDP_ETF.2.4. Rationale: The LSPP
writes the requirement this way to make it clear that data being exported without
security attributes has no label and to allow the explicit rules to be specified, as is
done for FDP_ETC.2 and FDP_ITC.1.
FDP_ETC.2.4 Refinement: The TSF shall enforce the following rules when
labeled user data is exported from the TSC: [assignment].
9. FDP_IFC.2.1(1) The TSF shall enforce the [assignment] on [assignment], and all
operations that cause that information to flow to and from subjects covered by the
SFP.
A refinement of CC text was performed in FDP_IFC.2.1(1). Rationale: The LSPP
changes the wording to make it more clear.
FDP_IFC.2.1(1) Refinement: The TSF shall enforce the [assignment] on
[assignment], and all operations that cause that information to flow to and from
subjects covered by the MAC policy.
10. FDP_IFF.2.2(1) The TSF shall permit an information flow between a controlled
subject and controlled information via a controlled operation if the following
rules, based on the ordering relationships between security attributes hold:
[assignment]
A refinement of CC text was performed in FDP_IFF.2.2(1). Rationale: The words
“between a controlled subject and controlled information via a controlled
operation if” and “based on the ordering relationships between security attributes
hold” was deleted because the information flow for this requirement is among
subjects and objects.
FDP_IFF.2.2(1) Refinement: The TSF shall permit an information flow among
subjects and objects based on the following rules: [assignment]
11. FDP_IFF.2.5(1) The TSF shall explicitly authorize an information flow based on
the following rules: [assignment]
75
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
A refinement of CC text was performed in FDP_IFF.2.5(1). Rationale: Text was
refined to tailor it to the TOE. The modified text is a more specific requirement.
FDP_IFF.2.5(1) Refinement: Authorized users may bypass MAC by setting their
integrity level to “admin” and executing certain TSF commands. Some commands
may also require a user to posses a capability added to their account by the system
administrator.
12. FDP_IFF.2.7(1) The TSF shall enforce the following relationships for any two
valid information flow control security attributes:
a) There exists an ordering function that, given two valid security attributes,
determines if the security attributes are equal, if one security attribute is
greater than the other, or if the security attributes are incomparable; and
b) There exists a “least upper bound” in the set of security attributes, such
that, given any two valid security attributes, there is a valid security
attribute that is greater than or equal to the two valid security attributes;
and
c) There exists a “greatest lower bound” in the set of security attributes, such
that, given any two valid security attributes, there is a valid security
attribute that is not greater than the two valid security attributes.
A refinement of CC text was performed in FDP_IFF.2.7(1). Rationale: For
clarification, “security attribute” was replaced with “sensitivity label”. Also the
specific ordering rules for this TOE are given, as dictated by the LSPP.
FDP_IFF.2.7(1) Refinement: The TSF shall enforce the following relationships
for any two valid sensitivity labels:
a) There exists an ordering function that, given two valid security attributes,
determines if the security attributes are equal, if one security attribute is
greater than the other, or if the security attributes are incomparable; and
1) Sensitivity labels are equal if the hierarchical level of both labels
are equal and the non-hierarchical category sets are equal;
2) Sensitivity label A is greater than sensitivity label B if one of the
following conditions exist:
i. If the hierarchical level of A is greater than the hierarchical
level of B, and the non-hierarchical category set of A is equal to
the non-hierarchical category set of B.
ii. If the hierarchical level of A is equal to the hierarchical level of
B, and the non-hierarchical category set of A is a proper superset of the nonhierarchical category set of B.
iii. If the hierarchical level of A is greater than the hierarchical
level of B, and the non-hierarchical category set of A is a
proper super-set of the non-hierarchical category set of B.
76
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
3) Sensitivity labels are incomparable if they are not equal and
neither label is greater than the other.
b) There exists a “least upper bound” in the set of sensitivity labels, such
that, given any two valid sensitivity labels, there is a valid sensitivity
label that is greater than or equal to the two valid sensitivity labels; and
c) There exists a “greatest lower bound” in the set of sensitivity labels, such
that, given any two valid sensitivity labels, there is a valid sensitivity
label that is not greater than the two valid sensitivity labels.
13. FDP_IFF.2.2(2) The TSF shall permit an information flow between a controlled
subject and controlled information via a controlled operation if the following
rules, based on the ordering relationships between security attributes hold:
[assignment]
A refinement of CC text was performed in FDP_IFF.2.2(2). Rationale: The words
“between a controlled subject and controlled information via a controlled
operation if” and “based on the ordering relationships between security attributes
hold” was deleted because the information flow for this requirement is among
subjects and objects.
FDP_IFF.2.2(2) Refinement: The TSF shall permit an information flow among
subjects and objects based on the following rules:
14. FDP_IFF.2.5(2) The TSF shall explicitly authorize an information flow based on
the following rules: [assignment]
A refinement of CC text was performed in FDP_IFF.2.5(2). Rationale: Text was
refined to tailor it to the TOE. The modified text is a more specific requirement.
FDP_IFF.2.5(2) Refinement: Authorized users may bypass MIC by setting their
integrity level to “admin” and executing certain TSF commands. Some commands
may also require a user to posses a capability added to their account by the system
administrator.
15. FDP_IFF.2.7(2) The TSF shall enforce the following relationships for any two
valid information flow control security attributes:
a) There exists an ordering function that, given two valid security attributes,
determines if the security attributes are equal, if one security attribute is
greater than the other, or if the security attributes are incomparable; and
b) There exists a “least upper bound” in the set of security attributes, such
that, given any two valid security attributes, there is a valid security
attribute that is greater than or equal to the two valid security attributes;
and
c) There exists a “greatest lower bound” in the set of security attributes, such
that, given any two valid security attributes, there is a valid security
attribute that is not greater than the two valid security attributes.
77
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
A refinement of CC text was performed in FDP_IFF.2.7(2). Rationale:
Requirement is tailored for the TOE.
FDP_IFF.2.7(2) Refinement: The TSF shall enforce the following relationships
for any two valid MIC security attributes:
a) There exists an ordering function that, given two valid security attributes,
determines if the security attributes are equal, if one security attribute is
greater than the other, or if the security attributes are incomparable; and
b) There exists a “least upper bound” in the set of security attributes, such
that, given any two valid security attributes, there is a valid security
attribute that is greater than or equal to the two valid security attributes;
and
c) There exists a “greatest lower bound” in the set of security attributes, such
that, given any two valid security attributes, there is a valid security
attribute that is not greater than the two valid security attributes.
16. FDP_ITC.1 was refined to replace “user data” with “unlabeled user data” in each
place those words were used.
Rationale: The LSPP uses this refinement to clarify that the data being imported
had no label.
17. FDP_ITC.2.1 The TSF shall enforce the [assignment] when importing user data,
controlled under the SFP, from outside the TSC.
A refinement of CC text was performed in FDP_ITC.2.1. Rationale: The LSPP
uses this refinement to clarify that the data being imported has a label.
FDP_ITC.2.1 Refinement: The TSF shall enforce the [assignment] when
importing labeled user data, controlled under the SFP, from outside the TSC.
18. FDP_ITC.2.2 Refinement: The TSF shall use the security attributes associated
with the imported user data.
A refinement of CC text was performed in FDP_ITC.2.2. Rationale: The LSPP
uses this refinement to clarify that the data being imported has a label.
FDP_ITC.2.2 Refinement: The TSF shall use the security attributes associated
with the imported labeled user data.
19. FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the
unambiguous association between the security attributes and the user data
received.
78
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
A refinement of CC text was performed in FDP_ITC.2.3. Rationale: This
refinement refers to the importation of data from devices such as a mounted
floppy drive. The revised wording adds clarity. Also, the LSPP uses this
refinement to clarify that the data being imported has a label.
FDP_ITC.2.3 Refinement: The TSF shall ensure that the protocol used provides
for the correct unambiguous association between the imported security attributes
and the imported user data.
20. FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes of
the imported user data is as intended by the source of the user data.
A refinement of CC text was performed in FDP_ITC.2.4. Rationale: The LSPP
uses this refinement to clarify that the data being imported has a label.
FDP_ITC.2.4 Refinement: The TSF shall ensure that interpretation of the
security attributes of the imported user data is as intended by the source of the
labeled user data.
21. FDP_ITC.2.5-NIAP-0407 The TSF shall enforce the following rules when
importing user data controlled under the SFP from outside the TSC: [selection].
A refinement of CC text was performed in FDP_ITC.2.5-NIAP-0407. Rationale:
The LSPP uses this refinement to clarify that the data being imported has a label.
FDP_ITC.2.5-NIAP-0407 Refinement: The TSF shall enforce the following rules
when importing labeled user data controlled under the SFP from outside the TSC:
[selection].
22. FIA_USB.1-NIAP-0415 was refined to include additional elements
(FIA_USB.1.2 and FIA_USB.1.3). Rationale: The LSPP uses this refinement to
clarify the rules for changing the attributes bound to subjects.
23. FMT_MSA.1.1 The TSF shall enforce the [assignment] to restrict the ability to
[selection] the security attributes [assignment] to [assignment].
FMT_MSA.1.1(3) was refined. Rationale: Change wording per LSPP to make the
statement more readable.
FMT_MSA.1.1(3) Refinement: The TSF shall enforce the [assignment] to
restrict the ability to [selection] the access control attributes associated with a
named object (see FDP_ACF.1.1-NIAP-0407) to [assignment].
24. FMT_MSA.3.1-NIAP-0409 The TSF shall enforce the [assignment] to provide
[selection] default values for security attributes that are used to enforce the SFP.
79
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
This requirement was refined in both iterations. Rationale: Change wording per
LSPP to make the statement more readable.
FMT_MSA.3.1-NIAP-0409(1) Refinement: The TSF shall enforce the
[assignment] to provide [selection] default values for security attributes that are
used to enforce the Discretionary Access Control policy.
FMT_MSA.3.1-NIAP-0409(2) Refinement: The TSF shall enforce the
[assignment] to provide [selection] default values for security attributes that are
used to enforce the Mandatory Access Control policy.
25. FPT_AMT.1.1 The TSF shall run a suite of tests [selection] to demonstrate the
correct operation of the security assumptions provided by the abstract machine
that underlies the TSF.
A refinement of CC text was performed in FPT_AMT.1.1. Rationale:
Administrator implies user with special privileges.”
FPT_AMT.1.1 Refinement: The TSF shall run a suite of tests at the request of an
authorized administrator to demonstrate the correct operation of the security
assumptions provided by the abstract machine that underlies the TSF.
26. FPT_RCV.2.1-NIAP-0406 had the following selection made “no failures/service
discontinuities”.
27. FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify
the integrity of TSF data.
A refinement of CC text was performed in FPT_TST.1.2. Rationale:
Administrator implies user with special privileges.”
FPT_TST.1.2 Refinement: The TSF shall provide authorized administrators or
operators with the capability to verify the integrity of TSF data.
28. FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify
the integrity of stored TSF executable code.
A refinement of CC text was performed in FPT_TST.1.3. Rationale:
Administrator implies user with special privileges.”
FPT_TST.1.3 Refinement: The TSF shall provide authorized administrators or
operators with the capability to verify the integrity of stored TSF executable
code.
29. FTA_TAB.1.1 Before establishing a user session, the TSF shall display an
advisory warning message regarding unauthorized use of the TOE.
A refinement of CC text was performed in FTA_TAB.1.1. Rationale: Change is a
more specific requirement while meeting the original intent.
80
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
FTA_TAB.1.1 Refinement: Before establishing a user session, the TSF shall
display an advisory notice and consent warning message regarding unauthorized
use of the TOE.
30. FTA_TAH.1.1 Upon successful session establishment, the TSF shall display the
[selection] of the last successful session establishment to the user.
A refinement of CC text was performed in FTA_TAH.1.1. Rationale:
Administrator implies user with special privileges.”
FTA_TAH.1.1 Refinement: Upon successful session establishment, the TSF shall
display the date, time, and location of the last successful session establishment to
the session user.
81
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.3 TOE Security Assurance Requirements
All TOE security assurance requirements are drawn from the CC Part 3. The combination
of chosen assurance components result in an Evaluated Assurance Level 5, augmented
(EAL5+). As shown, ALC_FLR.3 and ATE_IND.3 go beyond the requirements for
EAL5. The assurance requirements for the EAL4+ product are also shown. The intended
TOE environment and the value of information processed by this environment establish
the need for the TOE to be evaluated at this EAL level. These security assurance
requirements are summarized in Table 5.2.
For the EAL4+ version of the product, some of the component levels evaluated are less
than those shown for EAL5. For example, ACM_SCP was only evaluated to component
level 2 for EAL4+. Also the EAL4+ product was not subjected to any evaluation of
ADV_INT nor AVA_CCA. In most of the document, the EAL5 component level is used,
but for the EAL4+ product the actual component level evaluated is found in the table
below. An exception to this is that the EAL4+ product did include ALC_FLR.3.
82
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Table 5-2 Assurance Requirements: EAL5 augmented
Assurance
Class
Assurance
Family
Configuration ACM_AUT
Management ACM_CAP
ACM_SCP
Delivery and ADO_DEL
Operation
ADO_IGS
Development ADV_FSP
ADV_HLD
ADV_IMP
ADV_INT†
ADV_LLD
ADV_RCR
ADV_SPM
Guidance
AGD_ADM
Documents
AGD_USR
Life Cycle
ALC_DVS
Support
ALC_FLR
ALC_LCD
ALC_TAT
Tests
ATE_COV
ATE_DPT
ATE_FUN
ATE_IND
Vulnerability AVA_CCA†
Assessment
AVA_MSU
AVA_SOF
AVA_VLA
Assurance Components by Evaluation Assurance Level
EAL1 EAL2
EAL3
EAL4
1
4
2
2
1
2
2
1
1
1
1
1
1
1
1
1
2
1
1
2
2
1
2
83
UNCLASSIFIED
EAL5
1
4
3
2
1
3
3
2
1
1
2
3
1
1
1
2
2
2
2
1
1
2
1
3
EAL6
EAL7
3
3†
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
5.4 Strength of TOE Security Functional Requirements
This ST includes AVA_SOF.1. This TOE is intended to meet a strength of SOF-high.
SOF applies to FIA_SOS.1. The strength of the “secrets” mechanism is consistent with
the objectives of authenticating users (O.User_Authentication), operators, and
administrators and with maintaining a separate administrator role (O.Admin_Role).
84
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
6 TOE Summary Specification
6.1 Measures Used to Meet IT Security Functions
The following functions implement the SFRs presented in Section 5.1.
Table 6-1 Security Functions and the SFRs They Implement
Security
Function
AUDGEN
AUDREV
DACENF
MACENF
MICENF
RIPENF
IDNAUT
SECMGT
SECFPR
TRUPTH
SFRs
FAU_GEN.1, FAU_GEN.2, FAU_STG.2-NIAP-0422, FAU_STG.3,
and FAU_STG.4 and contributes to FMT_MTD.2
FAU_SAR.1, FAU_SAR.2, and FAU_SAR.3
FDP_ACC.2 and FDP_ACF.1-NIAP-0407 and contributes to
FDP_ETC.1, FDP_ETC.2, FDP_ITC.1, FDP_ITC.2-NIAP-0407,
FIA_USB.1-NIAP-0415, and FMT_REV.1
FDP_IFC.2(1), FDP_IFF.2-NIAP-0417(1), FIA_USB.1-NIAP-0415
and contributes to the implementation of FAU_SAR.2, FDP_ETC.1,
FDP_ETC.2, FDP_ITC.1, FDP_ITC.2-NIAP-0407, and FMT_REV.1
FDP_IFC.2(2), FDP_IFF. 2-NIAP-0417 (2), and FIA_USB.1-NIAP0415, and contributes to the implementation of FAU_STG.2-NIAP0422, FDP_ETC.1, FDP_ETC.2, FDP_ITC.1, FDP_ITC.2-NIAP-0407,
and FMT_REV.1
FDP_RIP.2
FAU_SAA.1, FIA_AFL.1-NIAP-0425, FIA_ATD.1, FIA_SOS.1,
FIA_UAU.2, FIA_UAU.4, FIA_UAU.7, FIA_UID.2, FTA_SSL.3,
FTA_TAB.1, and FTA_TAH.1 and contributes to FMT_SAE.1 and
FIA_USB.1-NIAP-0415
FMT-MOF.1, FMT_MSA.1, FMT_MSA.2, FMT_MSA.3-NIAP-0409,
FMT_MTD.1, FMT_MTD.2, FMT_REV.1(1), FMT_REV.1(2),
FMT_SAE.1, FMT_SMF.1, FAU_SEL.1-NIAP-0407, FIA_USB.1NIAP-0415, FMT_SMR.1, FMT_SMR.3
FPT_AMT.1, FPT_RCV.2-NIAP-406, FPT_RVM.1, FPT_SEP.1,
FPT_STM.1, and FPT_TST.1
FPT_TRP.1
85
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Table 6-2 SFRs and the Security Functions that Satisfy Them
Class Name
Security Audit
Functional
Family SFR
(Component)
FAU_GEN.1
FAU_GEN.2
FAU_SAA.1
Security
Functions
AUDGEN
AUDGEN
IDNAUT
AUDREV
FAU_SAR.1
FAU_SAR.2
AUDREV,
MACENF
FAU_SAR.3
AUDREV
FAU_SEL.1NIAP-0407
SECMGT
MICENF,
AUDGEN
FAU_STG.2NIAP-0422
AUDGEN
FAU_STG.3
AUDGEN
FAU_STG.4
Rationale that Security Function is
Suitable to Meet SFR
Includes the mechanism for generating audit
records
Places the real user ID in each audit record
Monitors the number of failed login attempts and
takes action when a threshold is reached
Provides a trusted audit command that formats
audit records for human-readable display and
allows an administrator to view records in the
audit trail
AUDREV restricts audit record display to
administrators executing at maximum security.
MACENF prevents also prevents any user not
cleared to system maximum from reading the
audit trail in a raw fashion, as the audit files are
at maximum security.
Allows the administrator to search the audit trail
for specific kinds of records
Provides a trusted param_edit command which
allows pre-selection of auditing by event type,
user, and MAC/MIC level
MICENF is used to prevent the modification or
deletion of records in the audit trail by untrusted
users, as the audit files and the directory in
which they reside are at maximum integrity.
AUDGEN includes a mechanism by which
sufficient disk space is held in reserve such that
if additional permanent storage for audit records
runs out, all buffered records can be written to
permanent storage. In this case, the operator is
notified of the problem and the system is shut
down.
Includes monitoring of the number of audit files
and if an administratively set threshold is
exceeded, the operator and/or administrator is
notified via a console message.
Includes detection of runout of permanent
storage (disk) space for the audit trail. When this
is detected, the system is shut down to prevent
generation of too much additional audit data.
Disk space is held in reserve so that if this
happens, all buffered records can be written to
permanent storage.
86
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
User Data
Protection
Functional
Family SFR
(Component)
Security
Functions
DACENF
FDP_ACC.2
FDP_ACF.1NIAP-0407
FDP_ETC.1
DACENF
DACENF,
MACENF,
MICENF
DACENF,
MACENF,
MICENF
FDP_ETC.2
FDP_IFC.2
FDP_IFF.2NIAP-0417
FDP_ITC.1
MACENF,
MICENF
MACENF,
MICENF
DACENF,
MACENF,
MICENF
Rationale that Security Function is
Suitable to Meet SFR
All subjects have a user and group ID and all
objects have either an explicit or implicit set of
discretionary access attributes. DAC checks are
always performed, unless the subject created the
object or inherited the object from its parent.
Includes the specific attributes needed for DAC
and the specific rules used for DAC.
Data exported without security attributes will
implicitly have the attributes of the device (userclass disk, non-save tape, network) used to
export the data. The security functions will
ensure that the subject has the appropriate access
to the export device.
When data is exported with security attributes,
the security attributes are associated with the
data in different ways depending on the export
media. MIC and DAC attributes are not exported
to hard-copy output, but MAC attributes are
written on the banner page and the header and
footer of every other page. For save tapes, all
attributes are bound directly with each data
object and maintained transparently by the tape
media as part of the data. For disk file systems,
all attributes are kept in a branch which is found
via object ID and which in turn identifies the
disk blocks holding the object data.
MACENF defines the mandatory access control
policy. MICENF defines the mandatory integrity
control policy.
MACENF includes the specific attributes needed
for MAC and the specific rules used for MAC.
MICENF includes the specific attributes needed
for MIC and the specific rules used for MIC.
Data imported without security attributes will
implicitly have the attributes of the device (userclass disk, non-save tape, network) used to
import the data. The security functions will
ensure that the subject has the appropriate access
to the import device.
87
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Functional
Family SFR
(Component)
FDP_ITC.2NIAP-0407
Identification
and
Authentication
Security
Functions
DACENF,
MACENF,
MICENF
FDP_RIP.2
RIPENF
FIA_AFL.1NIAP-0425
IDNAUT
FIA_ATD.1
IDNAUT
IDNAUT
FIA_SOS.1
IDNAUT
FIA_UAU.2
IDNAUT
FIA_UAU.4
FIA_UAU.7
IDNAUT
IDNAUT
FIA_UID.2
FIA_USB.1NIAP-0415
DACENF,
IDNAUT,
MACENF,
MICENF,
SECMGT
Rationale that Security Function is
Suitable to Meet SFR
When data is imported with security attributes,
the security attributes are associated with the
data in different ways depending on the import
media. For save tapes, all attributes are extracted
directly from each data object. For disk file
systems, all attributes are obtained from the
branches associated with the objects.
Provides all mechanisms to avoid residual data
problems.
Includes a mechanism to lock the terminal if too
many failed login attempts are detected.
Defines the security attributes maintained for
users.
Implements a password authentication
mechanism. This includes defining the strength
of the mechanism and defining various
restrictions on password selection by users.
The system can not be used until a user
successfully logs in and no successful log in is
allowed, unless the user provides the correct
password for the user name entered.
The initial passwords provided in a new system
are marked as expired, so that they will have to
be changed during the initial login. When
administrators create new user accounts, they
can specify that the initial password can only be
used once.
The mechanism will not echo to the terminal, the
password which is entered by the user.
The system can not be used until a user
successfully logs in and no successful log in is
allowed, unless the user provides a valid user
name.
IDNAUT includes starting a user’s session at the
default MAC and MIC levels, and with the
default group, for that user. DACENF includes
checking that the default group is within the
group membership of the user. MACENF and
MICENF include checking that the default MAC
and MIC levels, respectively, are within the
user’s clearance and within the allowed ranges
for the terminal and system. SECMGT includes
allowing a user to change his or her session’s
MAC, MIC, and group and includes allowing an
administrator to change a user’s clearance, group
membership, and capabilities.
88
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Security
Management
Functional
Family SFR
(Component)
FMT_MOF.1
Security
Functions
SECMGT
Rationale that Security Function is
Suitable to Meet SFR
Includes trusted commands restricted to the
administrator which allow:
1. setting of a threshold for the number of
new audit files before the operator is
warned;
2. setting of the allowable MAC and MIC
ranges of devices;
3. configuring of a daemon to perform
abstract machine and TSF self-tests at
designated times;
4. setting of the threshold for the number
of allowed, failed login attempts;
5. setting of the lockout interval on a
terminal once the threshold of failed
login attempts has been hit;
6. setting of parameters for valid
passwords;
7. configuring a serial device as a login
terminal.
Restricts to administrators and operators the
trusted commands which provide the following
functions:
1. startup of hard-copy printing facilities;
2. setting the “class” of a disk device to
“user” or “trusted”;
3. restoring multi-level data from save
tape;
4. mounting and unmounting of file
systems.
89
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Functional
Family SFR
(Component)
FMT_MSA.1
Security
Functions
SECMGT
Rationale that Security Function is
Suitable to Meet SFR
Includes trusted commands restricted to the
administrator which allow:
1. setting of user clearances, such that a
very limited set will be allowed to act
as administrators or operators;
2. change the group membership of users;
3. setting of the MAC, MIC, and DAC
attributes of objects not owned by the
administrator, including restrictions
such that access by some subjects
would be revoked;
4. change of the default MIC and MAC
level and the default group for another
user;
5. setting the system time;
6. setting the terminal inactivity time
(after which a session will be logged
out).
Includes trusted commands restricted to the
administrator and operator which allow:
1. setting initial MAC and MIC range for
a new file system.
FMT_MSA.2
SECMGT
SECMGT
FMT_MSA.3NIAP-0409
Includes trusted commands available to
untrusted users which allow:
1. setting of the MAC, MIC, and DAC
attributes of objects owned by the user
(though MAC and MIC changes require
the appropriate capability), including
restrictions such that access by some
subjects would be revoked;
2. changing the default MIC and MAC
level of the user.
The trusted commands that provide for
“management” check that input security
attributes are within allowable limits.
Includes trusted commands that allow a user to
set his or her default MAC level, MIC level, and
group. Includes a trusted command which allows
an administrator to set the default MAC level,
MIC level, and group of any user.
90
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Functional
Family SFR
(Component)
Security
Functions
SECMGT
FMT_MTD.1
Rationale that Security Function is
Suitable to Meet SFR
Restricts to administrators the trusted commands
which allow creation, modification and deletion
of all security data, except:
1. a user’s own password;
2. a user’s own default MAC, MIC, and
group;
3. a device’s current level.
Restricts to administrators the trusted commands
which allow viewing of the following security
data:
1. audit records;
2. enabled/disabled audit events, users,
and levels.
Restricts to administrators and operators the
trusted commands which allow modification of
the following security data:
1. a device’s current MAC and MIC level.
Includes trusted commands available to
untrusted users which allow:
1. changing the user’s password (if the
user has the required capability).
AUDGEN,
SECMGT
FMT_MTD.2
DACENF,
MACENF,
MICENF,
SECMGT
FMT_REV.1
SECMGT includes trusted operator and
administrator commands to specify the size of a
file system and a threshold number of audit files.
AUDGEN includes a mechanism that checks
this threshold and generates a console message if
the threshold is reached. AUDGEN also includes
a mechanism to detect complete runout of disk
space for the audit trail, at which time the system
will be shut down.
SECMGT includes the only TSF interface to
allow the security attributes of a user to be
changed and this interface is restricted to
administrators. SECMGT includes the only TSF
interface to allow one user to modify the security
attributes of an object s/he does not own and this
interface is restricted to administrators.
SECMGT, DACENF, MACENF, and MICENF
include the only TSF interfaces to allow a user to
modify the security attributes of an object s/he
does own. DACENF, MACENF, and MICENF
include the revocation access checks.
91
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Functional
Family SFR
(Component)
FMT_SAE.1
FMT_SMF.1
FMT_SMR.1
Security
Functions
IDNAUT,
SECMGT
SECMGT
SECMGT
SECMGT
FMT_SMR.3
Protection of
the TOE
Security
Functions
FPT_AMT.1
FPT_RCV.2NIAP-406
FPT_RVM.1
SECFPR
SECFPR
SECFPR
SECFPR
FPT_SEP.1
TOE Access
FPT_STM.1
SECFPR
FPT_TST.1
SECFPR
IDNAUT
FTA_SSL.3
FTA_TAB.1
IDNAUT
IDNAUT
FTA_TAH.1
Trusted
Path/Channels
FTP_TRP.1
TRUPTH
Rationale that Security Function is
Suitable to Meet SFR
SECMGT includes an interface to allow an
expiration time to be set on passwords and this
interface is restricted to administrators.
IDNAUT checks the expiration time during a
login attempt and prevents the login if the
password to too old.
SECMGT is defined by the list given.
Includes a mechanism to support different roles.
Different roles can only be established by the
explicit action, on the part of the user, of either
logging in or changing the current session MIC
level. In the later case the new MIC level must
be within the clearance level of the user.
Includes the abstract machine test mechanism.
Note that this mechanism may actually be part of
the TSF self-test mechanism.
Includes a non-automatic recovery mechanism
using specific trusted commands that execute
while the TOE is in a maintenance mode.
Includes the mechanisms, which depend on
object type and specific policy, to implement a
reference validation monitor.
Includes the mechanisms, which depend on the
kinds of interference being prevented and the
portion of the TSF being protected, to implement
separation of the TSF and non-TSF domains.
Also includes the mechanism to separate subject
domains from one another.
Includes the mechanism for providing time
stamps.
Includes the TSF self-test mechanism.
Includes an inactivity timeout mechanism
whereby the user’s session will be logged out if
it is inactive for longer than an administratively
set threshold.
Includes login functionality that displays an
administratively set of notices and warnings.
Includes login functionality that, after a
successful login, notifies a user of information
about the previous successful and unsuccessful
logins.
Defines the trusted path mechanism.
92
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
6.1.1 Audit Generation – AUDGEN
The security audit generation function, AUDGEN, is a distributed function that generates
audit records for the security related events identified FAU_GEN.1 and Appendix F.
Audit events are generated by Trusted Software, Operating System Software, TSF
System Services, and the Kernel and include the following types of events:
•
•
•
•
•
•
•
•
•
Startup and shutdown of the operating system
Use of special permissions that circumvent the access control policies
Login attempts
Logout commands issued
Opens and closes of file system objects
Creates and deletes of file system objects
Operator commands issued
Administrator commands issued
Print request issued with no markings
Each audit record has a header that contains the size of the audit record, type of event
being audited, date and time of audit record generation, process ID of the process causing
the audit event, MAC and MIC label of the process, effective privileges of the process,
real user ID, and real group ID.
When a threshold number of recent audit files have been generated, a message is sent for
the administrator and operator at the system console (and all console messages can be
optionally written to a log). Audit files consume space on the boot file system, which can
fill up due to the audit trail or to other system activity, and are not placed on any other
disk. The warning message to the administrator gives him or her a chance to remove old
data from the boot file system or to archive old audit files on tape.
Disk space is held in reserve by the audit mechanism so that if disk space for permanent
storage of the audit trail runs out, all buffered records can still be written. When this
happens, the operator is notified of the problem and the system is shut down due to the
inability to continue generating audit data.
The audit trail is a set of audit files, in a special directory, that are collections of all the
audit records generated by request from various parts of the TSF. The audit files and
directory reside at administrator integrity so that only an administrator could modify or
remove them. The audit files reside at maximum security and are protected by a TSFinternal subtype mechanism so that untrusted users can not read them.
When the administrator changes the set of audit events, users, or levels to be audited
(which is the only way auditing can be enabled or disabled), the changes do not take
93
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
effect until the system is rebooted. Auditing is always started up during system booting,
assuming some events are enabled – no explicit action by a trusted user is necessary. The
only exception is that if the boot file system is out of space during boot, auditing will not
be started and a message to that effect will be presented to the operator. Note that
auditing is never enabled on Installation and Repair diskettes, due to the lack of disk
space.
6.1.2 Audit Review – AUDREV
The security audit review function, AUDREV, provides the authorized administrator the
tools necessary to examine and review the audit records generated by the AUDGEN
function.
The Trusted Software audit command accepted option of “display” is used to view the
audit data through the use of three subcommands (print, reset, and select). It formats the
raw audit data to allow management of the audit files via one of five options (switch,
remove, files, display, and exit). No other trusted command is provided for reviewing the
audit trail. Because the audit files are at maximum integrity and protected by a TSFinternal subtype mechanism, the only other way to review the audit trail is by having an
administrator use the trusted “fsm” command, but that will not produce a human-readable
display.
Operators can use the audit command, but can not use it to review the audit trail. They
can only see which audit files exist and request that a new file be started.
Valid audit selection criteria are audit event type, start date and time, stop date and time,
process ID, user ID, group ID, device ID, trusted editor command name, trusted editor
request, file name, and object level.
6.1.3 Discretionary Access Control – DACENF
The discretionary access control function, DACENF, enforces the Discretionary Access
Control policy for the STOP OS, based on user identity and group membership of the
subject and owner identity, group, and operation allowed for the object.
The TOE allows owning users to define and control access to named objects through the
use of an Access Control List (ACL). Every subject has associated with it an effective
user and group; every named object has an ACL. Each ACL contains permissions that
specify the allowable access for the owning user, the owning group, up to seven other
user or groups, and any user or group not explicitly listed. These permissions can either
grant or deny a particular form of access to a named object. When a subject introduces an
object into its address space, the ACL is checked to ensure that the subject can access the
object.
94
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
The kinds of access that are controlled are read. write, and execute. Write does not imply
the ability to delete and some objects can not be executed.
Only administrators can introduce new users and groups to the system, establish the
group membership of users, or set the default group for users. Normal users can change
the discretionary attributes of only the objects they own, but administrators can change
the attributes of any object.
6.1.4 Mandatory Access Control – MACENF
The mandatory access control function, MACENF, enforces the Mandatory Access
Control policy for the STOP OS, based on user clearance (level and category(ies)) of the
subject and classification (level and category(ies)) of the object.
The TSF enforces a mandatory access control policy over all identified system resources
(i.e., subjects, storage objects, and I/O devices) that are accessible, either directly or
indirectly, to subjects external to the TSF. As the basis of its enforcement, this policy
uses MAC labels that are associated with every subject and object in the system. These
MAC labels consist of 16 hierarchical sensitivity levels, and 64 nonhierarchical
sensitivity categories.
The TOE provides a dominates function that is used to compare sensitivity labels; this
comparison is done whenever a subject external to the TSF accesses an object. Every user
has an identification and authentication database record that specified the MAC label of
the user’s clearance. The TSF enforces the restriction that any subject created on behalf
of a user has a current MAC label dominated by the user’s clearance.
The kinds of access that are relevant are read and write – execute is considered the same
as read. The MAC level of processes and some objects can not be modified. Only
administrators can change the MAC level of an object, except that a user (who has been
granted an appropriate capability) can change the level of objects that s/he owns. A MAC
level change to an object will take effect immediately, even if that means denying access
to the object by a process which already has the object “open”.
Mandatory security control is used internally by the TSF to prevent viewing of sensitive
TSF data, including the audit trail and authentication data.
The TSF is designed to minimize the covert channels that exist to circumvent the MAC
policy†. Potential use of covert storage channels is detected and a resource exhaustion
delay is used to reduce covert storage channel capacity without eliminating any user
capabilities. The delay is imposed only when a resource exhaustion error occurs. The
resource exhaustion delay is a site-set time interval that puts processes to sleep for a set
95
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
amount of time when a resource exhaustion condition is encountered. The param_edit
command is used to change the default value. Potential use of a storage channel is also an
auditable event.
6.1.5 Mandatory Integrity Control – MICENF
The mandatory integrity control function, MICENF, enforces the Mandatory Integrity
Control policy for the STOP OS, based on user clearance, user integrity level of the
subject, and integrity level of the object.
The TSF enforces a mandatory integrity control policy over all identified system
resources (i.e., subjects, storage objects, and I/O devices) that are accessible, either
directly or indirectly, to subjects external to the TSF. As the basis of its enforcement, this
policy uses MIC labels that are associated with every subject and object in the system.
These MIC labels consist of 8 hierarchical integrity levels, and 16 nonhierarchical
integrity categories.
The TOE provides a dominates function that is used to compare integrity labels; this
comparison is done whenever a subject external to the TSF accesses an object. Every user
has an identification and authentication database record that specified the MIC label of
the user’s clearance. The TSF enforces the restriction that any subject created on behalf
of a user has a current MIC label that dominates the user’s MIC clearance.
The kinds of access that are relevant are read and write – execute is considered the same
as read. The MIC level of processes and some objects can not be modified. Only
administrators can change the MIC level of an object, except that a user (who has been
granted an appropriate capability) can change the level of objects that s/he owns. A MIC
level change to an object will take effect immediately, even if that means denying access
to the object by a process which already has the object “open”.
Mandatory integrity control is used internally by the TSF to prevent modification or
deletion of TSF data, including the audit trail and configuration parameters for “alarm”
mechanisms (such as low disk space, low audit trail space, excessive failed login
attempts).
6.1.6 Residual Information Protection – RIPENF
The residual information protection function, RIPENF, provides object reuse control for
the STOP OS. The TSF is designed to prevent a process from seeing any information left
over in an object or memory area from use by another process (or the TSF itself).
Generally, main memory and device memory/media/registers are cleared as needed, in a
manner dependent on the resource in question.
96
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
When a file is deleted, the name of the file is deleted, leaving no residual information in
the directory (this is a variation from the standard UNIX behavior). All entries into the
TSS are cleared when allocated to a new address. When a segment shrinks, the TSF
clears residual data in partial pages.
6.1.7 Identification and Authentication – IDNAUT
The identification and authentication function, IDNAUT, provides and controls the
identification and authentication of users of the STOP OS. Users are required to enter
their user name and password prior to gaining access to any other functions of the system.
User names are converted to a user-id. Passwords are encrypted and compared to the
encrypted password, for that user-id, in the user authentication database.
Passwords are never stored in the clear and the encryption mechanism used is relatively
strong encryption (128-bit MD5). In addition the passwords are stored in a database that
is protected with a TSF-internal subtype so that not even users cleared for maximum
security can read it.
The administrator can specify the following system-wide parameters for passwords:
minimum password length
• mixed case required
• non-alphanumeric characters required
• password history size (if the history is of size N, when a user changes his or her
password, it can not be the same as any of his or her last N passwords)
• expiration time (after which the user must change the password)
• lifetime (after which the user can not log in nor change the password)
• maximum consecutive erroneous passwords
The identification and authentication function, IDNAUT, also provides advisory banners
prior to user identification and authentication and login history after successful
identification and authentication. The login history includes the number of failed login
attempts since the last logout, potentially alerting the user that someone has been trying
to break into his or her account.
The identification and authentication function, IDNAUT, also associates attributes with a
user following a successful login. These attributes are set by an administrator, except that
the user can change the default MAC and MIC levels, within his or her administratively
set clearance.
The identification and authentication function, IDNAUT, also provides TSF-initiated
termination of interactive user sessions after an administratively defined inactivity
timeout occurs. This serves primarily to lessen the chance that a user “walks away” from
97
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
his session such that another person can make unauthorized use of the session, but serves
partly as a screen saver.
The identification and authentication function, IDNAUT, also monitors the number of
failed login attempts. When an administratively configured threshold is reached, a
console message is generated for the administrator and the terminal is locked for an
administratively set time. Only an administrator can unlock a terminal.
6.1.8 Security Management – SECMGT
The security management function, SECMGT, provides the management functions to
support most of the other functions. It allows authorized administrators and, in some
cases operators, to specify initial values, change values, and monitor (as appropriate) the
security parameters that affect the behavior of the TOE.
SECMGT also provides for three distinct user roles (administrator, operator, and user).
The roles are implemented using MIC levels for users. Normal users have a clearance
that specifies a maximum integrity level below that required for the operator role.
Operators execute at an integrity level below that required by the administrator role.
All TSF data, other than the runtime data dynamically held by the TSF, resides in files
that are at the administrator integrity level. This prevents any user other than an
administrator, or any process running below administrator integrity, from modifying the
data. Some trusted commands have privileges that allow operators to modify some of
these data items in controlled manners.
A normal user is not allowed to modify or delete TSF data, but are allowed to change
some of the security attributes of their own login session or their own objects.
Use of all commands restricted to operators and administrators is auditable. This includes
commands that would be used to archive and restore audit files, and that would be used
for multi-level backups and restores in general (and the opening and closing of devices on
which to archive/restore, and of the files themselves, are also auditable).
6.1.9 Security Function Protection – SECFPR
The security function protection function, SECFPR, provides protection mechanisms for
the security functions of the TOE. The TSF is carefully designed to protect itself from
tampering or bypass by untrusted code and users. This includes mechanisms to:
• test the abstract machine to ensure that features of the hardware and firmware that
are relied upon for secure operation are functioning properly;
98
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
•
•
•
•
•
self-test the TSF itself to verify that it has not been tampered with or affected by a
bug;
avoid tampering of the TSF by untrusted code;
avoid tampering of one process by another;
avoid bypass of the access control mechanisms by untrusted code;
repair file systems in a secure fashion after a system crash.
The abstract machine tests and TSF self-tests are provided together in a single trusted
command. The operator, or any user, can run these whenever desired and the
administrator can configure them to run periodically in the background. Normal users,
however, are not allowed to generate new checksum information for the TSF files, since
that could impede the ability of trusted users to correctly make use of the checksums. As
much of the hardware is included in the TSF, the abstract machine tests could really be
considered part of the TSF self-tests.
In the event that the TOE crashes, the file systems that were mounted at the time of the
crash will have to be repaired before they can be used again. The TSF will prevent
booting from, or mounting, a file system that was not previously properly unmount or
repaired, since the security attributes for objects in the file system may be corrupt (in rare
circumstances). Two trusted commands are provided to check the validity of file systems
and to repair them. They are usable only by operators and administrators. The boot file
system is repaired in a maintenance mode.
6.1.9.1 How Domain Separation is Provided by the TOE
The maintenance of a security domain for the TSF's execution that protects it from
interference and tampering by untrusted subjects (FPT_SEP.1.1) is done partly by
hardware and partly by software. The hardware provides primitive building blocks to
support this as follows:
•
•
•
•
Has a privilege domain mechanism that allows software executing in a privileged
domain to be inaccessible to software executing in an unprivileged domain and
that allows privileged software to restrict access to I/O instructions to privileged
software. There are at least two privilege levels.
Hardware descriptors control which domains can access which areas in physical
memory and control where unprivileged software can transfer into privileged
software. These descriptors are only modifiable by hardware-privileged software.
Unprivileged software has no way to disable or circumvent the descriptors and
has no way to gain privilege, other than by making controlled transfers to
privileged software through the aforementioned descriptors.
Unprivileged software has no way to modify other hardware descriptors, the mode
of operation of the hardware, nor the control and configuration registers or the
hardware.
99
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
However, the hardware does not “know”:
a. which software is trusted and which is not;
b. where the allowable entry points into the TSF are.
Also, some aspects of providing the domain separation are implemented completely in
software, with no reliance on the hardware building blocks. The TSF (software)
implements the protection, with full awareness of the security state and requirements, by:
a. packaging code into file system objects (well-defined, well-bounded
containers);
b. marking and distinguishing code as trusted or untrusted by virtue of integrity
and privilege attributes attached to the containing file system object;
c. preventing creation or modification, by untrusted code, of file system objects
containing trusted code;
d. starting untrusted software in an unprivileged domain and requiring TSF
involvement in creation of new subjects;
e. avoiding use of or transfers to untrusted code (fragments) from within
privileged domains;
f. controlling exactly where and how untrusted code can make requests of the
TSF;
g. providing a very limited, well-defined, and secure set of services that
unprivileged code can request;
h. checking the location of parameters specified by unprivileged code to ensure
that they are not within the privileged domain(s);
i. setting hardware flags to a safe state for the TSF upon entry to the TSF from
untrusted code (where some of these flags are settable by untrusted code);
j. implementing (fully in software) domain attributes for semaphore, shared
memory, and process objects and using those attributes to prevent the TSF’s
internal objects from being created or manipulated by unprivileged code;
k. using the mandatory integrity mechanism to prevent creation or modification
of TSF objects by untrusted code;
l. setting up all hardware descriptors for TSF-internal objects, processes, and
mechanisms such that the hardware will cause a fault if unprivileged code
attempts to use the descriptor;
m. setting hardware flags to make I/O instructions cause a fault if attempted by
unprivileged code;
100
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
n. setting up all hardware fault and trap descriptors so that the TSF will catch all
interrupts and faults from the hardware;
o. refusing to perform any service on behalf of untrusted code, or to allow the
attempted use to proceed, when the hardware generates a fault due to the
untrusted code attempting to use a descriptor, register, or instruction that is
restricted to privileged code;
p. refusing to allow unprivileged code to hog the CPU or to fill up the audit trail
to the point that the TSF security functions would become disabled or
malfunction [note that unprivileged code may still be able to slow down TSF
operations significantly or may precipitate an orderly shut down of the
system];
q. setting the CPU state to enable all hardware building blocks for protection
features;
r. setting up hardware descriptors for the virtual memory mechanism such that
the privileged and unprivileged code reside in well-defined, limited, and nonoverlapping memory areas;
s. refusing to perform any service on behalf of untrusted code, or to allow the
attempted use to proceed, when the hardware generates a fault due to the
untrusted code attempting to access a memory location outside its allowed
memory area.
The enforcement of separation between the security domains of subjects in the TSC
(FPT_SEP.1.2) is done partly by the hardware and partly by software. The hardware
provides primitive building blocks to support this as follows:
•
•
•
Has a virtual memory mechanism that allows the set of physical “pages”
accessible to the current execution thread to be limited to a subset of all physical
pages available to the current domain.
The virtual-to-physical mapping allows certain areas to be marked read-only.
The virtual-to-physical mapping is switchable only by hardware-privileged
software and unprivileged software has no way to disable, circumvent, or modify
the mapping.
However, the hardware does not “know”:
a. which objects and/or code constitutes a subject;
b. which constituent parts of a subject can be shared with other subjects.
Also, some aspects of providing the domain separation are implemented completely in
software, with no reliance on the hardware building blocks. The TSF (software)
implements the protection, with full awareness of the security state and requirements, by:
101
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
a. packaging code into file system objects (well-defined, well-bounded
containers);
b. implementing process-local memory areas (in addition to process-global
memory areas) that are of limited size and that do not overlap with any other
memory areas;
c. placing the code and private data for a subject in process-local memory areas;
d. not providing any service to untrusted code that allows one subject to access
another subject’s process-local memory areas;
e. requiring TSF involvement in creation of new subjects and switching of
control between subjects;
f. using the mandatory integrity mechanism to prevent modification of TSF
objects (which may be “mapped” into a subject) by untrusted code;
g. setting up hardware tables in a particular way to define the memory areas for a
process;
h. associating specific hardware tables with specific processes;
i. setting up hardware memory descriptors in a particular way for a subject such
that the hardware will cause a fault if the subject attempts to access memory
outside the bounds of the descriptors;
j. setting up all hardware fault descriptors so that the TSF will catch all faults
from the hardware;
k. refusing to perform any service on behalf of untrusted code, or to allow the
attempted use to proceed, when the hardware generates a fault due to a subject
attempting to access memory outside the bounds allowed by the subject’s
hardware memory descriptors;
l. setting the CPU state to enable hardware building blocks for virtual memory
support.
6.1.9.2 How Reference Validation is Provided by the TOE
The insurance that TSP enforcement functions are invoked and succeed before each
function within the TSC is allowed to proceed (FPT_RVM.1.1) is done partly by the
hardware and partly by the software. The hardware provides primitive building blocks to
support this are the same as those given above for domain separation. However, the
hardware does not “know”:
a. which kinds of objects and functions exist;
b. which different kinds of accesses are supported.
102
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Also, some aspects of providing the reference validation mechanism are implemented
completely in software, with no reliance on the hardware building blocks. The TSF
(software) implements the protection, with full awareness of the security state and
requirements, by:
a. defining a set of objects, their attributes, and how the policies apply to them;
b. implementing (fully in software) access control (at every access attempt) for
semaphore, device, socket, and process objects;
c. implementing (fully in software) access control during initial
opening/mapping for file system and shared memory objects;
d. providing services to non-TSF software that allow well-defined portions of
file system and shared memory objects to be “mapped” into well-defined
areas of a process’s address space;
e. setting up hardware memory descriptors to limit access to mapped file system
and shared memory objects to exactly the approved regions of the process’s
address space;
f. requiring TSF involvement in creation of, and initial access to, all kinds of
objects;
g. converting requests for “execute” permission to read permission and
converting requests for “write-only” permission to read-write permission,
because of limitations in the underlying abstract machine;
h. disabling hardware memory descriptors when access to mapped objects is
revoked;
i. setting up all hardware fault descriptors so that the TSF will catch all faults
from the hardware;
j. refusing to perform any service on behalf of untrusted code, or to allow the
attempted use to proceed, when the hardware generates a fault due to a subject
attempting to access an object through a disabled hardware memory
descriptor;
k. setting the CPU state to enable hardware building blocks for virtual memory
support.
6.1.9.3 How Reliable Time Stamps are Provided by the TOE
The production of reliable time stamps (FPT_STM.1.1) is done partly by the hardware
and partly by the software. The hardware provides primitive building blocks to support
this as follows:
•
It stores, and updates, the time-of-day while the TOE is not running.
103
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
•
It provides periodic timers/counters that the TSF can use at run-time to calculate
the current time-of-day.
However, the hardware does not “know”:
a. whether the stored time is correct;
b. which time zone or daylight savings time offsets to apply;
c. whether relative or absolute times are needed;
d. what format times will be kept or displayed in.
Also, some aspects of providing reliable time stamps are implemented completely in
software, with no reliance on the hardware building blocks. The TSF (software)
implements the protection, with full awareness of the security state and requirements, by:
a. applying appropriate time zone and daylight savings modifications to the time;
b. setting up the PIT registers to count and interrupt in a particular way;
c. setting up hardware descriptors to route PIT interrupts to the appropriate TSF
interrupt handler;
d. using PIT interrupts to update the running (absolute) time stored in the TSF
(software);
e. notifying the interrupt hardware when interrupt processing is complete;
f. serializing access to the PIT hardware counter and to the TSF-stored time;
g. placing time stamps in audit records, console log entries, and databases of
login activity;
h. displaying time stamps associated with audit records and previous login
activity.
i. providing an interface for an operator to display and change the absolute time
kept in software and to change the time zone and daylight savings values;
j. placing corrected times into the hardware for storage when the TOE is not
active;
k. providing a programmatic interface for non-TSF software to obtain the current
absolute time.
6.1.10 Trusted Path – TRUPTH
The trusted path function, TRUPTH, provides a trusted communication path between
users and the TSF.
104
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Note that “remote” users, i.e., across a network, are not supported. Users on serial
terminals are considered local users. The <Break> key invokes the Trusted Path key for
serial terminal users. On the console the sequence is <Ctrl-Alt-SysRq>. These are known
as the SAK (Secure Attention Key). Any invocation of the SAK leads to a Trusted Path.
SAK must be used to initiate a login. Any time SAK is used, the user will obtain a
prompt from a part of the TSF known as the Secure Server. If the terminal is not already
handling a login session, a login is initiated; otherwise the user can request running of
any trusted command. Use of SAK which processes are already running returns the
display to a known state and severs access by those processes to the display. Access to
the display by those processes can be restored with the trusted “reattach” command.
105
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
6.2 Assurance Measures
The XTS-400, Version 6 claims to satisfy the assurance requirements for Evaluation
Assurance Level (EAL) 5+. Table 6-1 shows the assurance requirements and the
assurance measures that meet them.
Table 6-3 Security Assurance Requirements and the Security Measures
That Meet Them
Class Name
Configuration
Management
Assurance
Component
ACM_AUT.1
ACM_CAP.4
ACM_SCP.3
Delivery and
Operation
Development
ADO_DEL.2
Assurance Measure(s) and
Rationale
CVS is used to control changes to the
implementation representation. Scripts and
CVS provide automated support for
generating the TOE.
Each version of the TOE has a unique
version ID and that ID is available through
a trusted command and appears on the
delivery documentation. All constituent
components of the TOE are associated with
configuration items and each version of
each item is uniquely identified. Processes
are in place such that all changes to
configuration items have to be reviewed and
approved. CM processes include procedures
to build a release of the TOE.
CM processes cover not only the
implementation representation, but also
documents, product flaws, and development
tools. The CM system includes mechanisms
to retrieve older versions of configuration
items and to determine differences between
versions of any configuration item.
Processes are in place to assure secure
delivery of the TOE to customers.
ADO_IGS.1
Specific procedures exist for the customer
to securely install and start up the TOE.
ADV_FSP.3
The external TSF interfaces are
documented.
The high-level design of the TSF is
documented.
All source code is provided.
ADV_HLD.3
ADV_IMP.2
106
UNCLASSIFIED
Document(s)
CM-Plan
CM-Plan
CM-Plan
CM-Plan, Software
Release Bulletin
Software Release
Bulletin, TFM
Functional Specification
HLD
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Assurance
Component
ADV_INT.1†
ADV_LLD.1
ADV_RCR.2
ADV_SPM.3
Guidance
Documents
AGD_ADM.1
Life Cycle
Support
ALC_DVS.1
AGD_USR.1
ALC_FLR.3
ALC_LCD.2
ALC_TAT.2
Test
ATE_COV.2
ATE_DPT.2
ATE_FUN.1
ATE_IND.3
Assurance Measure(s) and
Rationale
The TSF is internally designed and
implemented using strong architectural
features.
The low-level design of the TSF is
documented.
Correspondence between all design
abstraction levels is documented.
MAC, MIC, and DAC policy enforcement
follows strict rules. Correspondence to the
Functional Specification is documented.
Extensive administrative guidance is
provided to the customer.
Extensive user guidance is provided to the
customer.
Physical, procedural, and personnel
processes are in place to protect the TOE
while in development.
There are specific points-of-contact for a
customer to use when reporting TOE
problems. There is a bug reporting and
tracking tool and a database of bug reports.
Processes are in place to quickly recognize
security flaws and to remedy them.
A standard life-cycle model governs
changes made to the TOE.
The CM system defines the development
tools. The Coding Standards provide a
reference for meaning of implementation
representation statements and shows the
values of tools options.
Multiple tests are provided for each TSF
interface.
Many tests indirectly test each subsystem. A
depth analysis shows which test map to
each subsystem and module.
The purpose, method, and expected results
of each test are documented.
Method for installing and running the tests
is documented.
107
UNCLASSIFIED
Document(s)
HLD (particularly the
section of the top-level
document entitled
General Architectural
Features), LLD
LLD
LLD, HLD, Functional
Specification
Security Model
TFM
User’s Manual
CM-Plan
CM-Plan
CM-Plan
CM-Plan, Coding
Standards,
Documentation
Guidelines
Test Guide
Test Guide
Test Guide
Test Guide
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Class Name
Vulnerability
Analysis
Assurance
Component
AVA_CCA.1†
AVA_MSU.2
AVA_SOF.1
AVA_VLA.3
Assurance Measure(s) and
Rationale
Covert channel analysis has been performed
and the capacities of all usable channels are
estimated. Though the hardware is not
included in the TOE, assumptions about the
maximum speeds of hardware components
have been made and operation timings have
been extrapolated down to use those limits
for worst-case capacity calculations.
The TFM documents all modes of
operation, all assumptions about the IT
environment, and mentions all requirements
for external security measures. An analysis
has been performed to verify that the
guidance is complete, consistent, and clear.
A strength-of-function analysis has been
performed on password guessing. The
strengths of these mechanisms meet the
requirements of this ST and the LSPP.
A systematic search for vulnerabilities has
been made.
Document(s)
Covert Channel Analysis†
TFM
ST
Vulnerability Analysis
6.3 IT Security Functions Realized by Probabilistic or
Permutational Mechanisms
The only IT security function that includes probabilistic or permutational mechanisms is
IDNAUT. As stated in section 5.4, this TOE meets a strength of SOF-high.
Within IDNAUT, the methods used to provide difficult-to-guess passwords are
probabilistic.
108
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
7 PP Claims
This section provides the PP Conformance claims for the XTS-400, Version 6 Security
Target.
7.1 PP Reference
The TOE conforms to the Labeled Security Protection Profile (LSPP) Version1.b, 8
October, 1999. It also conforms to the Controlled Access Protection Profile (CAPP)
Version 1.d, 8 October, 1999. CAPP is a subset of LSPP and will not be discussed
further.
7.2 PP Refinements, Selections, and Assignments
Refinements, selections, and assignments to the requirements from the LSPP are shown
in boldface in Section 5.1 of this ST. Table 5-1 denotes which SFRs are part of the LSPP.
7.3 PP Additions
Assumptions, Threats, and Objectives have been added or further refined to reflect the
capabilities of the TOE.
The following objectives were added:
• O.AC_Admin_Limit
• O.Access_History
• O.Admin_Role
• O.Audit_Protection
• O.Authorities
• O.Display_Banners
• O.Mandatory_Integrity
• O.Markings
• O.Protect
• O.Recovery
• O.Self_Protection
• O.Testing
• O.Trained_Users
• O.Trusted_Path
• O.User_Authentication
• O.User_Identification
• O.Vulnerability_Analysis
The following SFRs have been added to support these objectives:
109
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
FAU_SAA.1
FAU_STG.2-NIAP-0422 (LSPP requires only FAU_STG.1)
FDP_ACC.2 (LSPP requires only FDP_ACC.1)
FDP_IFC.2 (LSPP requires only FDP_IFC.1)
FIA_AFL.1-NIAP-0425
FIA_UAU.2 (LSPP requires only FIA_UAU.1)
FIA_UAU.4
FIA_UID.2 (LSPP requires only FIA_UID.1)
FMT_MOF.1
FMT_MSA.2
FMT_MTD.2
FMT_SAE.1
FMT_SMF.1 (required by CCIMB-65)
FMT_SMR.3
FPT_ RCV.2-NIAP-406
FPT_TST.1
FTA_SSL.3
FTA_TAB.1
FTA_TAH.1
FTP_TRP.1
The LSPP uses an EAL3 assurance package. Therefore all of those assurance
requirements are included or superceded by this ST (EAL5+). EAL5 includes the
following assurance components that are not even part of EAL3: ACM_AUT,
ADV_IMP, ADV_INT†, ADV_LLD, ADV_SPM, ALC_LCD, ALC_TAT, and
AVA_CCA†. In addition, this ST includes ALC_FLR, which is not even part of EAL5.
The additional SFRs provide additional features desired by XTS-400 customers, make the
system more flexible for a wider range of customers and applications, and contribute to
overall higher security. The additional assurance is needed by customers that have
systems in higher threat environments and with more levels of more sensitive data than is
intended by the LSPP.
110
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
8 Rationale
This section of the ST will describe how the threats, assumptions, and policies are
addressed by the security objectives of the TOE. Table 8-1 provides the mapping of each
threat, assumption, and policy to the security objective(s) that address them.
For a rationale that each security function defined in the TOE Summary Specification is
suitable to meet the SFRs, see table 6-2. For a rationale that each assurance measure
defined in the TOE Summary Specification is suitable to meet the SARs, see table 6-3.
8.1 Security Objectives Rationale
Table 8-1 Mapping the TOE Security Environment to Security Objectives
Policy/Threat/Assumption
A.Admin_Errors
Justification
Assumptions
OE.Admin ensures that only
competent administrators are
chosen and they understand the
guidance documentation.
O.Admin_Trained ensures that the
administrators are trained.
O.AC_Admin_Limit limits the
actions an administrator is capable
of. O.Audit_Gen_User ensures that
actions taken by administrators are
auditable and can therefore be
reviewed later.
111
UNCLASSIFIED
Objective
OE.Admin
O.AC_Admin_Limit
O.Admin_Trained
O.Audit_Gen_User
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Policy/Threat/Assumption
A.Outsider_Hi
A.User_Mistakes
Justification
Many of the objectives for both the
TOE and the environment are
intended to counter a highly
capable and motivated attacker.
Generally a high assurance TOE is
required. Specifically, the
environment must physically
protect the system and must
provide for capable administrators
that will correctly configure the
system and review system activity.
The TOE must protect itself. The
TOE must have mechanisms in
place to limit circumvention of
policy via residual data or covert
channels†. The TOE must provide
a good auditing mechanism, so that
attack activity can be recorded.
Vulnerability analysis must be
performed so that subtle
weaknesses are uncovered.
OE.User ensures that only
competent users are chosen and
they understand the guidance
documentation. O.Trained_Users
ensures that the users are trained.
O.Audit_Gen_User ensures that
actions taken by users are
auditable and can therefore be
reviewed later.
Objective
OE.Admin
OE.Physical
O.Audit_Gen_User
O.Protect
O.Self_Protection
O.Vulnerability_Analysis
OE.User
O.Audit_Gen_User
O.Trained_Users
Policies
P.Accountability
P.Authorities
Auditing security relevant events
provides a basis for user
accountability. Administrators
must exist to enable and review the
auditing.
Audit data would provide a basis
for threats being reported to
authorities. The vendor also has a
flaw remediation process in place.
112
UNCLASSIFIED
O.Admin_Role
O.Audit_Gen_User,
O.Audit_Generation,
O.Audit_Protection,
O.Audit_Gen_User,
O.Audit_Review,
O.Admin_Trained,
O.Authorities
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Policy/Threat/Assumption
P.Authorized_Use
P.Authorized_Users
P.Availability
P.Classification
P.Guidance
Justification
Information shall be used for
authorized purposes through
training, System Banners and
through audit accountability.
Administrators must exist to
configure the mandatory levels of
user terminals and management
functions must exist to allow such
configuration.
The TOE shall ensure that only
authorized users gain access to the
TOE and its users. Users are also
told at login time of previous
logins so that they may assess if
another user has been using their
account. Administrators must exist
to add and remove users from the
system and management functions
must exist to allow such
configuration.
The TOE shall protect resources to
ensure information availability to
authorized users and processes.
The TOE shall restrict access by
sensitivity level. Administrators
must exist to configure the MAC
levels of users and system devices
and management functions must
exist to allow such configuration.
The TOE shall provide written
procedures to ensure proper
installation and operation by
trained users and administrators.
P.Information_AC
Information access shall be limited
to authorized users and processes
by the MIC, MAC, DAC policy
enforcement and by audit
traceability
P.Integrity
Information integrity shall be
protected by the TSF’s
enforcement of MIC policy.
113
UNCLASSIFIED
Objective
O.Admin_Role
O.Display_Banners
O.Audit_Gen_User
O.Audit_Review
O.Manage
O.Trained_Users
O.Admin_Trained
O.Access
O.Access_History
O.Admin_Role
O.Manage
O.Self_Protection
O.Trusted_System_Oper
ation
O.Admin_Role
O.Mandatory_Access
O.Manage
O.Install
O.Admin_Trained
O.Trained_Users
O.Audit_Gen_User
O.Discretionary_Access
O.Discretionary_User_C
ontrol
O.Mandatory_Access
O.Mandatory_Integrity
O.Mandatory_Integrity
O.Trusted_System_Oper
ation
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Policy/Threat/Assumption
Justification
Objective
O.Discretionary_Access
O.Discretionary_User_C
ontrol
O.Mandatory_Access
O.Mandatory_Integrity
O.Markings
P.Marking
Data contained in named objects
shall have associated MAC, MIC
and DAC labels. Unnamed objects
shall protect information by
inheriting the owning subject’s
sensitivity/integrity levels.
P.Need_to_Know
Users must have a need to know
before accessing or destroying
data. Administrators must exist to
configure the group membership
and cleared security categories for
users and management functions
must exist to allow such
configuration.
O.Admin_Role
O.Discretionary_Access
O.Manage
O.Mandatory_Access
O.Mandatory_Integrity
Malicious code is prevented from
executing on the TOE by resource
protection, and MAC, MIC, DAC
policy enforcement.
O.Self_Protection
O.Protect
O.Discretionary_Access
O.Discretionary_User_C
ontrol
O.Mandatory_Access
O.Mandatory_Integrity
Threats
T.Malicious_Code
T.Admin_Err_Commit
T.Admin_Err_Omit
T.Admin_Hostile_Modify
T.Covert_Channel†
T.Dev_Flawed_Code
To prevent errors of administrators
that compromise security, they are
trained properly and limited in
roles and access.
To prevent errors of administrators
that compromise security, they are
trained properly.
The threat of a hostile
administrator is mitigated through
role and access limitation and
traceability by audit.
The threat of covert channel use is
mitigated design of the TSF to
eliminate some of them, auditing
of them where possible, and timing
delays to slow their speed†.
The threat of flawed code is
mitigated by configuration
management, rigorous testing and
vulnerability analysis.
114
UNCLASSIFIED
O.Admin_Trained
O.AC_Admin_Limit
O.Admin_Trained
O.AC_Admin_Limit,
O.Audit_Gen_User
O.Audit_Generation
O.Mandatory_Access
O.Trusted_System_Oper
ation
O.Config_Mgmt
O.Testing
O.Vulnerability_Analysis
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Policy/Threat/Assumption
Justification
T.Hack_AC
The threat of a hacker attack is
mitigated by strict enforcement of
MAC, MIC, DAC policies,
resource protection, as well as by
ensuring the system can withstand
penetration and other attempts to
gain unauthorized access. Users
are also told at login time of
previous logins so that they may
assess if another user has been
using their account.
T.Audit_Corrupt
Audit files are to be well protected
and accessible to authorized
administrators.
T.Config_Corrupt
Configuration files are to be well
protected and accessible to
authorized administrators.
T.Improper_Installation
T.Insecure_Start
T.Objects_Not_Clean
T.Poor_Design
T.Poor_Implementation
The TOE shall be installed in
accordance with well defined
procedures by trained individuals.
The TOE shall be able to restart
without compromising security.
The TSF will ensure that
information stored in an object will
not be shared if object resource is
reallocated.
This threat will be countered by
sound, proven, accepted design
practices.
This threat will be countered by a
sound implementation of the
design.
115
UNCLASSIFIED
Objective
O.Audit_Gen_User
O.Access
O.Access_History
O.Audit_Generation
O.Audit_Protection
O.Discretionary_Access
O.Discretionary_User_C
ontrol
O.Mandatory_Access
O.Mandatory_Integrity
O.Protect
O.Self_Protection
O.Trusted_Path
O.Vulnerability_Analysis
O.Audit_Protection
O.Mandatory_Access
O.Mandatory_Integrity
O.User_Identification
O.User_Authentication
O.Mandatory_Access
O.Mandatory_Integrity
O.User_Identification
O.User_Authentication
O.Install
O.Admin_Trained
O.Recovery
O.Residual_Information
O.Trusted_System_Oper
ation
O.Sound_Design
O.Vulnerability_Analysis
O.Sound_Implementation
O.Testing
O.Vulnerability_Analysis
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Policy/Threat/Assumption
T.Poor_Test
T.Power_Disrupt
T.Replay
Justification
The TOE will undergo rigorous
testing to ensure that all security
objectives are met.
This threat is mitigated by trusted
recovery.
This threat is countered by
performing authentication over a
trusted path.
T.Sysacc
The threat of a malicious user or
process gaining administrator level
access is mitigated by strict
enforcement of MAC, MIC, DAC
policies, resource protection, as
well as by ensuring the system can
withstand penetration and other
attempts to gain unauthorized
access.
T.Unattended_Session
The TOE implement measures to
ensure unattended sessions cannot
be exploited by malicious users or
processes
T.Unauth_Modification
Objective
O.Testing
O.Recovery
O.Trusted_Path
O.Trusted_System_Oper
ation
O.Audit_Gen_User
O.Access
O.Audit_Generation
O.Audit_Protection
O.Discretionary_Access
O.Discretionary_User_C
ontrol
O.Mandatory_Access
O.Mandatory_Integrity
O.Protect
O.Self_Protection
O.Trusted_Path
O.Vulnerability_Analysis
O.Trusted_System_Oper
ation
O.Protect
O.Self_Protection
OE.Secure_Term
O.Audit_Gen_User
O.Access
O.Audit_Generation
The threat of unauthorized
O.Audit_Protection
modifications to system attributes
and resources is mitigated through O.Discretionary_Access
O.Discretionary_User_C
the enforcement of MAC, MIC,
DAC policies, resource protection, ontrol
as well as by ensuring the system
O.Mandatory_Access
can withstand penetration and
O.Mandatory_Integrity
other attempts to gain unauthorized O.Protect
access.
O.Self_Protection
O.Vulnerability_Analysis
116
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Policy/Threat/Assumption
T.User_Corrupt
T.Hack_Social_Engineer
T.Spoofing
T.User_Improper_Export
T.User_Abuse
Justification
Objective
O.Audit_Gen_User
O.Access
O.Audit_Generation
The threat of unauthorized
O.Audit_Protection
modifications to system attributes
O.Discretionary_Access
and resources is mitigated through
O.Discretionary_User_C
the enforcement of MAC, MIC,
DAC policies, resource protection, ontrol
as well as by ensuring the system
O.Mandatory_Access
can withstand penetration and
O.Mandatory_Integrity
other attempts to gain unauthorized O.Protect
access.
O.Self_Protection
O.Vulnerability_Analysis
This threat is mitigated by the
proper training of administrators
and users regarding password
selection. Users are also told at
login time of previous logins so
that they may assess if another user
has been using their account.
The threat of spoofing from
another machine is mitigated by
the use of the Trusted Path. Users
are also told at login time of
previous logins so that they may
assess if another user has been
using their account.
O.Trained_Users
O.Admin_Trained
O.Access
O.Access_History
O.User_Authentication
O.Access_History
O.Trusted_Path
O.Audit_Gen_User
O.Discretionary_Access
This threat is mitigated through the O.Discretionary_User_C
use of MAC, MIC, DAC policy
ontrol
enforcement and audit traceability. O.Mandatory_Access
O.Mandatory_Integrity
This threat is mitigated through
audit traceability.
117
UNCLASSIFIED
O.Audit_Gen_User
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Policy/Threat/Assumption
T.User_Error
T.Trusted_User_Error
Justification
Objective
O.Audit_Gen_User
O.Trained_Users
This threat is mitigated through the O.Admin_Trained
enforcement of MAC, MIC, DAC
O.Discretionary_Access
policy; user and administrator
O.Discretionary_User_C
training; and policy and usage
ontrol
warnings and reminders on the
O.Display_Banners
system access banner.
O.Mandatory_Access
O.Mandatory_Integrity
The TOE must provide selfprotection features.
O.Self_Protection
Table 8-2 Tracing of Security Objectives to the TOE Security
Environment
Assumptions/Policies/Threats
A.Acc_to_Comms
A.Admin_Docs
A.Clearance
A.Competent_Admin
A.Coop_User
Justification
Physical security of communication
to TOE.
The TOE itself cannot govern
behavior of administrators.
The environment must provide
procedures for determining how
much “trust” (in terms of MAC and
MIC clearance, group membership,
XTS capabilities, and access to
console), and which needs-to-know,
to place on each system user.
The TOE itself can not determine
whether administrators are
competent. This objective includes
selection of competent
administrators.
The TOE itself can not determine
whether users will be cooperative.
This objective includes procedures
for selecting, training, and
monitoring cooperative users.
118
UNCLASSIFIED
Objectives
OE.Physical
OE.Admin
OE.Clearance
OE.Admin
OE.User
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Assumptions/Policies/Threats
A.Dispose_User_Data
A.Handling_of_Data
A.No_Abuse_By_Admin
A.No_Trusted_Network
A.Password_Management
A.Peer
A.Phys_Acs_to_Out
A.Physical
A.Protect_From_Out
Justification
The TOE itself can not ensure that
administrators follow procedures.
This objective includes selection,
training, and monitoring of
competent administrators and one of
the functions of an administrator is
to properly dispose of user data.
The site is assumed to have
procedures for how sensitive,
classified, and high-integrity data
and secrets are to be handled when
they are in possession of an
authorized user. The site is also
assumed to have procedures for pickup and distribution of hardcopy
output at multi-user or multi-level
printers.
The TOE itself can not prevent an
administrator from abusing his or her
authority. This objective includes
selection, training, and monitoring of
competent administrators.
The TOE itself can not determine
what kinds of information other
systems on the network transmit.
The TOE itself can not ensure that
administrators follow procedures.
This objective includes selection,
training, and monitoring of
competent administrators. Training
of administrators includes ensuring
that they read and understand the
TFM, which includes instructions on
password management.
The TOE itself can not determine the
kinds of information placed on the
network by other systems.
The TOE is assumed to have
adequate physical security protection
The TOE is assumed to have
adequate physical security protection
The TOE is assumed to have
adequate physical security protection
119
UNCLASSIFIED
Objectives
OE.Admin
OE.Handling_of_Data
OE.Admin
OE.Network_Mgmt
OE.Admin
OE.Network_Mgmt
OE.Physical
OE.Physical
OE.Physical
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Assumptions/Policies/Threats
A.Review_Audit_Log
A.Secure_Term
A.Sensitivity
A.Trusted_User
P.Physical_Control
T.Hack_Phys
Justification
The TOE itself can not ensure that
administrators follow procedures.
This objective includes selection,
training, and monitoring of
competent administrators. Training
of administrators includes ensuring
that they read and understand the
TFM, which includes instructions on
using the auditing mechanism.
The TOE itself can not govern user
behavior and can not control the
local storage of any arbitrary
terminal. This objective includes
procedures for selecting terminals
that meet the assumptions of the
TOE, documenting for users how to
securely use the terminals, and
training the users.
The TOE itself can not determine the
proper security attributes of imported
data. This objective includes
procedures for specifying a
consistent sensitivity labeling
scheme, for determining the correct
sensitivity of information, for
determining the allowed clearance of
users, and for handling of sensitive
material.
The TOE itself can not govern the
behavior of users. This objective
includes procedures for selecting
competent and trustworthy users,
training the users, determining the
appropriate clearance and allowed
capabilities for each user, and
monitoring the users.
The TOE is assumed to have
adequate physical security protection
This threat is mitigated by physical
security.
120
UNCLASSIFIED
Objectives
OE.Admin
OE.Secure_Term
OE.Sensitivity
OE.User
OE.Physical
OE.Physical
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
8.2 Security Requirements Rationale
8.2.1 Functional Security Requirements Rationale
Table 8-3 Functional and Assurance Component to Security Objective
Mapping
Objectives
Justification
The administrative roles are
limited by identification and
authentication, MAC, MIC and
DAC privileges, and audit
traceability.
O.AC_Admin_Limit
O.Audit_Gen_User
O.Access
O.Access_History
A requirement for a
comprehensive audit capability
meets this objective.
Authorized access is ensured
through the use of
identification and
authentication of users, and
control of user privileges.
This requirement’s definition
specifically meet’s this
objective.
121
UNCLASSIFIED
Requirements
FAU_GEN.1,
FAU_GEN.2,
FAU_SAR.1, FAU_SAR.2,
FAU_SAR.3, FAU_SEL.1NIAP-0407, FAU_STG.2NIAP-0422, FAU_STG.4,
FDP_IFC.2, FDP_IFF.2NIAP-0417, FDP_RIP.2,
FIA_AFL.1-NIAP-0425,
FIA_ATD.1, FIA_SOS.1,
FIA_UAU.2, FIA_UAU.4,
FIA_UAU.7
FAU_GEN.1,
FAU_GEN.2, FAU_SAA.1
FAU_SAA.1, FIA_AFL.1NIAP-0425, FIA_ATD.1,
FIA_SOS.1, FIA_UAU.2,
FIA_UAU.4, FIA_UAU.7,
FIA_USB.1-NIAP-0415
FTA_TAH.1
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Objectives
O.Admin_Role
O.Admin_Trained
O.Audit_Generation
O.Audit_Protection
O.Audit_Review
O.Authorities
O.Config_Mgmt
Justification
This objective is accomplished
through identification and
authentication of administrator,
and by limiting administrative
functions to highly privileged
administrator(s).
The TOE developer will
provide adequate
documentation to ensure secure
management by the
administrator(s).
A requirement for a
comprehensive audit capability
meets this objective. The
reliable time stamp mechanism
is used to place accurate time
stamps on audit records.
These requirements specify
audit data protection.
These requirements specify that
the administrator will have
audit capability and tools to
query audit data.
The TOE developer will have a
flaw remediation process in
place.
This assurance requirement
specifically details
configuration management
requirements for the TOE.
122
UNCLASSIFIED
Requirements
FAU_SEL.1-NIAP-0407,
FAU_STG.2-NIAP-0422,
FDP_IFC.2, FIA_AFL.1NIAP-0425, FIA_ATD.1,
FIA_SOS.1, FIA_UAU.2,
FIA_UAU.4, FIA_UAU.7,
FIA_UID.2, FMT_MOF.1,
FMT_MSA.1,
FMT_MTD.1,
FMT_MTD.2,
FMT_SMR.1,
FMT_SMR.3
AGD_ADM.1
FAU_GEN.1,
FAU_GEN.2, FPT_STM.1
FAU_STG.2-NIAP-0422,
FAU_STG.3, FAU_STG.4
FAU_SAA.1,
FAU_SAR.1, FAU_SAR.2,
FAU_SAR.3
ALC_FLR.3
ACM_AUT.1,
ACM_CAP.4,
ACM_SCP.3
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Objectives
Justification
These requirements specifically
delineate TOE responsibilities
O.Discretionary_Access
regarding discretionary access
controls (DAC).
These requirements specifically
O.Discretionary_User_Co delineate TOE responsibilities
ntrol
regarding discretionary access
controls (DAC).
This requirement is to provide
O.Display_Banners
banner displays in accordance
with the objective.
This assurance requirement
specifically details
O.Install
documentation required for
installation activities.
These security requirements
detail all of the functions
required to allow the
administrator to properly
manage the security of the
O.Manage
TOE.
O.Mandatory_Access
O.Mandatory_Integrity
O.Markings
O.Protect
These requirements detail the
mandatory access control
requirements of the TSF.
These requirements detail the
mandatory integrity control
requirements of the TSF.
This requirement details the
printer output labeling
requirements of the TOE.
Data and resources are
protected by the enforcement
of MAC, MIC, DAC policies.
123
UNCLASSIFIED
Requirements
FDP_ACC.2, FDP_ACF.1NIAP-0407, FDP_ETC.1,
FDP_ITC.1, FDP_ITC.2NIAP-0407
FDP_ACC.2, FDP_ACF.1NIAP-0407
FTA_TAB.1
ADO_IGS.1
FMT_MOF.1,
FMT_MSA.1,
FMT_MSA.2,
FMT_MSA.3-NIAP-0409,
FMT_MTD.1,
FMT_MTD.2,
FMT_REV.1,
FMT_SAE.1,
FMT_SMF.1,
FMT_SMR.1,
FMT_SMR.3
FDP_ETC.1, FDP_IFC.2,
FDP_IFF.2-NIAP-0417,
FDP_ITC.1, FDP_ITC.2NIAP-0407
FDP_IFC.2, FDP_IFF.2NIAP-0417
FDP_ETC.2
FDP_ACC.2, FDP_ACF.1NIAP-0407, FDP_IFC.2,
FDP_IFF.2-NIAP-0417
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Objectives
O.Recovery
O.Residual_Information
O.Self_Protection
O.Sound_Design
O.Sound_Implementation
O.Testing
O.Trained_Users
O.Trusted_Path
O.Trusted_System_Opera
tion
Justification
The TOE shall have the
functionality to allow for
recovery after a system
malfunction.
The TOE shall prevent users or
processes from accessing
residual information upon
reallocation of resources.
These requirements relate to
maintenance of separate
domains for the TSF and nonTSF entities and for testing to
ensure that the TSF
mechanisms are still working.
This assurance requirement
details the requirements of the
TOE design to ensure that the
security objectives are met.
This assurance requirement
details the requirement of the
TOE Implementation to ensure
that the security objectives are
met.
This assurance requirements
details the requirement of
independent testing that
ensures that the function
requirements have been met.
The TOE developer will
provide adequate
documentation to ensure secure
operation by users.
The TOE will be required to
provide a trusted path to remote
and local users.
The TOE must ensure TSF is
not bypassed.
124
UNCLASSIFIED
Requirements
FPT_RCV.2-NIAP-406
FDP_RIP.2
FPT_AMT.1, FPT_SEP.1,
FPT_TST.1, FTA_SSL.3
ADV_HLD.3
ADV_IMP.2, ALC_FLR.3
ATE_COV.2, ATE_DPT.2,
ATE_FUN.1, ATE_IND.3,
AVA_VLA.3
AGD_USR.1
FTP_TRP.1
FPT_RVM.1,
FPT_SEP.1
FPT_STM.1
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Objectives
O.User_Authentication
O.User_Identification
O.Vulnerability_Analysis
Justification
The TOE shall require users to
be authenticated before any
access to TSF mediated
actions.
The TOE shall require users to
be identified before any access
to TSF mediated actions.
The TOE shall undergo a
comprehensive vulnerability
analysis as described in these
assurance requirements.
OE.Physical
OE.Clearance
OE.Handling_of_Data
OE.Sensitivity
Requirements
FIA_UAU.2, FIA_UAU.4,
FIA_UAU.7, FAU_SAA.1
FIA_UID.2
AVA_CCA.1†,
AVA_MSU.2,
AVA_SOF.1,
AVA_VLA.3
environment
environment
environment
environment
8.2.2 Assurance Security Requirements Rationale
EAL3 is required by the LSPP. EAL5+ level of assurance was chosen for this ST because
the product is intended to be used in hostile environment while protecting very sensitive
information. The product was also originally designed and evaluated to meet TCSEC B3
requirements. Though the B3 requirements did not encompass all EAL5 requirements,
they surpass EAL5 in some respects and it is important for the XTS-400 product to
distinguish itself from EAL4 products. EAL4 products are not required to be designed
with anywhere close to the same level of assurance of that is designed into the XTS-400.
Finally, EAL5 meets or exceeds all “medium robustness” requirements, except for covert
channel analysis of cryptographic modules.
The only reason for the existence of the EAL4+ version of the product, which also
conforms to the LSPP, is to have a version of the product which is recognized
internationally.
The XTS is used in very sensitive environments and its customers want every ounce of
assurance they can get.
The following assurance requirements have augmented the basic EAL5 package:
ALC_FLR.3
ATE_IND.3
125
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Addition of ALC_FLR.3 was natural because BAE - IT already had flaw remediation
mechanisms in place, partly to satisfy the TCSEC RAMP requirements. Some newer PPs
are also requiring ALC_FLR. BAE - IT intends for the XTS product to enter an assurance
maintenance phase in the future.
Addition of ATE_IND.3 was natural because BAE - IT already has a security test suite
which is designed to be run in entirety by evaluators, partly due to TCSEC B3
requirements†.
Though the TOE could easily meet certain EAL6 requirements, significant additional
staff-hours (and lab costs) would be needed to meet some of the EAL6 documentation
and testing requirements. Time to market of the evaluated TOE would also be delayed if
an EAL6 evaluation were performed.
8.2.3 Rationale that IT Security Requirements are Internally Consistent
There are no requirements that conflict with one another. The MAC, MIC, and DAC
policies (see FDP_ACC.2, FDP_ACF.1-NIAP-0407, FDP_IFC.2, and FDP_IFF.2-NIAP0417) operate on an overlapping set of objects and operations, but their attributes are
overlapping and additive, and the rules and operations are orthogonal. ADV_SPM
provides formal modeling of these policies and AGD_USR provides user-level
documentation of these policies. Import and export of data, with or without security
attributes, (see FDP_ETC.1, FDP_ITC.1, FDP_ETC.2 and FDP_ITC.2-NIAP-0407) is
just a special case of these policies as applied to device objects.
All objects are also subject to the residual data mechanisms (see FDP_RIP.2). The
residual data mechanisms are orthogonal to the policy mechanisms.
The MAC policy mechanism involves covert channel reduction mechanisms†. These
mechanisms and the scenarios of actual channels are documented via AVA_CCA.1†.
The MIC policy mechanism underpins the role mechanism (see FMT_SMR.1). The role
mechanism does not modify the MIC policy attributes or rules.
Login processing brings in elements of many requirements, but all in a complementary
way. The login starts with an invocation of the trusted path mechanism (see FTP_TRP.1).
FIA_UID.2 wants the user identified before allowing any other operations and
FIA_UAU.2 wants the user authenticated before allowing any other operations. FIA_SOS
defines the strength of the authentication. FIA_UAU.7 requires that feedback from
authentication input be obscured and FTA_TAH requires a history of previous logins, but
this history does not have to include authentication values. FAU_SAA and FIA_AFL
require that the number of failed login attempts be recorded and limited. Initial MAC,
126
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
MIC, and DAC attributes are imparted on the user’s session according to FIA_USB.
FTA_TAB requires that a banner be displayable upon successful login.
Audit records generally contain a lot of detail (see FAU_GEN.1.2-NIAP-0347), but in
specific cases, that detail is not meaningful. The subject identity is not meaningful for an
authentication failure nor for records generated internally by the TSF (such as to show the
startup of the audit functions). FAU_SEL.1.1-NIAP-0407 generally requires that the
audit trail be searchable by subject identity, the naturally the aforementioned records
would not reliably show up in such a search. Passwords are not kept in login audit
records, but there is no requirement that they should be.
Audit records are generated for many events where other requirements are coming to
bear, such as login, policy check failures, and system recovery. The audit record
generation mechanism is orthogonal to these other mechanisms.
The management requirements (FMT_) are related to many of the mechanisms involved
with other requirements. In many cases, the other mechanisms will enforce the settings
made through management functions. Installation mechanisms (see ADO_IGS.1) rely on
management functions. The administrator guidance (see AGD_ADM) documents the
management functions.
Use of many of the management functions relies on a use of the trusted path mechanism.
127
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
8.3 Functional Requirements Grounding in Objectives
Table 8-4 Requirements to Objectives Mapping
Requirements
FAU_GEN.1
FAU_GEN.2
FAU_SAA.1
FAU_SAR.1
FAU_SAR.2
FAU_SAR.3
FAU_SEL.1-NIAP0407
FAU_STG.2-NIAP0422
FAU_STG.3
FAU_STG.4
Justification
The TSF shall be able to
generate audit events to
satisfy these objectives.
The TSF shall provide
detailed audit information to
accomplish these objectives.
The TSF shall detect an
accumulation of failed login
attempts to help satisfy these
objectives.
The TSF shall provide
specific high level audit
information to satisfy these
objectives.
Audit review shall be
restricted to designated
administrators.
Audit record querying
functions shall be made
available to the administrator.
The audit administrator shall
be able to select audit events.
The audit data shall be
protected and not accessible
by any user except the
designated administrator.
The audit trail shall be
protected from disk space
runout or hard crashes.
The audit trail shall be
protected by shutting down
the system when a
predetermined threshold has
been met.
128
UNCLASSIFIED
Objectives
O.AC_Admin_Limit,
O.Audit_Gen_User,
O.Audit_Generation
O.AC_Admin_Limit,
O.Audit_Gen_User,
O.Audit_Generation
O.Access,
O.Audit_Gen_User,
O.Audit_Review,
O.User_Authentication
O.AC_Admin_Limit,
O.Audit_Review
O.AC_Admin_Limit,
O.Audit_Review
O.AC_Admin_Limit,
O.Audit_Review
O.AC_Admin_Limit,
O.Admin_Role
O.AC_Admin_Limit,
O.Admin_Role,
O.Audit_Protection
O.Audit_Protection
O.AC_Admin_Limit,
O.Audit_Protection
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Requirements
FDP_ACC.2
FDP_ACF.1-NIAP0407
FDP_ETC.1
FDP_ETC.2
FDP_IFC.2
FDP_IFF.2-NIAP0417
FDP_ITC.1
FDP_ITC.2-NIAP0407
FDP_RIP.2
FIA_AFL.1-NIAP0425
FIA_ATD.1
Justification
Discretionary Access Control
Policy shall be enforced by
the TSF.
Discretionary Access Control
policy shall be enforced by
the TSF.
Discretionary and Mandatory
access control shall
encompass export of data.
Printer output shall be labeled
with sensitivity information.
The TSF shall enforce MAC,
MIC policy.
The MAC and MIC policies
have a well-defined set of
attributes and rules. Even
administrators must work
within these rules, except
where specific trusted
commands allow specific
kinds of exemptions.
Discretionary and Mandatory
access control shall
encompass import of data.
Discretionary and Mandatory
access control shall
encompass import of data.
The TSF shall prevent access
of residual information after
reallocation of resources.
Only authorized users and
administrators will have
access to the TSF.
The TSF shall maintain the
list of user security attributes.
129
UNCLASSIFIED
Objectives
O.Discretionary_Access,
O.Discretionary_User_Control,
O.Protect
O.Discretionary_Access,
O.Discretionary_User_Control,
O.Protect
O.Discretionary_Access,
O.Mandatory_Access
O.Markings
O.AC_Admin_Limit,
O.Admin_Role,
O.Mandatory_Access,
O.Mandatory_Integrity,
O.Protect
O.AC_Admin_Limit,
O.Mandatory_Access,
O.Mandatory_Integrity,
O.Protect
O.Discretionary_Access,
O.Mandatory_Access
O.Discretionary_Access,
O.Mandatory_Access
O.AC_Admin_Limit,
O.Residual_Information
O.AC_Admin_Limit, O.Access,
O.Admin_Role
O.AC_Admin_Limit, O.Access,
O.Admin_Role
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Requirements
FIA_SOS.1
FIA_UAU.2
FIA_UAU.4
FIA_UAU.7
FIA_UID.2
FIA_USB.1-NIAP0415
FMT_MOF.1
FMT_MSA.1
FMT_MSA.2
FMT_MSA.3-NIAP0409
FMT_MTD.1
Justification
The TSF shall enforce
minimum password lengths.
The TSF shall mediate no
actions prior to user
authentication.
This requirement further
reinforces FIA_UAU.2 to
meet these objectives.
This requirement further
reinforces FIA_UAU.2 to
meet these objectives.
The TSF shall take no action
before the user is identified.
The TSF shall allow a subject
no more privilege than the
user on behalf of whom the
subject is executing.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
130
UNCLASSIFIED
Objectives
O.AC_Admin_Limit, O.Access,
O.Admin_Role
O.AC_Admin_Limit, O.Access,
O.Admin_Role,
O.User_Authentication
O.AC_Admin_Limit, O.Access,
O.Admin_Role,
O.User_Authentication
O.AC_Admin_Limit, O.Access,
O.Admin_Role,
O.User_Authentication
O.Admin_Role,
O.User_Identification
O.Access
O.Admin_Role, O.Manage
O.Admin_Role, O.Manage
O.Manage
O.Manage
O.Admin_Role, O.Manage
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Requirements
FMT_MTD.2
FMT_REV.1
FMT_SAE.1
FMT_SMF.1
FMT_SMR.1
FMT_SMR.3
FPT_AMT.1
FPT_RCV.2-NIAP406
Justification
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TSF shall provide
functionality to ensure the
administrator can manage the
TOE security effectively.
The TOE shall have
functionality to be able to
ensure its security features are
operating correctly. Some of
the security features rely on
the hardware, regardless of
whether the hardware is part
of the TSF or part of the
abstract machine.
The TOE shall be able to be
manually recovered upon
system failure without
compromising security.
131
UNCLASSIFIED
Objectives
O.Admin_Role, O.Manage
O.Manage
O.Manage
O.Manage
O.Manage, O.Admin_Role
O.Manage, O.Admin_Role
O.Self_Protection
O.Recovery
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Requirements
FPT_RVM.1
FPT_SEP.1
FPT_STM.1
FPT_TST.1
FTA_SSL.3
FTA_TAB.1
FTA_TAH.1
FTP_TRP.1
Justification
The inability to bypass the
TSF is essential to trusted
system operations.
The ability to maintain data
separation is essential to
trusted system operations.
The ability to provide reliable
time stamps is essential to
trusted system operations and
the generation of audit data.
The TOE’s ability to test itself
ensures that it can protect its
own resources.
The requirement for
terminating an interactive
session after a designated time
of activity helps the TOE
protect its own resources.
This requirement fully meets
the intent of the objective to
have warning and advisory
messages to users.
The requirement fully meets
the intent of the objective to
have access history displayed
to users.
The TOE is required to be
able to establish a trusted path
between local and remote
users to the TSF.
132
UNCLASSIFIED
Objectives
O.Trusted_System_Operation
O.Trusted_System_Operation,
O.Self_Protection
O.Trusted_System_Operation,
O.Audit_Generation
O.Self_Protection
O.Self_Protection
O.Display_Banners
O.Access_History
O.Trusted_Path
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
8.4 PP Claims Rationale
This ST, although not written directly for the LSPP nor the CAPP, is in conformance
with it. The functional and assurance requirements in this ST go beyond what is required
by those PPs.
There are no other official PPs which are a good fit for the TOE. In particular, though the
TOE could meet assurance requirements in the “Medium Robustness” OS PP, significant
additional staff-time (and lab cost) would be required to meet the cryptographic
functional requirements in that PP. Those crypto requirements did not exist in the
TCSEC.
Because this ST is designed to support more functional and assurance requirements than
the LSPP, this ST has additional security objectives to those in the LSPP. Those
additional objectives can easily be seen by viewing the Security Objectives section of this
ST. A mapping of the LSPP objectives to objectives in this ST is shown below.
Table 8-5 LSPP Objectives to ST Objectives Mapping
LSPP Objectives
O.AUTHORIZATION
O.DISCRETIONARY_ACCESS
O.MANDATORY_ACCESS
O.AUDITING
O.RESIDUAL_INFORMATION
O.MANAGE
O.ENFORCEMENT
O.INSTALL
O.PHYSICAL
O.CREDEN
ST Objectives
O.Access
O.Discretionary_Access,
O.Discretionary_User_Control
O.Mandatory_Access
O.Audit_Gen_User, O.Audit_Generation,
O.Audit_Review
O.Residual_Information
O.Manage
O.Config_Mgmt, O.Sound_Design,
O.Sound_Implementation
O.Admin_Trained, O.Install, O.Manage,
O.Trained_Users, O.Trusted_System_Operation
OE.Physical
OE.Handling_of_Data
8.5 Strength-of-Function Rationale
As stated in section 6.3, there are some security functions based on probabilistic methods.
The strength of this TOE, SOF-high, surpasses what is required by the LSPP (SOF133
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
medium). A strength of SOF-high is consistent with protecting the TOE’s assets from
highly skilled and motivated attackers (A.Outsider_Hi). See section 5.4 for the objectives
that SOF supports.
The specific “strength” required of the methods used to provide difficult-to-guess
passwords is stated in FIA_SOS.1. That specific strength surpasses what is given in the
LSPP for the strength of the authentication mechanism. An analysis of the strength of that
mechanism, as required by AVA_SOF.1, follows.
For a worst-case calculation, we assume that the administrator has configured the
minimum password length to 6 characters and has not specified that mixed-case or nonalphabetic must be part of a valid password. That creates a password space of 26 to the
6th power, which equals 3.09e08. If we then assume that humans would tend to construct
passwords from only 1% of the password space, we are still left with a random guess
having only a 1 in 3,090,000 chance of matching a user’s actual password. The LSPP,
which is SOF-medium, requires only a 1 in 1e6 chance.
The LSPP also requires that there be only a 1 in 100,000 chance that multiple guesses
within a minute will succeed. The TOE allows only interactive logins. If we assume that
a human attacker could type quickly enough, including use of the secure attention key
and entering a different password each time, to make a login attempt every two seconds,
the chance of a match on a password guess within the minute would be1 in 103,000. Also
this makes the unlikely assumption that the administrator has set the allowed number of
failed login attempts to be greater than 30 – a more normal value would be 5.
In addition, the TOE implements the following aspects of the password mechanism that
are stronger than what is implemented by many other systems (and add strength beyond
the SOF-medium documented in the LSPP):
• An administrator can specify a minimum password length greater than 6 (and
up to 16);
• An administrator can specify that passwords contain mixed case;
• An administrator can specify that passwords contain at least one nonalphabetic character (the alphabet for passwords can be as large as 124
character, including non-printing characters);
• Only N incorrect passwords can be tried on an account before the terminal is
locked, where N has been configured by an administrator [this prevents
repeated guessing ad infinitum];
• the encrypted passwords can not be viewed by untrusted users nor programs
[therefore an attacker can not attempt to get passwords by cracking the
encryption];
• Passwords are not ever requested across dial-up lines or networks and are
never accepted by the TOE from such media/devices, and terminals and their
134
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
•
•
•
•
•
communication lines must be physically protected [therefore an attacker has
no opportunity to “sniff” passwords off communication lines];
Passwords are only ever requested or accepted after invocation of the trusted
path mechanism [therefore an attacker can not spoof a request for a
password];
An administrator can configure the mechanism such that the last N passwords
can not be reused;
Passwords can not be used after their life time, which has been set by an
administrator;
Passwords must be changed after their expiration time, which has been set by
an administrator;
An administrator can specify that passwords must be changed after the initial
login on an account.
The total protection and flexibility afforded by the features mentioned above qualifies the
strength of secrets mechanism (FIA_SOS, IDNAUT) as SOF-high.
8.6 Rationale for Inclusion of Hardware in the TOE
All required hardware/firmware components are included in the TOE because: the LSPP
suggests that a conformant TOE will include hardware; the hardware plays a role in
implementing the following SRFs: FDP_RIP.2, FPT_RVM.1, FPS_SEP.1, and
FPT_STM.1; and estimation of covert channel capacities† requires making measurements
on real hardware.
The following assumptions about the hardware/firmware base are made by the software:
I. The BIOS must:
a) Set hardware/firmware/microcode configuration settings as specified by
the operator (they are specified when the TOE is not executing);
b) Take control of the system when the system is physically powered up or
reset;
c) Run a set of hardware/firmware/microcode diagnostics during boot;
d) Transfer control to the TOE bootstrap loader, during boot, and then never
execute again, unless explicitly invoked by the TOE, until another boot
occurs;
e) Refrain from modifying the TOE bootstrap loader as it is copied from disk
to memory;
f) Refrain from modifying any content of any disk or tape attached to the
system.
II. Hardware_Domains:
The hardware will provide a privilege domain mechanism that allows software
135
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
executing in a privileged domain to be inaccessible to software executing in an
unprivileged domain and that allows privileged software to restrict access to I/O
instructions to privileged software. There will be at least two privilege levels.
Hardware descriptors will control which domains can access which areas in
physical memory and will control where unprivileged software can transfer into
privileged software. These descriptors will only be modifiable by hardwareprivileged software. Unprivileged software will have no way to disable or
circumvent the descriptors and will have no way to gain privilege, other than by
making controlled transfers to privileged software through the aforementioned
descriptors. Unprivileged software will also have no way to modify other
hardware descriptors, the mode of operation of the hardware, nor the control and
configuration registers or the hardware.
III. Hardware_Faults:
The hardware will provide a fault mechanism that allows privileged software to
be notified of an attempt by unprivileged software to access memory outside its
domain, beyond the limits of its own domain, never mapped, previously mapped,
or mapped read-only. The information provided during the fault will allow
privileged software to discern which case occurred and at what point in the
execution of the unprivileged software. The software invoked at the time of the
fault will be dictated by the settings in hardware descriptors. These hardware
descriptors will be modifiable only by privileged software and unprivileged
software will have no way to disable, circumvent, or corrupt the fault mechanism.
IV. Hardware_Integrity:
The hardware/firmware/microcode components that handle data must maintain
the integrity of that data and must maintain logical separation between separate
logical requests.
V. Hardware_Virtual_Mem:
The hardware must provide a virtual memory mechanism that allows the set of
physical “pages” accessible to the current execution thread to be limited to a
subset of all physical pages available to the current domain. The virtual-tophysical mapping will also allow certain areas to be marked read-only. The
virtual-to-physical mapping must be switchable only by hardware-privileged
software and unprivileged software must have no way to disable, circumvent, or
modify the mapping.
VI. Optional_HW:
Hardware components other than those listed in chapter 2 can be added on to an
XTS-400 system, but will be usable by the TOE and its users only if:
a) they are configured to answer to different I/O ports, memory addresses, and
SCSI IDs than the listed components;
136
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
b) they are not using any bus resources of the system;
c) they do not interrupt the CPU;
d) they do not communicate with any of the required and optional components.
VII. Restrict_HW_Feat:
The required and optional hardware/firmware/microcode is only allowed to
contain features (such as vendor-specific extensions) beyond the listed standards,
if one of the following:
a) The feature is inactive until explicitly invoked by software and is invoked
only by special, obvious I/O or SCSI commands; or
b) The feature is inactive until explicitly invoked by physical user intervention
and such user intervention is prevented by site physical or procedural controls;
or
c) The feature is disabled by the standard TOE configuration or by site-specific
procedures; or
d) Use of the feature does not: 1) allow display, retrieval or modification of
information from another process nor from a global resource; 2) consume a
global resource; 3) increase the performance of the system.
137
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
139
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
9 Appendix A – List of Subjects
9.1 Subjects
XTS-400, Version 6 supports only one type of subject: a process.11
9.1.1 Subject Attributes
For each subject, in addition to the current ring of execution, the system maintains the
following security-relevant information in the kernel Active Process Table:
•
The real user and group identifiers (IDs). This identifies the user and group
responsible for the subject.
•
The effective user and group IDs. This identifies the user and group on whose
behalf the subject is operating. It is the effective user and group IDs that are used
in the discretionary access checks.
•
The clearance (MAC and MIC) of the user on whose behalf the subject is
operating.
•
The Mandatory Access Control (MAC) label (i.e., sensitivity label) of the subject.
•
The Mandatory Integrity Control (MIC) label (i.e., integrity label) of the subject.
•
The effective privileges of the subject.
•
The maximum privileges of the subject.
9.1.2 Subject Creation and Destruction
Subjects can only be created by other subjects.22 At the TSF interface, subjects are
created via the xts_load_process and fork system calls. When xts_load_process,
is used, the TSF creates a new subject environment that executes within the TSF until the
TSF program loader relinquishes control. With xts_load_process, the new process
environment is determined solely by the attributes of the program file. If the program
being loaded has an integrity level greater than or equal to operator, the subject continues
to execute within the TSF when loading is complete (i.e., it is a “trusted” subject). If the
1
This definition is independent of the domain of execution of the process, which may
change during the process's lifetime (for example, as the process transitions between
hardware rings). In XTS-400, Version 6, as long as the process is active, it is a subject.
22
The first subject in the system (the system loader) is created by the bootstrap loader.
141
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
program is of an integrity level below operator, the subject executes outside the TSF
when loading is completed (i.e., it is an “untrusted” subject).
fork, the other subject creation path provided to untrusted code, creates a new subject
whose environment is identical to that of the parent subject. In this case, the new subject
executes within the TSF until fork terminates; execution then resumes at the same point
in parent and child. In all cases, the TSF interface provides trusted subjects with the
ability to create both trusted and untrusted subjects; however, it restricts untrusted
subjects to the creation of untrusted subjects. Subjects are destroyed by the
xts_release_process system call.
142
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
10 Appendix B – List of Objects
10.1 Information and Objects
Subjects provide no utility without information with which to work. This information is
organized as “objects”. Control over the interaction between subjects and objects is
defined by the system security policy, which has mandatory and discretionary
components. The discretionary controls are applicable only to the subset of objects that
can be named by users outside the TSF. Supplemental mechanisms within the system
provide finer control on the accessibility of information within objects, as well as
providing assurance that reuse of objects cannot result in information flow.
The following sections describe the objects of the TOE. For each type of object, a
description of the security-relevant characteristics of the object, as well as the methods of
object creation and destruction, are given. The objects to be discussed are: processes,
devices, semaphores, sockets,3 file system objects (files, directories, device special files,
symbolic links, and named First-In First-Outs (FIFOs)), and memory objects (shared
memory and unnamed pipes).
10.1.1 Semaphores
Semaphores, or more accurately semaphore sets, are used to coordinate access to
resources. A semaphore set consists of one or more individual semaphores. Unlike file
system objects and devices, semaphores are not included in the process address space.
Semaphore sets contain the following security-relevant characteristics:
3
•
The MAC label for the semaphore set, which cannot be changed once created.
•
The creator of the semaphore set (user and group identifiers). This is set to the
user and group identifiers of the process creating the semaphore set and, unlike
the owner, it cannot be changed.
•
The owner of the semaphore set (user and group identifiers).
•
The access control list for the semaphore set.
•
The ring identifier of the semaphore set (combined read/write).
Sockets are protected resources, not named objects as the other objects discussed are.
143
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
10.1.2 Processes
Processes differ from file system objects in that they are considered to be both active
subjects and storage objects. The storage object determination arises from the fact that (a)
processes may be the target of an interprocess communication (IPC) message, and (b)
processes contain accessible status information.
When viewed as an object, processes have the following security relevant characteristics:
•
The MAC label of the process
•
The effective owner of the process (user and group identifiers), for Discretionary
Access Control (DAC) purposes
•
The access control list for the process
10.1.3 Devices
Devices are classified as objects in XTS-400, Version 6 because (a) devices serve as
gateways for information, and, as such, may be viewed as abstract repositories of
information; and (b) devices contain accessible status information. They have the
following security-relevant characteristics:
•
The MAC label of the device. This MAC label is constrained by the MAC
label range associated with the system limits.
•
The effective owner of the device (user and group identifiers), for DAC
purposes
•
The access control list for the device
•
The device class (TRUSTED, USER, MOUNTED, and TERMINAL). The
TRUSTED class is used for disk logical devices that are to be used by trusted
services (e.g., check, fscheck, mkfsys). The USER class is used to specify
those devices to which untrusted programs are to have access. The
MOUNTED class is used to designate disk logical devices that are currently
mounted. The TERMINAL class is used to designate devices that are
configured for use as a terminal.
For disk devices, each partition has its own class (i.e., is a logical device). In order to
change the class, all use of the device must be terminated. It must be unmapped (if a
USER device) and have all file systems unmounted (if MOUNTED).
The kernel restricts device creation to subjects that possess an integrity level of
administrator or greater. The kernel allows sharing of devices; however, devices can only
be shared by processes running at the same MAC label as the device.
144
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Additional information about and the amount of free space available on a disk holding a
mounted kernel file system is returned if the user has MAC read access to the level of the
device.
10.1.4 Sockets
Sockets (network and Unix-domain) are classified as objects in XTS-400, Version 6
because they are channels through which data can flow out of and into a process. Sockets
are a little different than other TSF objects in the following ways: the object data may not
be stored on the system, there may be no static “name” for the container of the data, data
written cannot be read back, and specific “records” cannot be read. Instead, the object
data is a dynamic set of packets to which there is no beginning, ending, or maximum size.
The name of a network socket is also dynamic in that it can change according to what the
sending and receiving processes agree upon. Like pseudo-terminals and unnamed pipes,
sockets cease to exist one all processes have closed them.
The MAC and MIC label of the socket is set to the level of the creating process. For
network sockets, this will be equal to the MAC and MIC label of the Ethernet device and
of the TCP/IP daemon process (identical). If the Ethernet device were to change MAC
levels, the socket would cease to operate. Sockets can only be used by processes at the
same level, even if the processes are privileged.
DAC policy is not applied to sockets. Each socket can bind to a local port or identifier
suitable for the protocol that is being used. TCP and UDP ports that are less than 1024 are
considered privileged ports and can only be bound by the owner of the TCP/IP daemon.
The TSF ensures that only the creator of a socket can attach to a socket. The creating
process must be at the same MAC label as the socket or Ethernet device.
10.1.5 File System Objects
File System objects are the basic information repository in the XTS-400, Version 6
system. File System objects possess the following security-relevant characteristics:
•
The MAC and MIC label for the object.
•
The owner of the object (user and group identifiers).
•
The permissions and access control list for the object. This space is allocated
by the kernel as part of the object for use by the DAC enforcement
mechanisms in TSS.
•
XTS-400, Version 6 uses file system objects to create a hierarchically
structured file system. There are six types of file system objects: files,
directories, device special files, symbolic links, Unix-domain sockets, and
named FIFOs (pipes).
145
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
10.1.5.1 Files
The most common type of file system object in XTS-400, Version 6 is the regular file.
The file header for an executable file also contains the following additional securityrelevant information:
•
The maximum authorized privilege set to be used
•
The minimum integrity label required to execute the file.
10.1.5.2 Directories
A directory is a special type of file system object that is used to construct a hierarchical
file system. The file system code in TSS enforces the restriction that, within a file system
hierarchy, the mandatory level of a directory must be dominated by the mandatory level
of each object in the directory.
The file system also supports a special type of directory called a deflection directory.
This type of directory automatically redirects unprivileged users4 into the appropriate
hidden single level subdirectory.
10.1.5.3 Device Special Files
Device special files serve as the way that devices are designated through the file system.
A device special file has a fixed structure: it is a UNIX-style major/minor number that is
mapped by TSS into a device-unique ID for the actual device.
TSS does not allow a subject any direct access to a device special file. The only way to
obtain information from a device special file is via the stat structure, which contains the
major/minor numbers. It is up to untrusted software to map these major/minor numbers to
device-unique IDs. Only when the actual device is opened via xts_open_device or
open are checks made. The checks are based on information on the device, not on the
device special file.
10.1.5.4 Named FIFOs
Named FIFOs provide a method to support the UNIX “named pipe” concept. They
provide a permanent “First-In First-Out” communication path between multiple
processes, at the request of the processes, within the bounds of the system security policy.
Named FIFOs support multiple readers and multiple writer; locks are used to serialize
access. DAC is enforced through the same mechanisms used for files.
10.1.5.5 Unix-Domain Socket File System Objects
Unix-Domain socket file system objects are simply a handle for getting to Unix-domain
sockets (mentioned above). They are created by a “bind” operation and must be explicitly
4
Users running at an integrity level above OSS can optionally bypass the deflection.
146
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
removed from the system when no longer wanted (i.e., they are not implicitly removed
when all processes close the socket). Their security attributes can be changed, but a
process attempting a “connect” must be at the level of the socket (and may need privilege
to access the file system object). DAC policy is enforced during “connect” requests.
Normal opens are not allowed against this kind of file system object.
10.1.5.6 Symbolic Links
Symbolic links appear as names in the file system, but simply “point” at another file
system object. When an application performs a normal file system operation on a
symbolic link, the operation is actually performed on the target of the link. If a symbolic
link appears in a pathname, the target of the link is used in the path. There are special
system calls to read the content, or get the status, of a symbolic link. Unlike “hard” links,
the target object can be on another file system, can be downgraded with respect to the
link, or can be non-existent.
10.1.6 Memory Objects
Memory objects do not have a presence in the file system and are not persistent across
system re-boots. They exist solely in system memory, except when portions of them may
be swapped to disk. The TSF Kernel implements an internal memory object with full
MAC, MIC, and DAC attributes, but this object is not directly visible outside the TSF.
However shared memory and unnamed pipe objects are visible outside the TSF and are
built on top of the internal, Kernel memory objects.
10.1.6.1 Shared Memory
Shared memory objects follow the Unix System V shared memory model. They can be
shared between processes with a key or ID, or they can be private to the creating process.
They persist until the system shuts down or until they are explicitly removed by the
creator or owner. Shared memory is “mapped” into the address space of a process. The
MAC and MIC level of shared memory objects can not be changed and is set to the level
of the creating process by default.
10.1.6.2 Unnamed Pipes
Unnamed pipes serve as a data transfer conduit between processes. They have no interprocess “handle” and can only be shared between predecessor and ancestor in a “fork”
relationship. An unnamed pipe ceases to exist as soon as the last process using it either
closes the pipe or exits. Pipes are at the MAC and MIC level of the creating process and
this level can not be changed. The DAC policy applied to pipes is that it is readable and
writeable by the owner only.
147
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
11 Appendix C – TSF Commands
Command
audit(1T)
check(1T)
dev_edit(1T)
ctl(1T)
daemon_edit(1T)
dump(1T)
frestore(1T)
Security Requirement
audit is restricted to users whose current integrity level is at
least operator and whose current security level is at the system
maximum. Furthermore, to execute the display or remove
functions, the user’s current level must be the system
maximum security level and at least the administrator integrity
level.
check is restricted to users whose session integrity level is at
least operator.
The user must be at the same security and integrity level as the
logical device containing the file system to be checked. The
user also must be at or above the maximum security level of
the file system.
The user must be at the system minimum security level and
maximum integrity level.
ctl is restricted to users whose current integrity level is at least
administrator.
The user must be at the system minimum security and
maximum integrity levels.
dump is restricted to users whose current integrity level is at
least operator.
The user must also possess the shutdown_allowed capability,
as defined in the User Access Authentication database.
frestore is restricted to users whose current integrity level is at
least operator.
The user must be at the same security and integrity level as the
save device, and at or above the maximum security level of the
file system objects on the save media. fsave records the
maximum potential security level of the file system objects on
the save media. This level is determined by the level of the
user.
frestore will not restore an existing object if it has a higher
integrity level than the user.
149
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Command
fsave(1T)
Security Requirement
fsave is restricted to users whose current integrity level is at
least operator.
The user must be at the same security and integrity level as the
save device, and at or above the security level of the objects
being saved. fsave records the maximum potential security
level of the file system objects on the save media. This level is
determined by the level of the user.
fscheck(1T)
fstab_edit(1T)
ga_edit(1T)
install(1T)
mkfsys(1T)
In the case of saving to removable media, the operator must
attach an external label to the save media indicating the
sensitivity of the saved information. In the case of a multivolume save, the operator should appropriately label all
volumes and include sequence numbers in the labels.
fscheck is restricted to users whose current integrity level is at
least operator.
The user must be at the same security and integrity level as the
logical device containing the file system. The user also must be
at or above the maximum security level of the file system.
Can only be used by an operator or administrator.
The user must be at the system maximum security and
maximum integrity level.
install is restricted to users whose integrity is at least
administrator. The user must be at the same security and
integrity level as the install device and at or above the max
security level of the file system objects on the release media.
Install will not set the discretionary access information of an
existing object, except subtype. Install will set the mandatory
access information of an existing object if it differs from that
found on the release media.
mkfsys is restricted to users whose current integrity level is at
least operator.
The user must be at the same security and integrity level as the
logical device on which the file system is being created, and at
or above the maximum security level of the file system.
150
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Command
mount(1T)
partition_edit(1T)
param_edit(1T)
pq_edit(1T)
proc_edit(1T)
sda(1T)
sdc(1T)
shutdown(1T)
sm_edit(1T)
st(1T)
start_daemon(1T)
startup(1T)
stop_daemon(1T)
Security Requirement
mount is restricted to users whose current integrity level is at
least operator.
The user’s current security level must be at or above that of the
device and of the file system minimum security level.
The user must be at the system minimum security and
maximum integrity level.
The user must be at the system minimum security and
maximum integrity level.
pq_edit is restricted to users whose current integrity level is at
least operator and whose current security level is at system
maximum.
The user must be at the system maximum integrity level. In
addition, if the user’s security level is below the system
maximum, only processes with the same or lower security
classification and the same categories or a subset of those
categories will be visible.
sda is restricted to users whose current integrity level is at least
operator.
The user must be at or above the (old) security level of the
logical device.
sdc is restricted to users whose current integrity level is at least
operator.
The user must be at or above the security level of the logical
device.
shutdown is restricted to users whose current integrity level is
at least operator.
To use this command, the user must possess the
shutdown_allowed capability, as defined in the User Access
Authentication database.
The user must be at the system minimum security and
maximum integrity level.
st is restricted to users whose current integrity level is at least
operator.
The user must be at least operator integrity.
startup is restricted to users whose current integrity level is at
least operator.
The user must be at least operator integrity.
151
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Command
tcpip_edit(1T)
tdc(1T)
ua_edit(1T)
unmount(1T)
Security Requirement
The user must be at the system minimum security level and
maximum integrity level.
tdc is restricted to users whose integrity is at least operator.
The user must be at the same security and integrity level as the
specified device.
The user must be at the system maximum security and
maximum integrity level.
unmount is restricted to users whose current integrity level is
at least operator.
The user’s current security level must be at or above that of the
device and of the file system minimum security level.
152
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Command
tp_edit(1T)
Security Requirement
The user must be at the system maximum integrity level. The
user must also be at the same or higher security level as any
input file (for the add and change requests). For the display
request, the user must be at the same or higher security level as
the requested program file to display its attributes. For the
change request, the user must be at the same or higher security
level as the requested program file to change its attributes.
Warning: Only untrusted programs may be installed without
modifying the TCB and affecting any rating that has been
applied to the system by the National Computer Security
Center. See Installing OSS Domain Programs in Chapter 1 of
the Trusted Programmer’s Reference Manual.
Warning: Modifying or removing STOP programs in the
/trusted directory or the /system directory could affect any
rating that has been applied to the system by the National
Computer Security Center.
Warning: Modifying or removing STOP programs in the
/trusted directory or the /system directory can result in
making the system unusable.
The following special privileges are supported:
set_level The ability to modify the mandatory security
attributes of an object (security and integrity level).
upgrade_level
The ability to upgrade the mandatory
security attributes of an object (security and integrity level).
set_discretionary_access The ability to modify the
discretionary security attributes of an object (access control
information).
set_owner_group The ability to change the owner and group
associated with an object (for processes, the ability to change
the real owner/group identifiers).
set_process_attributes
The ability to change restricted
status information on a process (i.e., clearance level and
process family identifier).
set_subtype_access The ability to modify the object subtypes
to which a process has access.
terminal_lock
The ability to lock and unlock terminals.
device_control_exempt
The ability to obtain control
access to a device (i.e., the ability to issue privileged control
functions).
simple_security_exempt The ability to bypass the simple
security property check (i.e., allows read up).
security_star_property_exempt
The ability to bypass the
153
*-property
security check (i.e., allows write down).
UNCLASSIFIED
simple_integrity_exempt The ability to bypass the simple
integrity property check (i.e., allows read down).
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
12 Appendix D – User Commands
Command
ccp(1T)
cdl(1T)
chd(1T)
cup(1T)
df(1T)
disconnect(1T)
Security Requirement
The ccp command requires that the user have the run_allowed
capability, as defined in the User Access Authentication
database.
The cdl requires that the user have the sl_allowed capability,
as defined in the Access Authentication database.
none
The cup command requires that the user have the cup_allowed
capability, as defined in the Access Authentication database.
The df command only displays information on mounted file
systems whose maximum security level is less than or equal to
the user’s current security level.
The disconnect command requires that the user have the
disconnect_allowed capability, as defined in the User Access
Authentication database.
154
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Command
fsm(1T)
Security Requirement
For the following discussion, the following permissions are
defined, depending on the current integrity level of the
requester:
USER PERMISSIONS
READ
The requester must be at the same security level or
higher and at the same integrity level or lower as the
object and must have discretionary read permissions
to the object.
WRITE
The requester must be at the same security level and
integrity level as the object and must have
discretionary write permissions to the object.
MODIFY The requester must be at the same security level and
at the same integrity level as the containing directory
and must have discretionary write and search
permissions to the containing directory.
OPERATOR PERMISSIONS
READ
The requester must be at the same security level or
higher as the object and must have discretionary read
permission to the object.
WRITE
The requester must be at the same security level and
at the same or higher integrity level as the object and
must have discretionary write permissions to the
object.
MODIFY The requester must be at the same security level and
at the same or higher integrity level as the containing
directory and must have discretionary write and
search permissions to the containing directory.
ADMINISTRATOR PERMISSIONS
READ
The requester must be at the same security level or
higher as the object.
WRITE
The requester must be at the same security level and
at the same or higher integrity level as the object.
MODIFY The requester must be at the same security level and
at the same or higher integrity level as the containing
directory.
For the change and delete requests, the user must be at the
same security level and integrity level as the requested object.
In addition, 155
the user must be the owner of the object or be
executing
as an administrator. An operator or an administrator
UNCLASSIFIED
may be at a higher integrity level than the requested object.
With regard to the change request, only an administrator can
turn on the set-user-id and set-group-id bits in the discretionary
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Command
ikill(1T)
kill(1T)
logout(1T)
reattach(1T)
run(1T)
session(1T)
sg(1T)
sl(1T)
sit(1T)
system(1T)
Security Requirement
The ikill command requires that the user have the kill_allowed
capability, as defined in the Access Authentication database.
The kill command requires that the user have the kill_allowed
capability, as defined in the Access Authentication database.
none
The user’s current access level and group must be the same as
when the process family was started with the run(1T)
command.
The run command requires that the user have the run_allowed
capability, as defined in the User Access Authentication
database.
The run command requires that the current integrity
classification be 3 or lower. In addition, the CASS environment
requires that the user have no integrity categories enabled.
none
The sg command requires that the user have the sg_allowed
capability, as defined in the Access Authentication database.
The sl command requires that the user have the
set_level_allowed capability, as defined in the Access Authentication database.
If new TSF file integrity checksums are to be generated, the
user’s integrity level must be at least “admin”.
none
156
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
13 Appendix E – Auditable Events
What follows are the kinds of events that must be audited in order to meet the “basic”
level of auditing, given the functional requirements included in the TOE.
Requirement
Audit Data Generation (FAU_GEN.1)
Audit events prompted by requirement
login/logout, start up/shutdown, requests to
change user security attributes
User Identity Association (FAU_GEN.2)
login/logout
Audit Review (FAU_SAR.1)
Reading of information from the audit
records (which can be attained by
auditing any open of an audit file).
Potential Violation Analysis (FAU_SAA.1) Unsuccessful login attempts.
Restricted Audit Review (FAU_SAR.2)
Unsuccessful attempts to read information
from the audit records (which can be
attained by auditing failed attempts to
open an audit file for read).
Selectable Audit Review (FAU_SAR.3)
(none)
Selective Audit (FAU_SEL.1-NIAP-0407) All modifications to the audit configuration
that occur while the audit collection
functions are operating.
Guarantees of Audit Data Availability
(none)
(FAU_STG.2-NIAP-0422)
Action in Case of Possible Audit Data Loss Actions taken due to exceeding a thresh(FAU_STG.3)
hold.
Prevention of Audit Data Loss
Actions taken due to the audit storage
(FAU_STG.4)
failure.
Complete Access Control (FDP_ACC.2)
(none)
Access Control Functions
All requests to perform an operation on an
(FDP_ACF.1-NIAP-0407)
object covered by the SFP.
Export of User Data Without Security
All attempts to export information (which
Attributes (FDP_ETC.1)
can be attained by auditing the open of
any device and the running of the trusted
mount, unmount, and fsave commands).
Export of User Data With Security
All attempts to export information and to
Attributes (FDP_ETC.2)
override human-readable output marking
(which can be attained by auditing the open
of any device, the request to override
markings, and the running of the trusted
mount, unmount, and fsave commands).
157
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Requirement
Complete Information flow control (for
Mandatory Access Control Policy)
(FDP_IFC.2(1))
Complete Information flow control (for
Mandatory Integrity Control Policy)
(FDP_IFC.2(2))
Hierarchical Security Attributes (for
Mandatory Access Control) (FDP_IFF.2NIAP-0417(1))
Hierarchical Security Attributes (for
Mandatory Integrity Control) (FDP_IFF.2NIAP-0417(2)
Import of User Data Without Security
Attributes (FDP_ITC.1)
Import of User Data With Security
Attributes (FDP_ITC.2-NIAP-0407)
Subset Residual Information Protection
(FDP_RIP.1)
Full Residual Information Protection
(FDP_RIP.2)
Authentication Failure Handling
(FIA_AFL.1-NIAP-0425)
User Attribute Definition (FIA_ATD.1)
Verification of Secrets (FIA_SOS.1)
User Authentication Before Any Action
(FIA_UAU.2)
Single-use Authentication Mechanisms
(FIA_UAU.4)
Protected Authentication Feedback
(FIA_UAU.7)
User identification before any action
(FIA_UID.2)
Audit events prompted by requirement
(none)
(none)
All decisions on requests for information
flow.
All decisions on requests for information
flow.
All attempts to import user data, including
any security attributes (which can be
attained by auditing the open of any
device and the running of the trusted
mount, unmount, and frestore
commands).
All attempts to import user data, including
any security attributes.
(none)
(none)
Reaching of the threshold of allowed login
attempts and attempts to restore system
to ready state.
(none)
Rejection or acceptance by the TSF of any
tested secret.
All use of the authentication mechanism.
Attempts to reuse authentication details.
(none)
All use of the user identification
mechanism, including the identity
provided during successful attempts.
158
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Requirement
User-subject binding (FIA_USB.2-NIAP0415)
Management of Security Functions
Behavior (FMT_MOF.1)
Management of Security Attributes
(FMT_MSA.1)
Static Attributes Initialization
(FMT_MSA.3-NIAP-0409)
Management of TSF Data (FMT_MTD.1)
Management of Limits on TSF Data
(FMT_MTD.2)
Revocation (to authorized
administrators)(FMT_REV.1(1))
Audit events prompted by requirement
Success and failure of binding user security
attributes to a subject (e.g., success and
failure to create a subject). [This can be
attained by auditing successful and
failing login attempts, since the TOE
will reject the login if a subject can not
properly be created.]
All modifications in the behavior of the
functions in the TSF.
All modifications of the values of security
attributes.
Modifications of the default setting of
permissive or restrictive rules.
All modifications of the initial values of
security attributes.
All modifications of the values of TSF
data, including audit data.
All modifications to the limits on TSF data
and actions to be taken in case of
violation of the limits.
All attempts to revoke security attributes
and all modifications to the values of
TSF data (this can be attained by
auditing the use of trusted commands,
auditing modification actions performed
within trusted commands, and auditing
security attribute changes to objects).
All attempts to revoke security attributes.
Revocation (to owners and authorized
administrators) (FMT_REV.1(2))
Time-Limited Authorization (FMT_SAE.1) Specification of the expiration time for an
attribute.
Action taken due to attribute expiration.
Management Operations (FMT_SMF.1)
Execution of operator and administrator
commands. Additional auditing of
trusted editor operations.
159
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
Requirement
Security Roles (FMT_SMR.1)
Assuming Roles (FMT_SMR.3)
Abstract Machine Testing (FPT_AMT.1)
Recovery from Failure (FPT_RCV.2NIAP-406)
Non-Bypassability of the TSF
(FPT_RVM.1)
TSF Domain Separation (FPT_SEP.1)
Reliable Time Stamps (FPT_STM.1)
TSF Testing (FPT_TST.1)
TSF-Initiated Termination
(FTA_SSL.3)
Default TOE Access Banners
(FTA_TAB.1)
TOE Access History (FTA_TAH.1)
Trusted Path (FTP_TRP.1)
Audit events prompted by requirement
Modifications to the group of users that are
part of a role and every use of the rights
of a role (this can be attained by auditing
“edits” performed by the trusted ua_edit
command and by auditing use of every
trusted command).
Explicit requests to assume a role.
Use of any function restricted to an
authorized administrator role (identified
in FMT_SMR.1).
Execution of the tests of the
hardware/firmware base and the results
of the tests. Note that this testing may be
part of TSF self-testing.
The fact that a failure or service
discontinuity occurred.
Resumption of the regular operation.
Type of failure or service discontinuity.
(none)
(none)
Changes to the time.
Execution of the TSF self tests and the
results of the tests.
Locking of an interactive session by the
session locking mechanism.
(none)
(none)
All attempted uses of the trusted path
functions.
Identification of the user associated with all
trusted path failures, if available.
160
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
14 Appendix F – Selectable Audit Events
What follows are the specific events that can be audited by the TOE. These are used to
satisfy the “basic” level of auditing requirements shown in appendix F, but go beyond
those requirements.
The TOE shall be able to audit the following events:
system change event
branch block runout
device access change
device creation
device deletion
device owner change
device close
IPC message sent
mount space runout
process creation
process deletion
process owner change
process real user change
process subtypes change
FS object subtypes change
device subtype violation
FS object subtype violation
shared memory unmap
semaphore access denial
shared memory DAC
program loader failed
FS object access change
FS object close
FS object creation
FS object deletion
FS object open
FS object remove link
socket bind failure
socket accept
socket sendto recvfrom
161
UNCLASSIFIED
file system access violation
data block runout
device access violation
device DAC violation
device open
device subtypes change
disk error
mount access violation
process access violation
process DAC violation
process fork
process privilege change
process space runout
FS object access violation
unmount busy file system
process subtype violation
shared memory map
semaphore object
semaphore access change
device class change
setuid program
FS object add link
FS object chdir
terminal lockout
FS object name change
FS object owner change
socket open close
socket connect
FIFO action
Internet inbound connect
failure
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
ICMP redirect
cdl command
cup command
fsm error
logout
print with no markings
shutdown command
st command
trusted editor request
sit command
crypto event
...
Audit Application event
admin command
ctl command
device start error
login
operator command
sg command
sl command
startup command
UPS status change
memory object runout
The min security / max integrity for auditing is the minimum security and
maximum integrity level of objects for which the following audit events will be
recorded:
device open
device close
IPC message sent
process creation
process deletion
socket open close
socket accept
process fork
FS object close
FS object creation
FS object deletion
FS object open
socket connect
socket sendto recvfrom
162
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
15 Appendix G - Acronyms
CASS
Commodity Application System Services
CC
Common Criteria
EAL
Evaluation Assurance Level
IT
Information Technology
OSS
Operating System Services
PP
Protection Profile
SF
Security Function
SFP
Security Function Policy
SOF
Strength of Function
ST
Security Target
TFM
Trusted Facility Manual
TOE
Target of Evaluation
TSC
TSF Scope of Control
TSF
TOE Security Functions
TSFI
TSF Interface
TSP
TOE Security Policy
TSS
TSF System Services
163
UNCLASSIFIED
BAE Systems Information Technology, LLC
Security Target Version 1.11
for
XTS-400 Version 6
December 2004
16 Appendix H – Functional
Requirements Required by Existing
XTS-400 Customers
The following functional requirements are not required by the PPs to which the TOE is
conforming, but are required by existing TOE customers:
1. FAU_SAA.1
2. FMT_MSA.2
3. FPT_TST.1
165
UNCLASSIFIED
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising