View
1
Download
0
Category
Preview:
Citation preview
IEEE P2600.5/D31b31a, December 2007
IEEE P2600.5™/D31b31aDraft Standard fora Protection Profile in Environment E
Prepared by the Hardcopy Device and System Security Working Group of the
IEEE Computer Society Information Assurance (C/IA) Committee
Copyright © 2007 by the Institute of Electrical and Electronics Engineers, Inc.Three Park AvenueNew York, New York 10016-5997, USAAll rights reserved.
This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only. Prior to submitting this document to another standards development organization for standardization activities, permission must first be obtained from the Manager, Standards Licensing and Contracts, IEEE Standards Activities Department. Other entities seeking permission to reproduce this document, in whole or in part, must obtain permission from the Manager, Standards Licensing and Contracts, IEEE Standards Activities Department.
IEEE Standards Activities DepartmentStandards Licensing and Contracts445 Hoes Lane, P.O. Box 1331Piscataway, NJ 08855-1331, USA
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
1
1
2
3
4
5
6789
101112131415161718
1920212223
23
IEEE P2600.5/D31b31a, December 2007
Abstract: Standard for a Protection Profile for Hardcopy Devices in a commercial information processing environment in which many elements of security are provided by the physical environment but the sensitive nature and volume of the documents processed often require a moderate to high level of document security, network security, and security assurance, are required. Typically, this environment typically involves one or more dedicated operators that handle a high volume of documents commissioned by multiple enterprise organizations or paying customers. This environment will be known as “Operational Environment E”.”Keywords: Hardcopy, Paper, Document, Printer, Scanner, Copier, Facsimile, Fax, Document Server, Document Storage and Retrieval, Nonvolatile storage, Residual data, Temporary data, Disk overwrite, Network interface, NIC, Shared communications medium, Multifunction Device, Multifunction Product, All-In-One, MFD, MFP, Network, Office, ISO/IEC 15408, Common Criteria, Protection Profile, Security Target, Production Systems, Transaction Printer, Digital Press, Production Printer
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
ii
1
2
123456789
10111213
34
IEEE P2600.5/D31b31a, December 2007
Introduction
(This introduction is not part of IEEE P2600.5/D31b31a, Draft Standard for a Protection Profile in Environment E.)
This document is a standard for a Common Criteria Family of Protection Profiles for Hardcopy Devices. It is intended to be used by manufacturers of hardcopy devices to write conformant Security Target documents for Common Criteria certification of their hardcopy device products. It may also be used to write conformant Protection Profiles for hardcopy devices.
This standard is related to IEEE Std. 2600. IEEE Std. 2600 is a more general standard for hardcopy device security and contains a large amount of content that is beyond the scope of or otherwise inappropriate for a Common Criteria Protecton Profile. The two standards are related by way of the Compliance clause of IEEE Std. 2600. With some well-defined exceptions, the IEEE Std. 2600 Compliance clause for “Security Objectives for the HCD in Operational Environment E” contains security objectives that are technically consistent with the TOE Security Objectives (APE_OBJ) clauses of this document. The exceptions to this consistency between IEEE Std. 2600 and IEEE Std. 2600.5 are distinguished by the use of the word “should” instead of “shall” in IEEE Std. 2600 and the absence of those objectives in IEEE Std. 2600.5.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents or patent applications for which a license may be required to implement an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.
Participants
At the time this draft standard was completed, the Hardcopy Device and System Security Working Group had the following membership:
Don Wright, Chair
Lee Farrell, Vice-chair
Brian Smithson, Secretary and Lead Editor
Hiromasa AkamatsuCarmen AubryNancy ChenPeter CybuckNick Del ReSatoshi FujitaniTom Haapanen
Harry LewisTakanori MasuiTakeshi NakamuraRon NevoYusuke OhtaKen OtaAlan Sukert
Jerry ThrasherHiroki UchiyamaShigeru UedaBrian VolkoffSameer Yami
The following members of the balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention.
(to be supplied by IEEE)
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
iii
1
2
1
23456789
1011121314151617
18
1920212223
24
25262728
29
30
31323334353637
38394041424344
4546474849
505152535455
34
IEEE P2600.5/D31b31a, December 2007
Acknowledgments
The following companies have agreed to make financial contributions to underwrite the cost of Common Criteria certification of some or all of the IEEE Std. 2600-series protection profiles:
Canon Océ ToshibaFuji-Xerox Oki Data XeroxHP RicohLexmark Sharp
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
iii
1
2
1
2345678
34
IEEE P2600.5/D31b31a, December 2007
CONTENTS
1 Overview.................................................................................................................................................1
1.1 Scope.............................................................................................................................................11.2 Purpose..........................................................................................................................................1
2 Normative references..............................................................................................................................1
3 Special Terms..........................................................................................................................................2
4 Protection Profiles references (APE_INT).............................................................................................3
5 Family of Protection Profiles overview (APE_INT)..............................................................................5
5.1 Typical products............................................................................................................................55.2 Typical usage.................................................................................................................................55.3 Targets of Evaluation....................................................................................................................65.4 TOE models...................................................................................................................................65.5 Entity definitions...........................................................................................................................7
6 Conformance claims (APE_CCL)........................................................................................................13
6.1 Conformance to Common Criteria..............................................................................................136.2 Conformance to other Protection Profiles...................................................................................136.3 Conformance to Packages...........................................................................................................136.4 Conformance to this Protection Profile.......................................................................................13
7 Print Protection Profile: P2600.5-PRT.................................................................................................14
7.1 PRT TOE Overview (APE_INT)................................................................................................147.2 PRT Security problem definition (APE_SPD)............................................................................167.3 PRT Security objectives (APE_OBJ)..........................................................................................187.4 PRT Extended components definition (APE_ECD)...................................................................207.5 PRT Security functional requirements (APE_REQ)...................................................................207.6 PRT Security requirements rationale..........................................................................................31
8 Scan Protection Profile: P2600.5-SCN.................................................................................................34
8.1 SCN TOE Overview (APE_INT)................................................................................................348.2 SCN Security problem definition (APE_SPD)...........................................................................368.3 SCN Security objectives (APE_OBJ).........................................................................................388.4 SCN Extended components definition (APE_ECD)...................................................................408.5 SCN Security functional requirements (APE_REQ)..................................................................408.6 SCN Security requirements rationale..........................................................................................51
9 Copy Protection Profile: P2600.5-CPY................................................................................................53
9.1 CPY TOE Overview (APE_INT)................................................................................................539.2 CPY Security problem definition (APE_SPD)...........................................................................559.3 CPY Security objectives (APE_OBJ).........................................................................................579.4 CPY Extended components definition (APE_ECD)...................................................................59
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
iii
1
2
1
2
34
5
6
7
8
910111213
14
15161718
19
202122232425
26
272829303132
33
34353637
34
IEEE P2600.5/D31b31a, December 2007
9.5 CPY Security functional requirements (APE_REQ)..................................................................599.6 CPY Security requirements rationale..........................................................................................70
10 Document Storage and Retrieval Protection Profile: P2600.5-DSR....................................................73
10.1 DSR TOE Overview (APE_INT)................................................................................................7310.2 DSR Security problem definition (APE_SPD)...........................................................................7510.3 DSR Security objectives (APE_OBJ).........................................................................................7710.4 DSR Extended components definition (APE_ECD)...................................................................7910.5 DSR Security functional requirements (APE_REQ)..................................................................7910.6 DSR Security requirements rationale..........................................................................................90
11 Nonvolatile Storage Protection Profile: P2600.5-NVS........................................................................94
11.1 NVS TOE Overview (APE_INT)...............................................................................................9411.2 NVS Security problem definition (APE_SPD)...........................................................................9511.3 NVS Security objectives (APE_OBJ).........................................................................................9711.4 NVS Extended components definition (APE_ECD)...................................................................9911.5 NVS Security functional requirements (APE_REQ)..................................................................9911.6 NVS Security requirements rationale........................................................................................108
12 Security assurance requirements (APE_REQ)....................................................................................111
12.1 ADV_ARC.1 Security architectural description.......................................................................11112.2 ADV_FSP.2 Security-enforcing functional specification.........................................................11212.3 ADV_TDS.1 Basic design........................................................................................................11312.4 AGD_OPE.1 Operational user guidance...................................................................................11312.5 AGD_PRE.1 Preparative procedures........................................................................................11412.6 ALC_CMC.2 Use of a CM system...........................................................................................11512.7 ALC_CMS.2 Parts of the TOE CM coverage...........................................................................11512.8 ALC_DEL.1 Delivery procedures.............................................................................................11612.9 ALC_FLR.1 Basic flaw remediation........................................................................................11612.10 ATE_COV.1 Evidence of coverage..........................................................................................11712.11 ATE_FUN.1 Functional testing................................................................................................11712.12 ATE_IND.2 Independent testing - sample................................................................................11812.13 AVA_VAN.2 Vulnerability analysis........................................................................................11912.14 ASE_CCL.1 Conformance claims............................................................................................11912.15 ASE_OBJ.2 Security objectives................................................................................................12012.16 ASE_ECD.1 Extended components definition.........................................................................12112.17 ASE_INT.1 ST introduction.....................................................................................................12212.18 ASE_SPD.1 Security problem definition..................................................................................12212.19 ASE_REQ.2 Derived security requirements.............................................................................12312.20 ASE_TSS.1 TOE summary specification.................................................................................124
Annex A normative) Glossary......................................................................................................................125
Annex B Acronyms....................................................................................................................................127
Annex B........................................................................................................................................................138
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
iv
1
2
12
3
456789
10
111213141516
17
1819202122232425262728293031323334353637
38
39
40
4142
34
IEEE P2600.5/D31b31a, December 2007
Draft Standard fora Protection Profile in Environment E
1 Overview
1.1 Scope
Standard for a Protection Profile for Hardcopy Devices in a restrictive commercial information processing environment in which a relatively high level of document security, operational accountability, and information assurance, are required. Typical information processed in this environment is trade secret, mission-critical, or subject to legal and regulatory considerations such as for privacy or governance. This environment is not intended to support life-critical or national security applications. This environment will be known as “Operational Environment E”.
1.2 Purpose
The purpose of this standard is to create security protection profiles hardcopy devices in Operational Environment E as defined in IEEE Std. 2600 Information Technology: Hardcopy System and Device Security.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies.
[B1] IEEE Std. 2600 Information Technology: Hardcopy System and Device Security
[B2] Common Criteria for Information Technology Security Evaluation Version 3.1, Release 1 - Part 1: Introduction and general model, available from: http://www.commoncriteriaportal.org/public/files/CCPART1V3.1R1.pdf
[B3] Common Criteria for Information Technology Security Evaluation Version 3.1, Release 2 - Part 2: Security functional requirements, available from: http://www.commoncriteriaportal.org/public/files/CCPART2V3.1R1.pdf
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
1
1
2
1
2
3
4
56789
10
11
121314
15
1617181920
212223
242526
34
IEEE P2600.5/D31b31a, December 2007
[B4] Common Criteria for Information Technology Security Evaluation Version 3.1, Release 2 - Part 3: Security Assurance Requirements, available from: http://www.commoncriteriaportal.org/public/files/CCPART3V3.1R1.pdf
[B5] Common Methodology for Information Technology Security Evaluation Version 3.1, Release 2 - Evaluation Methodology, available from: http://www.commoncriteriaportal.org/public/files/CEMV3.1R1.pdf
[B6] IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, New York, Institute of Electrical and Electronics Engineers, Inc.
3 Special Terms
Lists of terms and abbreviations used in this document may be found in Annex A “normative) Glossary” and “Annex B Acronyms”. Other terms may be defined in The Authoritative Dictionary of IEEE Standards Terms [B6]
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
2
1
2
123
456
78
9
101112
34
IEEE P2600.5/D31b31a, December 2007
4 Protection Profiles references (APE_INT)
The class of Hardcopy Device (HCD) products encompasses a wide variety of functions and configurations, from small non-networked printers to large networked multifunction devices and production printing systems. To accommodate this variety of products, this Protection Profile is structured as a family of protection profiles composed of a variety of individual Protection Profiles which represent functions that are typically found in such products.
To use this Family of Protection Profiles, authors compose a security target or protection profile which:
a) Conforms to one or more of the following Protection Profiles: P2600.5-PRT, P2600.5-SCN, or P2600.5-CPY; and,
b) Conforms to any and all of the protection profiles in this Family of Protection Profiles (listed below) that represent functions which are present in their target of evaluation.
In other words, this Family of Protection Profiles can be used to create a security target or protection profile only for a target of evaluation that performs at least one of the functions that define hardcopy devices (print, scan, copy, or fax), and conforms to every Protection Profile whose Usage statement describes a function that is present in its target of evaluation.
The formal compliance requirements are described in Section 6.4 “Conformance to this Protection Profile”.
Title: P2600.5-PRT, Protection Profile for Print Functions in Hardcopy Devices, Operational Environment ARegistration:<to be provided upon registration>PP Version: 1.0, dated <date to be provided> Common Criteria: Version 3.1, Release 2, Part 2 conformant, Part 3 conformant, EAL2 augmented byALC_FLR.1Sponsor: IEEE Computer Society Information Assurance (C/IA) CommitteeAuthors: IEEE Hardcopy Device and System Security Working GroupKeywords: Hardcopy, Paper, Document, Printer, Transaction Printer, Digital Press, Production PrinterUsage: This Protection Profile shall be used for HCD products (such as printers, paper-based fax machines, MFPs amd Production Printers) that perform a printing function in which electronic document input is converted to physical document output.
Title: P2600.5-SCN, Protection Profile for Scan Functions in Hardcopy Devices, Operational Environment ARegistration:<to be provided upon registration>PP Version: 1.0, dated <date to be provided> Common Criteria: Version 3.1, Release 2, Part 2 conformant, Part 3 conformant, EAL2 augmented byALC_FLR.1Sponsor: IEEE Computer Society Information Assurance (C/IA) CommitteeAuthors: IEEE Hardcopy Device and System Security Working GroupKeywords: Hardcopy, Paper, Document, Scanner, Transaction Printer, Digital Press, Production PrinterUsage: This Protection Profile shall be used for HCD products (such as scanners, paper-based fax machines, MFPs and Production Printers) that perform a scanning function in which physical document input is converted electronic document output.
Title: P2600.5-CPY, Protection Profile for Copy Functions in Hardcopy Devices, Operational Environment ARegistration:<to be provided upon registration>PP Version: 1.0, dated <date to be provided> Common Criteria: Version 3.1, Release 2, Part 2 conformant, Part 3 conformant, EAL2 augmented byALC_FLR.1Sponsor: IEEE Computer Society Information Assurance (C/IA) Committee
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
3
1
2
1
23456789
1011
1213
14151617181920212223242526272829303132
333435363738394041424344
45464748495051
34
IEEE P2600.5/D31b31a, December 2007
Authors: IEEE Hardcopy Device and System Security Working GroupKeywords: Hardcopy, Paper, Document, Copier, Transaction Printer, Digital Press, Production PrinterUsage: This Protection Profile shall be used for HCD products (such as copiers, MFPs and Production Printers) that perform copy function in which physical document input is duplicated to physical document output.
Title: P2600.5-DSR, Protection Profile for Document Storage and Retrieval Functions in Hardcopy Devices, Operational Environment ARegistration:<to be provided upon registration>PP Version: 1.0, dated <date to be provided> Common Criteria: Version 3.1, Release 2, Part 2 conformant, Part 3 conformant, EAL2 augmented byALC_FLR.1Sponsor: IEEE Computer Society Information Assurance (C/IA) CommitteeAuthors: IEEE Hardcopy Device and System Security Working GroupKeywords: Hardcopy, Paper, Document, Document Server, Document Storage and Retrieval, Transaction Printer, Digital Press, Production PrinterUsage: This Protection Profile shall be used for HCD products (such as MFPs and Production Printers) that perform a document storage and retrieval feature in which a document is persistently stored during one job and can be retrieved during one or more subsequent jobs.
Title: P2600.5-NVS, Protection Profile for Nonvolatile Storage Functions in Hardcopy Devices, Operational Environment ARegistration:<to be provided upon registration>PP Version: 1.0, dated <date to be provided> Common Criteria: Version 3.1, Release 2, Part 2 conformant, Part 3 conformant, EAL2 augmented byALC_FLR.1Sponsor: IEEE Computer Society Information Assurance (C/IA) CommitteeAuthors: IEEE Hardcopy Device and System Security Working GroupKeywords: Hardcopy, Paper, Document, Nonvolatile storage, Residual data, Temporary data, Disk overwrite, Transaction Printer, Digital Press, Production PrinterUsage: This Protection Profile shall be used for products that provide nonvolatile storage of document data in a storage device which can practicably be removed from the HCD by unauthorized people for analysis and recovery of deleted data.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
4
1
2
12345
6789
101112131415161718
19202122232425262728293031
34
IEEE P2600.5/D31b31a, December 2007
5 Family of Protection Profiles overview (APE_INT)
5.1 Typical products
The Hardcopy Devices (HCDs) considered in this Family of Protection Profiles are used for the purpose of converting hardcopy documents into digital form (scanning), converting digital documents into hardcopy form (printing), transmitting hardcopy documents over telephone lines (faxing), or duplicating hardcopy documents (copying). Hardcopy documents are commonly in paper form, but they can also take other forms such as positive or negative transparencies or film.
HCDs can be implemented in many different configurations, depending on their intended purpose or purposes. Simple devices have a single purpose implemented by a single function, such as a printer, scanner, copier, or fax machine. Other devices augment a single primary purpose with additional secondary functions, such as a fax machine that can also be used to make copies, or a copier that can also be used as a printer. Complex multifunction devices fulfill multiple purposes by using multiple functions in different combinations to perform the operations of several single-function devices.
Some HCDs have additional functions that enhance their capabilities, such as hard disk drives or other nonvolatile storage systems, document server functions, or mechanisms for manually or automatically updating the HCD’s operating software.
All HCDs considered in this Family of Protection Profiles are assumed to provide the capability for appropriately authorized users to manage the security features of the HCD.
5.2 Typical usage
HCDs can be used in a wide variety of environments, such as:
home use by consumers;
home or office use by small businesses;
office use by medium or large organizations;
self-service use by the public in retail copy shops, libraries, business centers, or educational institutions; and
production use by commercial service providers
HCDs may contain or process valuable or sensitive assets that need to be protected from unauthorized disclosure, alteration, and destruction. The utility of the device itself may be considered a valuable asset which also needs to be protected. There is also a need to ensure that the HCD cannot be misused in such a way that it causes harm to devices with which it shares network connections.
However, each environment may place a different value on those assets, make different assumptions about security-relevant factors such as physical security and administrator skill, face threats of differing approach and sophistication, and be subject to different external legal, regulatory, or policy requirements. It is not practical to fulfill one set of security objectives for all environments, and therefore, the IEEE Std. P2600 has defined several environments that form the basis for several Family of Protection Profiles standards.
A complete description of those environments can be found in IEEE Std. P2600, Clause 5.
This Family of Protection Profiles, IEEE Std. P2600.5, addresses the requirements of Operational Environment E. Operational Environment E is generally characterized as a restrictive commercial
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
5
1
2
1
2
3456789
101112131415161718192021
22
232425
26
27
2829
30
313233343536373839404142434445
34
IEEE P2600.5/D31b31a, December 2007
information processing environment in which a relatively high level of document security, operational accountability, and information assurance, are required. Typical information processed in this environment is trade secret, mission-critical, or subject to legal and regulatory considerations such as for privacy or governance. This environment is not intended to support life-critical or national security applications.
5.3 Targets of Evaluation
In order to create a Common Criteria profile that can be used for many types and configurations of HCDs, it is necessary to structure the profile as a family of protection profiles. This Family of Protection Profiles is composed of protection profiles whose targets of evaluation represent the discrete functions of common hardcopy devices:
Printing – producing a hardcopy document from its electronic form
Scanning – producing an electronic document from its hardcopy form
Copying – duplicating a hardcopy document
Faxing – scanning documents in hardcopy form and transmitting them in electronic form over telephone lines, and receiving documents in electronic form over telephone lines and printing them in hardcopy form
Document storage and retrieval – storing an electronic document for subsequent retrieval
Nonvolatile storage – persistent or temporary document storage on devices that could practicably be removed and analyzed when the HCD is powered off
Shared-medium Interfaces – transmitting and receiving documents and data between the HCD and external devices over communications media that are or can be shared by other users
These functions can be combined to represent a wide variety of complete hardcopy devices. In this Family of Protection Profiles, each function is presented in an individual protection profile that contains the TOE overview, security problem definition, security objectives, extended components definitions, and security functional requirements, for that particular function. Conformance claims and security assurance requirements are common to all protection profiles in the family, and are therefore presented once.
5.4 TOE models
TOEs are described using the Common Criteria terminology of Users, Subjects, Objects, Operations, and Interfaces. Two additional terms are introduced: Channels, is introduced to describe both data interfaces and hardcopy document input/output mechanisms, and TOE Owner describes the person or organizational entity which is responsible for proecting TOE assets and establishing related security policies.
In the Common Criteria model, Users bind with Subjects through Interfaces to perform Operations on Objects. These entities and the communication among them have been defined abstractly so that they do not imply or require any particular architecture or implementation. It is anticipated that security target and protection profile authors will be able to use this model to describe most common HCD architectures and implementations.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
6
1
2
1234
5
6789
1011
12
13
141516
17
1819
2021
2223242526
27
28293031323334353637
34
IEEE P2600.5/D31b31a, December 2007
Figure 1—General TOE model
Subject
User
Normal UserAdministrator
Object
TSF Data User Data
Binds to
Performs operations on
Interface
5.5 Entity definitions
5.5.1 Users
Users are entities that are external to the TOE and which interact with the TOE. There may be five types of Users: Originator, Delegate, Administrator, Other Subject, and External Device.
Figure 2—Users
User
Originator AdministratorDelegate OtherSubject ExtDevice
For the purposes of this Protection Profile, the term ‘Operator’ will be used throughout the rest of this document when referring to a ‘User’ as an entity. In some instances the term ‘User’ will be still used but it is to be considered to be synonymous with the term ‘Operator’.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
7
1
2
1
2
3
4
56
7
89
1011
34
IEEE P2600.5/D31b31a, December 2007
Table 1—Users
Designation UserU.ORIGINATOR An Operator who is authorized to perform initiate User Document
Data processing functions of the TOE. Note: For Operational Environment E an Originator is usually a dedicated operator who performs Normal Use functions and accesses User Data.
U.DELEGATE An Operator who has been granted permission by an Originator to access that Originator’s User Document Data
U.ADMINISTRATOR An Operator who is authorized to perform the management functions of the TOE. Note: For Operational Environment E an Originator the dedicated operator can also act as an Administrator.
U.OTHERSUBJECT The Subject of another TOE from this Family of Protection Profiles that interacts with the TOE and is part of the overall target of evaluation of a conforming Security Target or Protection Profile.
U.EXTDEVICE An external IT device with which the TOE exchanges data.
PP APPLICATION NOTE— Some Operators do not apply to some TOEs. The Users that apply to each TOE are specified in the Protection Profile of each TOE.
5.5.2 Subjects
Subjects are active entities in the TOE that perform Operations on Objects. In this Family of Protection Profiles, Subjects represent the discrete functions of an HCD, and each TOE applies to only one Subject.
Figure 3—Subjects
Print Scan Copy Fax Doc. Store/ Retrieve Nonvol. Storage Shared-medium Int.
Subject
Table 2—Subjects
Designation SubjectS.PRT PrintS.SCN ScanS.CPY CopyS.DSR Document Store/RetrieveS.NVS Nonvolatile Storage
5.5.3 Objects (Assets)
Objects are passive entities in the TOE that contain or receive information and upon which Subjects perform Operations. In this Family of Protection Profiles, Objects are equivalent to TOE Assets. There are two types of Objects:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
8
1
2
1
23
4
56
7
89
10
111213
34
IEEE P2600.5/D31b31a, December 2007
User Data: data that are created by and for Operators and do not affect the operation of the TOE Security Functions (TSF). This type of data is composed of two objects: User Document Data, and User Function Data.
User Document Data are the information that HCDs are primarily designed to process, for example, a printed document or an electronic representation of such.
User Function Data are the instructions given to the HCD for processing User Document Data and the responses provided by the HCD to Operator requests.
TSF Data: data that are created by and for the TOE and that might affect the operation of the TSF. This type of data is composed of two objects: TSF Protected Data and TSF Confidential Data.
TSF Protected Data are assets for which alteration by an Operator who is not an Administrator or the owner of the data would have an effect on the operational security of the TOE, but for which disclosure is acceptable.
TSF Confidential Data are assets for which either disclosure or alteration by an Operator who is not an Administrator or the owner of the data would have an effect on the operational security of the TOE.
These objects may exist in one or more states: in transit between the TOE and an external device over a shared medium interface, in the TOE while awaiting or processing a job, in the TOE after the completion of a job and retrievable by subsequent jobs, as residual data after having been deleted during or after a job, or awaiting output to a hardcopy document handler.
PP APPLICATION NOTE— Some states do not apply to some objects, and some object-state pairs do not apply to some TOEs. The objects and object-state pairs that apply to each TOE are specified in the Protection Profile of each TOE.
Figure 4—Objects (Assets)
Asset
User Data TSF Data
User Document Data User Function Data TSF Protected Data TSF Confidential Data
TRANSIT
RETREIVE
DELETED
OUTPUT
TRANSIT RESTTRANSIT TRANSITRESTREST REST
J OB
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
9
1
2
12345
67
89
10111213
1415
1617181920
212223
24
25
34
IEEE P2600.5/D31b31a, December 2007
Table 3—Object (Asset) definitions
Use
r Dat
a
Use
r Doc
umen
t dat
a
D.DOC.TRANSIT In transit over a shared communications medium
User Document Data in transit to or from the TOE over an Interface to a shared communications medium
D.DOC.REST In the TOE User Document Data that are in the TOE (includes .RETRIEVE, .JOB, and .OUTPUT))
D.DOC.RETRIEVE In the TOE, retrievable by a new job
User Document Data in the TOE after completing a job and retrievable by a new job
D.DOC.JOB In the TOE, awaiting or performing a job
User Document Data in the TOE awaiting or performing a job (includes .OUTPUT)
D.DOC.OUTPUT In the TOE, waiting to be sent to hardcopy output handler
User Document Data in the TOE waiting to be sent to an output document handler in hardcopy form
D.DOC.DELETED Deleted Residual data from User Document Data that have been dereferenced (deleted) during or after processing a job
Use
r Fun
ctio
n D
ata D.FUNC.TRANSIT In transit over an
Interface to a shared communications medium
Job instructions or job status in transit to or from the TOE over an Interface to a shared communications medium
D.FUNC.REST In the TOE Job instructions or job status inquiries in the TOE
TSF
Dat
a
TSF
Prot
ecte
d da
ta
D.PROT.TRANSIT In transit over an Interface to a shared communications medium
Authentication data, security attributes, and other security relevant data, in transit to or from the TOE over an Interface to a shared communications medium, which must be protected from unauthorized alteration
D.PROT.REST In the TOE Authentication data, security attributes, and other security relevant data, in the TOE,, which must be protected from unauthorized alteration
TSF
Con
fiden
tial d
ata
D.CONF.TRANSIT In transit over an Interface to a shared communications medium
Authentication data, security attributes, and other security relevant data, in transit to or from the TOE over an Interface to a shared communications medium, which must be protected from unauthorized disclosure or alteration
D.CONF.REST In the TOE Authentication data, security attributes, and other security relevant data, in the TOE, which must be protected from unauthorized disclosure or alteration
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
10
1
2
1
2
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— Some states do not apply to some objects, and some object-state pairs do not apply to some TOEs. The objects and object-state pairs that apply to each TOE are specified in the Protection Profile of each TOE.
PP APPLICATION NOTE— There is a hierarchical relationship among D.DOC.REST and its subclasses D.DOC.RETRIEVE, D.DOC.JOB, and D.DOC.OUTPUT, When reference is made to one of these assets and to the associated threats and objectives in the Protection Profiles for each TOE, reference will be made to the lowest distinguishable class.
PP APPLICATION NOTE— In some TOEs, operations may be performed on behalf of other TOEs. To distinguish the the assets of other TOEs from the direct assets of a TOE, those assets are identified by an attribute (+OTHERTOE).
PP APPLICATION NOTE— It is required that ST authors define the TSF Data assets for their TOEs, and to appropriately categorize those assets according to whether they require protection from unauthorized alteration or protection from both unauthorized disclosure and unauthorized alteration.
5.5.4 Operations
Operations are a specific type of action performed by a Subject on an Object. In this Family of Protection Profiles, two types of operations are considered: those that result in disclosure of information (e.g., Reading) and those that result in alteration of information (Creating, Writing, Deleting). For the purposes of this Family of Protection Profiles, Reading is implied by Creating, Writing, or Deleting.
Figure 5—Operations
Reading Creating/ Writing/ Deleting
Operation
5.5.5 Channels
Channels are the mechanisms through which data can be transferred into and out of the TOE. In this Family of Protection Profiles, there are four types of channels:
Private Medium interface: mechanisms for exchanging data that (1) use wired or wireless electronic methods over a communications medium which, in conventional practice, is not accessed by multiple simultaneous operators; or, (2) using physical input/display methods.
Shared Medium interface: mechanisms for exchanging data that use wired or wireless network or non-network electronic methods over a communications medium which, in conventional practice, is or can be simultaneously accessed by multiple operators.
Input hardcopy handler: mechanisms for transferring User Document Data into of the TOE in hardcopy form.
Output hardcopy handler: mechanisms for transferring User Document Data out of the TOE in hardcopy form.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
11
1
2
123
4567
89
10111213
14
15161718
19
20
21
2223242526272829303132333435363738
34
IEEE P2600.5/D31b31a, December 2007
Figure 6—Channels
Channel
Private Medium Shared Medium
HardcopyInterface
Input Handler Output Handler
PP APPLICATION NOTE— Some channels to not apply to some TOEs. The channels that apply to each TOE are specified in the Protection Profile of each TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
12
1
2
1
2
345
34
IEEE P2600.5/D31b31a, December 2007
6 Conformance claims (APE_CCL)
6.1 Conformance to Common Criteria
The Protection Profiles in this Family of Protection Profiles are Common Criteria version 3.1, Release 2 Part 2 conformant and Part 3 conformant.
6.2 Conformance to other Protection Profiles
The Protection Profiles in this Family of Protection Profiles are not based on any other protection profile.
6.3 Conformance to Packages
The Protection Profiles in this Family of Protection Profiles conform to Common Criteria Evaluation Assurance Level (EAL) 2 augmented by ALC_FLR.1.
6.4 Conformance to this Protection Profile
To claim conformance to any of the protection profiles that are contained in this Family of Protection Profiles, the conforming security target or protection profile shall comply with two rules:
a) The Hardcopy Rule: Security targets and other protection profiles shall claim at least Demonstrable Conformance with one or more of the following Protection Profiles listed in Section 4 “Protection Profiles references (APE_INT)”: P2600.5-PRT, P2600.5-SCN or P2600.5-CPY.
b) The Complete TOE Rule: Security targets and other protection profiles shall claim at least Demonstrable Conformance with any and all Protection Profiles listed in Section 4 “ProtectionProfiles references (APE_INT)” whose target(s) of evaluation are representative of functions that are provided in the target of that security target or other protection profile.
Demonstrable conformance requires that the security target and other protection profiles be a suitable solution to the generic security problems described in this Protection Profile.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
13
1
2
1
2
34
5
6
7
89
10
11121314151617
18192021
2223
34
IEEE P2600.5/D31b31a, December 2007
7 Print Protection Profile: P2600.5-PRT
7.1 PRT TOE Overview (APE_INT)
7.1.1 PRT TOE Model
The Print TOE is composed of the essential input, output, and processing elements required to produce a printed hardcopy document from a document in electronic form:
a) An Originator sends User Document Data along with associated User Function Data (e.g. printing instructions) to the Print subject through an Interface.
b) The Print subject receives User Document Data and User Function Data, and produces a hardcopy Output Document.
c) The Originator, or a Delegate, retrieves the hardcopy Output Document from a document handler.
d) The Originator, or a Delegate, may query or modify User Function Data after submitting a job and before its completion.
User Function Data (e.g. print status) and TSF Data (e.g. job or audit logs) may be created or updated during the Print process.
The Print TOE also provides the essential processing elements required to manage the Print process and it’s authorized Operators:
e) An Administrator can retrieve, modify, and store TSF Protected Data.
f) An Administrator can retrieve, modify, and store TSF Confidential Data.
g) The Originator may be able to retrieve, modify, and store his own TSF Protected Data or TSF Confidential Data (e.g. operator profile information, operator password).
Additional TSF Data (e.g. audit logs) may be created or updated during the performance of administrative tasks.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
14
1
2
1
2
3
45678
910
1112
1314
15161718192021
22
2324
252627
34
IEEE P2600.5/D31b31a, December 2007
Figure 7—Print TOE model
User Document Data
User
Originator
User Function Data Interface Output Handler
Hardcopy
Channel
Delegate
OUTPUT REST
Figure 8—Print TOE Administration model
TSF Data
Administrator
User
Originator
Originators may havepermission to access ormodify some TSF Data,such as their own profile,preferences, or passwords.
Channel
REST
7.1.2 Major security features of the PRT TOE
The major security features of the PRT TOE are:
a) All operators are identified and authenticated, and are authorized before being granted permission to perform security-related PRT functions.
b) Information associated with processing PRT jobs is protected from alteration by anyone except for the Originator and authorized Administrators.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
15
1
2
1
23
4
5
6
789
10
1112
34
IEEE P2600.5/D31b31a, December 2007
c) TSF Data, of which unauthorized disclosure threatens operational security, is protected from disclosure to anyone except for the originating operator and authorized Administrators.
d) TSF Data, of which unauthorized alteration threatens operational security, is protected from alteration by anyone except for the originating operator and authorized Administrators.
e) Document processing operations and security-relevant system events (successful and unsuccessful) are recorded, and such records are protected from disclosure or alteration by anyone except for authorized administrators.
PP APPLICATION NOTE— Additional support for protecting nonvolatile stored data may be supplied by the Nonvolatile Storage TOE (P2600.5-NVS). For evaluation purposes, it should be assumed that nonvolatile storage is not present in the PRT TOE.
7.2 PRT Security problem definition (APE_SPD)
7.2.1 PRT Assets
This section describes the security-relevant assets and asset-state pairs that apply to the PRT TOE. These assets and states are a subset of assets and states defined for the Family of Protection Profiles in 5.5.3, “Objects (Assets)”. A PP application note provides additional information about some assets and states that are associated with the practical function of the PRT TOE but that are not within the scode of the TOE.
Table 4—User Data assets of the PRT TOEThere are no User Data Assets associated with the PRT TOE that must be protected from either unauthorized disclosure or unauthorized alteration.
PP APPLICATION NOTE – In the case where there are User Data assets that do need to be protected, it is required that ST authors define those specific User Data assets for their TOEs and then appropriately categorize those User Data assets according to whether they require protection from unauthorized alteration or protection from both unauthorized disclosure and unauthorized alteration.
Table 5— TSF Data assets of the PRT TOE
Asset State Name ExamplesTSF Protected Data
In the TOE D.PROT.REST Authentication data, security attributes, selected resources (e.g., fonts) and other security-relevant data in the TOE, which must be protected from unauthorized alteration
TSF Confidential Data
In the TOE D.CONF.REST Authentication data, security attributes, selected resources (e.g., signature files) and other security-relevant data in the TOE, which must be protected from unauthorized disclosure or alteration
PP APPLICATION NOTE – Some of the assets defined in 5.5.3 “Objects (Assets)” are not applicable to the PRT TOE model. Rationale for inapplicability is described in Table 6:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
16
1
2
12
34
567
89
10
11
12
13141516
17
1819
20212223
24
2526
34
IEEE P2600.5/D31b31a, December 2007
Table 6—Assets not applicable to the PRT TOE
Asset Rationale See other TOED.DOC.TRANSIT Assets in transit are only considered in TOEs that have a shared
medium interface N/A
D.DOC.JOB There is no Operator access to User Document Data after the job has been submitted
NVS
D.DOC.RETRIEVE The PRT TOE does not retain Operator User Document Data after completion of a job
N/A
D.DOC.DELETED Deleted User Document Data are only considered in TOEs that have nonvolatile storage
NVS
D.DOC.OUTPUT The hardcopy output handler is not considered in the PRT TOE because the originating Operator is physically present when User Document Data are sent to the hardcopy output handler.
CPY, NVS
D.FUNC.REST The PRT TOE does not have any User Function Data assets that must always be protected from either unauthorized disclosure or alteration while in the TOE.
N/A
D.FUNC.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.PROT.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.CONF.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
7.2.2 PRT Threats
This section describes threats to assets described in the previous section.
Table 7—Threats to User Data for the PRT TOEThere are no threats associated with User Data that the PRT TOE must be protected from.
Threat Affected asset(s) DescriptionT.FUNC.REST.ALT D.FUNC.REST User Function Data in the TOE may be altered by
unauthorized persons
Table 8—Threats to TSF Data for the PRT TOE
Threat Affected asset(s) DescriptionT.PROT.REST.ALT D.PROT.REST TSF Protected Data in the TOE may be altered by
unauthorized personsT.CONF.REST.DIS D.CONF.REST TSF Confidential Data in the TOE may be disclosed to
unauthorized personsT.CONF.REST.ALT D.CONF.REST TSF Confidential Data in the TOE may be altered by
unauthorized persons
7.2.3 PRT Organizational Security Policies
This section describes the Organizational Security Policies (OSPs) that apply to the PRT TOE. OSPs are used to provide a basis for security objectives that are commonly desired by TOE owners in this operational environment but for which it is not possible to make uniform defintions of the threats that are being mitigated or the assets that are being threatened.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
17
1
2
1
2
3
4
56
7
8
9101112
34
IEEE P2600.5/D31b31a, December 2007
Table 9—Organizational Security Policies for the PRT TOE
Name DefinitionP.OPERATOR.AUTHORIZATION To preserve accountability, Operators will be authorized to use the
TOE only as permitted by the TOE OwnerP.ADMIN.AUTHORIZATION To preserve security, Administrators will be authorized to manage
the TOE only as permitted by the TOE OwnerP.SOFTWARE.VERIFICATION To detect malicious modification of TOE software, procedures
will exist to verify that the currently installed software in the TOE is consistent with the authorized installed software
P.AUDIT.LOGGING To preserve accountability and security, records that provide an audit trail of TOE use and security-relevant events will be maintained and protected from unauthorized disclosure or alteration by the TOE, and will be reviewed by authorized personnel
7.2.4 PRT Assumptions
The Security Objectives and Security Functional Requirements defined in subsequent sections of this Protection Profile are based on the condition that all of the assumptions described in this section are satisfied.
Table 10 —Assumptions for the PRT TOE
Assumption DefinitionA.LOCATION.SECURITY The TOE is located in secure or monitored area which limits the opportunity
for unauthorized physical access to the TOE.A.OPERATOR.TRAINING Operators are aware of the security policies and procedures of their
organization, and are trained and competent to follow those policies and procedures.
A.OPERATOR.TRUST Operators do not use their privileged access rights for malicious purposes.A.ADMIN.TRAINING Administrators are aware of the security policies and procedures of their
organization, and are trained and competent to follow the manufacturer’s guidance and documentation to configure and operate the TOE in accordance those policies and procedures.
A.ADMIN.TRUST Administrators do not use their privileged access rights for malicious purposes.
7.3 PRT Security objectives (APE_OBJ)
7.3.1 PRT Security objectives
This section describes the security objectives that the PRT TOE shall fulfill.
Table 11 —PRT Security objectives for the TOE
Objective DefinitionO.USER.AUTHORIZED The TOE shall require identification and authentication of Users, and shall
ensure that Users are authorized in accordance with security policies before allowing them to use the TOE.
O.PROT.REST.NO_ALT The TOE shall protect TSF Protected Data in the TOE from unauthorized alteration.
O.CONF.REST.NO_DIS The TOE shall protect TSF Confidential Data in the TOE from unauthorized disclosure.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
18
1
2
1
2
345
6
7
8
9
10
34
IEEE P2600.5/D31b31a, December 2007
Objective DefinitionO.CONF.REST.NO_ALT The TOE shall protect TSF Confidential Data in the TOE from
unauthorized alteration.O.ADMIN.AUTHORIZED The TOE shall require identification and authentication of Administrators,
and shall ensure that Administrators, are authorized in accordance with security policies before allowing them to manage the TOE.
O.SOFTWARE.VERIFIED The TOE shall provide procedures to verify that the currently installed software in the TOE is consistent with the authorized installed TOE software.
O.AUDIT.LOGGED The TOE shall create and maintain a log of TOE use and security-relevant events, and prevent its unauthorized disclosure or alteration.
7.3.2 PRT Security objectives for the development environment
There are no security objectives for the development environment for the PRT TOE.
7.3.3 PRT Objectives for the IT operational environment
There are no IT Objectives for the operational environment for the PRT TOE.
7.3.4 PRT Objectives for the non-IT operational environment
This section describes the security objectives that must be fulfilled by non-IT methods in the operational environment for the PRT TOE.
Table 12 —Non-IT Objectives for the operational environment
Objective DefinitionOE.LOCATION.SECURED The TOE shall be placed in secure or monitored area which limits the
opportunity for unauthorized physical access to the TOE.OE.OPERATOR.TRAINED The TOE owner shall ensure that TOE Operators are aware of the security
policies and procedures of their organization, and have the training and competence to follow those policies and procedures.
OE.OPERATOR.TRUSTED The TOE owner shall take steps to establish trust that TOE Operators will not use their privileged access rights for malicious purposes.
OE.ADMIN.TRAINED The TOE owner shall ensure that TOE Administrators are aware of the security policies and procedures of their organization, and have the training, competence, and time to follow the manufacturer’s guidance and documentation to correctly configure and operate the TOE in accordance those policies and procedures.
OE.ADMIN.TRUSTED The TOE owner shall establish trust that TOE administrators will not use their privileged access rights for malicious purposes.
OE.AUDIT.REVIEWED The TOE owner shall ensure that audit logs are reviewed at appropriate intervals for security violations or unusual patterns of activity.
7.3.4.1 PRT Security objectives rationale
This section demonstrates that each threat, organizational security policy, and assumption, are mitigated by at least one security objective for the PRT TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
19
1
2
1
2
3
4
5
67
8
9
1011
34
IEEE P2600.5/D31b31a, December 2007
Table 13 —PRT objectives rationale
Threats. Policies, and Assumptions O.P
RO
T.R
EST.
NO
_ALT
O.C
ON
F.R
EST.
NO
_DIS
O.C
ON
F.R
EST.
NO
_ALT
O.O
PER
ATO
R.A
UTH
OR
IZD
O.A
DM
IN.A
UTH
OR
IZED
O.S
OFT
WA
RE.
VER
IFIE
D
O.A
UD
IT.L
OG
GED
OE.
AU
DIT
.REV
IEW
EDO
E.LO
CA
TIO
N.S
ECU
RED
OE.
AD
MIN
.TR
AIN
ED
OE.
AD
MIN
.TR
UST
ED
OEO
PER
ATO
R.T
RA
INED
O
E.O
PER
ATO
R.T
RU
STED
T.PROT.REST.ALT T.CONF.REST.DIS T.CONF.REST.ALT P.OPERTATOR.AUTHORIZATION P.ADMIN.AUTHORIZATION P.SOFTWARE.VERIFICATION P.AUDIT.LOGGING A.LOCATION.SECURITY A.ADMIN.TRAINING A.ADMIN.TRUST A.OPERATOR.TRAINING A.OPERATOR.TRUST
7.4 PRT Extended components definition (APE_ECD)
The PRT Protection Profile does not define any extended components.
7.5 PRT Security functional requirements (APE_REQ)
This section defines the security functional policies and requirements for the PRT TOE.
7.5.1 Security Function Policies
The Security Function Policy (SFP) described in this section is referenced in one or more SFR Class sections that follow.
7.5.1.1 PRT Access Control SFP
Table 14 — PRT Access Control SFP
Entity Access control rule(s)U.ORIGINATOR S.PRT authorizes U.ORIGINATOR to bind with S.PRT to create a job and
perform subsequent PRT job operations if granted permission to do so by U.ADMINISTRATOR.
U.DELEGATE S.PRT authorizes U.DELEGATE to bind with S.PRT to perform PRT job operations if granted permission to do so by U.ORIGINATOR or U.ADMINISTRATOR.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
20
1
2
1
2
3
4
5
6
78
9
10
34
IEEE P2600.5/D31b31a, December 2007
Entity Access control rule(s)U.ADMINISTRATOR S.PRT requires identification and authentication.
S.PRT authorizes U.ADMINISTRATOR to bind with S.PRT to perform PRT management operations if previously granted permission to do so by a U.ADMINISTRATOR.
D.PROT.REST S.PRT may read on behalf of any authorized Operator.S.PRT may write on behalf of U.ADMINISTRATOR.S.PRT may write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
D.CONF.REST S.PRT may read or write on behalf of U.ADMINISTRATOR.S.PRT may read or write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
7.5.2 Class FAU: Security audit
FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
{FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
[assignment:other specifically defined auditable event]. }
FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
events listed in Table 15—PRT Audit data requirements”; assignment:other specifically defined auditable event].
PP APPLICATION NOTE— Table 16—PRT Audit data recommendations” lists additional auditable events that are recommended for consideration in FAU_GEN.1.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
21
1
2
1
2
4
5
67
8
91011
121314
1516
17
181920
21222324
2526
34
IEEE P2600.5/D31b31a, December 2007
{FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment:other audit relevant informatio]. }
FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, additional information listed in Table 15—PRT Audit data requirements”; assignment:other audit relevant informatio].
PP APPLICATION NOTE— Table 16—PRT Audit data recommendations” lists additional audit information that is recommended for consideration in FAU_GEN.1.2
Table 15 —PRT Audit data requirements
Auditable event Audit level Additional information Relevant SFRDeletion of audit records None None FAU_SAR.1Audit storage full None None FAU_STG.4Job initiation None Type of job FDP_ACF.1Job completion None Type of job FDP_ACF.1Unsuccessful operator authentication Basic None FIA_UAU.1Successful operator authentication Basic None FIA_UAU.1Unsuccessful user identification Basic Attempted operator
identity, if availableFIA_UID.1
Successful operator identification Basic None FIA_UID.1Management function initiation Minimal None FMT_SMF.1Modification of administrative operator/role assignments
Minimal None FMT_SMR.1
Set/change system time Minimal None FPT_STM.1
Table 16 —PRT Audit data recommendations
Auditable event Audit level Additional information Relevant SFRJob initiation None Type of job FDP_ACF.1Attempts to authenticate reach failure limit
Minimal Operator identity, actions taken as a result, and if appropriate, subsequent restoration to the normal state
FIA_AFL.1
PP APPLICATION NOTE— FAU_GEN.1 is a dependency of FAU_SAR.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
22
1
2
12
34
5678
910
1112
131415161718
1920
21
22
23
24
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— FAU_GEN.1 performs audit recommendations of FAU_SAR.1, FAU_SAR.2, FAU_STG.4, FDP_ACF.1, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UAU.7, FIA_UID.1, FMT_MSA.1, FMT_MSA.3, FMT_MTD.1, FMT_SMF.1, FMT_SMR.1, FPT_STM.1, and FPT_TST.1
FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
{FAU_SAR.1.1The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of audit information] from the audit records.}
FAU_SAR.1.1The TSF shall provide [assignment: authorised operators] with the capability to read [assignment: list of audit information] from the audit records.
{FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the user to interpret the information.}
FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the operator to interpret the information.
PP APPLICATION NOTE— FAU_SAR.1 is a dependency of FAU_SAR.2
FAU_SAR.2 Restricted audit review
Hierarchical to: No other components.
Dependencies: FAU_SAR.1 Audit review
{FAU_SAR.2.1The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access.}
FAU_SAR.2.1The TSF shall prohibit all operators read access to the audit records, except those operators that have been granted explicit read-access.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
23
1
2
1234
5
7
8
91011
121314
151617
181920
21
22
24
25
262728
293031
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— FAU_SAR.2 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.1 Protected audit trail storage
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG.1.1The TSF shall protect the stored audit records in the audit trail from unauthorised deletion.
FAU_STG.1.2The TSF shall be able to [selection, choose one of: prevent, detect] unauthorised modifications to the stored audit records in the audit trail.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.4 Prevention of audit data loss
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
{FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditableevents”,“preventauditableevents,exceptthosetakenbytheauthoriseduserwithspecialrights”,
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
24
1
2
1
2
4
5
678
91011
12
13
15
16
17181920212223242526272829303132333435363738
34
IEEE P2600.5/D31b31a, December 2007
“overwritetheoldeststoredauditrecords”]and[assignment: otheractions to be taken in case of audit storage failure] if the audit trail isfull.}
FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditableevents”,“preventauditableevents,exceptthosetakenbytheauthorisedoperatorwithspecialrights”,“overwritetheoldeststoredauditrecords”]and[assignment: otheractions to be taken in case of audit storage failure] if the audit trail isfull.
PP APPLICATION NOTE— FAU_STG.4 is a requirement which fulfills O.AUDIT.LOGGED
7.5.3 Class FCO: Communication
There are no Class FCO security functional requirements for the PRT TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
25
1
2
123456789
10
1112131415161718192021222324252627282930313233343536373839404142
43
44
45
34
IEEE P2600.5/D31b31a, December 2007
7.5.4 Class FCS: Cryptographic support
There are no Class FCS security functional requirements for the PRT TOE.
7.5.5 Class FDP: User data protection
FDP_ACC.1 Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
{FDP_ACC.1.1The TSF shall enforce the [assignment: access control SFP] on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].}
FDP_ACC.1.1The TSF shall enforce the PRT Access Control SFP on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].
PP APPLICATION NOTE— FDP_AC C.1 is a dependency of FMT_MSA.1.
FDP_ACF.1 Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access controlFMT_MSA.3 Static attribute initialisation
{FDP_ACF.1.1The TSF shall enforce the [assignment: access control SFP] to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].}
FDP_ACF.1.1The TSF shall enforce the PRT Access Control SFP to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].
FDP_ACF.1.2The TSF shall enforce the following rules to determine if an operation among controlled
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
26
1
2
1
2
3
4
6
7
89
10
111213
14
15
17
1819
2021222324
2526272829
3031
34
IEEE P2600.5/D31b31a, December 2007
subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects].
FDP_ACF.1.3The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects].
FDP_ACF.1.4The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].
PP APPLICATION NOTE— FDP_AC F.1 is a dependency of FDP_ACC.1.
7.5.6 Class FIA: Identification and authentication
FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to [assignment: list of authentication events].
FIA_AFL.1.2When the defined number of unsuccessful authentication attempts has been [selection: met or surpassed] the TSF shall [assignment: list of actions].
PP APPLICATION NOTE— FIA_AFL.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
27
1
2
123
4567
89
10
11
12
13
15
16
1718192021
222324
2526
34
IEEE P2600.5/D31b31a, December 2007
FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_ATD.1.1The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: list of security attributes].}
FIA_ATD.1.1The TSF shall maintain the following list of security attributes belonging to individual operators: [assignment: list of security attributes].
FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_SOS.1.1The TSF shall provide a mechanism to verify that secrets meet [assignment: a defined quality metric].
PP APPLICATION NOTE— FIA_SOS.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
PP APPLICATION NOTE— The suggested minimum for password quality is eight (8) alphanumeric characters.
FIA_UAU.1 Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated.}
FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the operator to be performed before the operator is authenticated.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
28
1
2
1
3
4
567
89
10
11
13
14
151617
1819
20
21
23
24
252627
282930
34
IEEE P2600.5/D31b31a, December 2007
{FIA_UAU.1.2The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UAU.1.2The TSF shall require each operator to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UAU.1 is a dependency of FIA_AFL.1 and FIA_UAU.7.
FIA_UAU.7 Protected authentication feedback
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the user while the authentication is in progress.}
FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the operator while the authentication is in progress.
PP APPLICATION NOTE— FIA_UAU.7 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
FIA_UID.1 Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is identified.}
FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the operator to be performed before the operator is identified.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
29
1
2
123
456
7
8
10
11
121314
151617
1819
20
22
23
242526
272829
34
IEEE P2600.5/D31b31a, December 2007
(FIA_UID.1.2The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UID.1.2The TSF shall require each operator to be successfully identified before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UID.1 is a dependency of FIA_UAU.1, and FMT_SMR.1.
7.5.7 Class FMT: Security management
FMT_MSA.1 Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, orFDP_IFC.1 Subset information flow control]FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
{FMT_MSA.1.1The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].}
FMT_MSA.1.1The TSF shall enforce the PRT Access Control SFP to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MSA.1 is a dependency of FMT_MSA.3
PP APPLICATION NOTE— FMT_MSA.1 performs management recommendations of FDP_ACF.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
30
1
2
123
456
7
8
9
11
12131415
1617181920
2122232425
26
27
34
IEEE P2600.5/D31b31a, December 2007
FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributesFMT_SMR.1 Security roles
{FMT_MSA.3.1The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection, choose one of: restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.}
FMT_MSA.3.1The TSF shall enforce the PRT Access Control SFP to provide [selection, choose one of: restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial values to override the default values when an object or information is created.
PP APPLICATION NOTE— FMT_MSA.3 is a dependency of FDP_ACF.1
FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations]] the [assignment: list of TSF data] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MTD.1 is a required to fulfill O.PROT.REST.NO_ALT, O.CONF.REST.NO_DIS, and O.CONF.REST.NO_ALT
PP APPLICATION NOTE— In typical applications, an U.ADMINISTRATOR can perform operations on most or all TSF data. U.ORIGINATOR can modify some TSF Data when such data was created for that operator (for example, an Operator’s own password). Refer to the PRT Access Control SFP.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
31
1
2
1
3
456
789
10
11121314
15161718
19
20
22
232425
26272829
3031
323334
34
IEEE P2600.5/D31b31a, December 2007
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1The TSF shall be capable of performing the following management functions: [assignment: list of management functions to be provided by the TSF].
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1The TSF shall be capable of performing the following management functions: [assignment: list of management functions to be provided by the TSF].
PP APPLICATION NOTE— the management functions listed in Table 17—PRT Management functionrecommendations” are recommended for consideration in FMT_SMF.1. The ST author should consider specifying other management functions that support administrative functionality of the ST target of evaluation.
Table 17 —PRT Management function recommendations
Management function Relevant SFRMaintenance of group of operators who are authorized to access audit records
FAU_SAR.1
Management of the operator identities FAU_UID.1Management of system time FPT_STM.1
PP APPLICATION NOTE— FMT_SMF.1 is a dependency of FMT_MTD.1 and FMT_MSA.1
PP APPLICATION NOTE— FMT_SMF.1 performs management recommendations of FDP_ACF.1 FAU_SAR.1, FAU_STG.4, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UID.1, FMT_MSA.1, FMT_MSA.3, FMT_SMR.1, and FPT_STM.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
32
1
2
1
3
4
567
8
10
11
121314
151617
18
19
20
212223
34
IEEE P2600.5/D31b31a, December 2007
FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1The TSF shall maintain the roles [assignment: the authorised identified roles].
PP APPLICATION NOTE— recommended minimum to be specified in FMT_SMR.1: Administrator
{FMT_SMR.1.2The TSF shall be able to associate users with roles.}
FMT_SMR.1.2The TSF shall be able to associate operators with roles.
PP APPLICATION NOTE— FMT_SMR.1 is a dependency of FMT_MSA.1, FMT_MSA.3, and FMT_MTD.1.
7.5.8 Class FPR: Privacy
There are no Class FPR security functional requirements for the PRT TOE.
7.5.9 Class FPT: Protection of the TSF
FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_STM.1.1The TSF shall be able to provide reliable time stamps.
PP APPLICATION NOTE— FPT_STM.1 is a dependency of FAU_GEN.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
33
1
2
1
3
4
56
7
89
1011
12
13
14
15
16
18
19
2021
22
34
IEEE P2600.5/D31b31a, December 2007
FPT_TST.1 TSF testing
Hierarchical to: No other components.
Dependencies: No dependencies
{FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorised user, at theconditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF]}
FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorisedoperator, at theconditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF].
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF data]}
FPT_TST.1.The TSF shall provide authorised
operator with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of stored TSF executable code}
FPT_TST.1.The TSF shall provide authorised
operator with the capability to verify the integrity of stored TSF executable code.
PP APPLICATION NOTE— FPT_TST.1 is a requirement which fulfills O.SOFTWARE.VERIFIED.
7.5.10 Class FRU: Resource utilization
There are no Class FRU security functional requirements for the PRT TOE.
7.5.11 Class FTA: TOE access
There are no Class FTA security functional requirements for the PRT TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
34
1
2
1
3
4
56789
10
111213141516
17181920
2122232425
26272829
31323334
36
37
38
39
40
34
IEEE P2600.5/D31b31a, December 2007
7.5.12 Class FTP: Trusted paths/channels
There are no Class FTP security functional requirements for the PRT TOE.
7.6 PRT Security requirements rationale
Table 18 and Table 19 demonstrate the completeness and sufficiency of SFRs that fulfill the objectives of the PRT TOE. Bold typefaced items provide primary (P) fulfillment of the objectives, and normal typefaced items are support (S) fulfillment.
Table 18 —Completeness of PRT security requirements
SFR O.P
RO
T.R
EST
.NO
_AL
TO
.CO
NF.
RE
ST.N
O_D
ISO
.CO
NF.
RE
ST.N
O_A
LT
O.O
PER
AT
OR
.AU
TH
OR
IZE
DO
.AD
MIN
.AU
TH
OR
IZE
DO
.SO
FTW
AR
E.V
ER
IFIE
DO
.AU
DIT
.LO
GG
ED
FAU_GEN.1 PFAU_SAR.1 PFAU_SAR.2 SFAU_STG.1 SFAU_STG.4 SFDP_ACC.1 FDP_ACF.1 FIA_AFL.1 S S FIA_ATD.1 S S FIA_SOS.1 S SFIA_UAU.1 P P FIA_UAU.7 S S FIA_UID.1 S S S P P SFMT_MSA.1 FMT_MSA.3 FMT_MTD.1 P P P FMT_SMF.1 S S S FMT_SMR.1 S S S FPT_STM.1 SFPT.TST.1 P
Table 19 —Sufficiency of PRT security requirements
Objectives Description SFRs PurposeO.CONF.REST.NO_DIS Protection of
TSF Data from
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1
Prevents disclosure by restricting access.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
35
1
2
1
2
3
456
7
8
9
34
IEEE P2600.5/D31b31a, December 2007
Objectives Description SFRs Purposeunauthorized disclosure
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.PROT.REST.NO_ALT, O.CONF.REST.NO_ALT
Protection of TSF Data from unauthorized alteration
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1
Prevents alteration by restricting access.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.OPERATOR.AUTHORIZED,O.ADMIN.AUTHORIZED
Authorization of users and administrators to use the TOE.
FIA_AFL.1 Supports authorization by policy for handling authentication failures.
FIA_ATD.1 Supports authorization by associating attributes with authorized users.
FIA_SOS.1 Supports authentication by requiring minimum strength of authentication secrets.
FIA_UAU.1 Provides authorization by requiring user authentication.
FIA_UAU.7 Supports authentication by policy of limited authentication feedback.
FIA_UID.1 Provides authorization by requiring user identification.
O.SOFTWARE.VERIFIED Verification of software integrity
FPT_TST.1 Requires the capability to perform TSF self-tests
O.AUDIT.LOGGED Logging and authorized access to audit events.
FAU_GEN.1 Requires audit logging of relevant events.
FAU_SAR.1 Ensures that audit records can be reviewed by authorized users.
FAU_SAR.2 Supports audit review by preventing unauthorized access.
FAU_STG.1 Supports audit integrity by preventing unauthorized deletion.
FAU_STG.4 Supports audit integrity by policy against loss of records.
FIA_UID.1 Supports audit function by requiring user ID.
FPT_STM.1 Supports audit function by requiring timestamps.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
36
1
2
1
34
IEEE P2600.5/D31b31a, December 2007
8 Scan Protection Profile: P2600.5-SCN
8.1 SCN TOE Overview (APE_INT)
8.1.1 SCN TOE Model
The Scan TOE is composed of the essential input, output, and processing elements required to scan a hardcopy document into an electronic form:
a) An originator inputs User Document Data in hardcopy form to a document handler and supplies User Function Data (e.g. scanning instructions) to the Scan subject through an Interface.
b) The Scan subject receives the User Function Data and scans the hardcopy User Document Data input into softcopy User Document Data, and then sends that User Document Data to its destination (e.g., a network filesystem or email server).
c) The Originator may query or modify User Function Data after submitting a job and before its completion.
The Originator, or one or more Delegates, may retrieve User Document Data from its destination. However, the destination is outside of the TOE.
User Function Data (e.g. scan status) and TSF Data (e.g. job or audit logs) may be created or updated during the Scan process.
The Scan TOE also provides the essential processing elements required to manage the Scan process and its authorized Operators:
d) An Administrator can retrieve, modify, and store TSF Protected Data.
e) An Administrator can retrieve, modify, and store TSF Confidential Data.
f) The Originator may be able to retrieve, modify, and store his own TSF Protected Data or TSF Confidential Data (e.g. operator profile information, operator password).
Additional TSF data (e.g. audit logs) may be created or updated the performance of administrative tasks.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
37
1
2
1
2
3
45678
91011
1213
14151617181920212223
24
2526
2728
34
IEEE P2600.5/D31b31a, December 2007
Figure 9—Scan TOE model
Scan
User
Originator
User Function Data Input HandlerInterface
Hardcopy
Channel
REST
Figure 10 —SCN TOE Administration model
TSF Data
Administrator
User
Originator
Originators may havepermission to access ormodify some TSF Data,such as their own profile,preferences, or passwords.
Channel
Scan
REST
8.1.2 Major security features of the SCN TOE
The major security features of the Scan TOE are:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
38
1
2
1
23
45
6
78
34
IEEE P2600.5/D31b31a, December 2007
a) All operators are identified and authenticated, and are authorized before being granted permission to perform security-related SCN functions.
b) Information associated with processing SCN jobs is protected from alteration by anyone except for the Originator and authorized Administrators.
c) TSF Data, of which unauthorized disclosure threatens operational security, is protected from disclosure to anyone except for the originating operator and authorized Administrators.
d) TSF Data, of which unauthorized alteration threatens operational security, is protected from alteration by anyone except for the originating operator and authorized Administrators.
e) Document processing operations and security-relevant system events (successful and unsuccessful) are recorded, and such records are protected from disclosure or alteration by anyone except for authorized Administrators.
PP APPLICATION NOTE— Additional support for protecting nonvolatile stored data may be supplied by the Nonvolatile Storage TOE (P2600.5-NVS). For evaluation purposes, it should be assumed that nonvolatile storage is not present in the SCN TOE.
8.2 SCN Security problem definition (APE_SPD)
8.2.1 SCN Assets
This section describes the security-relevant assets and asset-state pairs that apply to the SCN TOE. These assets and states are a subset of assets and states defined for the Family of Protection Profiles in 5.5.3, “Objects (Assets)”. A PP application note provides additional information about some assets and states that are associated with the practical function of the SCN TOE but that are not within the scode of the TOE.
Table 20 —User Data assets of the SCN TOEThere are no User Data Assets associated with the SCN TOE that must be protected from either unauthorized disclosure or unauthorized alteration.
PP APPLICATION NOTE – In the case where there are User Data assets status that do need to be protected, it is required that ST authors define those User Data assets for their TOEs and then appropriately categorize those User Data assets according to whether they require protection from unauthorized alteration or protection from both unauthorized disclosure and unauthorized alteration.
Table 21 — TSF Data assets of the SCN TOE
Asset State Name ExamplesTSF Protected Data
In the TOE D.PROT.REST Authentication data, security attributes, selected resources (e.g., fonts) and other security-relevant data in the TOE, which must be protected from unauthorized alteration
TSF Confidential Data
In the TOE D.CONF.RET Authentication data, security attributes, selected resources (e.g., signature files) and other security-relevant data in the TOE, which must be protected from unauthorized disclosure or alteration
PP APPLICATION NOTE – Some of the assets defined in 5.5.3 “Objects (Assets)” are not applicable to the SCN TOE model. Rationale for inapplicability is described in Table 22:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
39
1
2
12
34
56
78
91011
121314
15
16
17181920
21
2223
24252627
28
29
3031
34
IEEE P2600.5/D31b31a, December 2007
Table 22 —Assets not applicable to the SCN TOE
Asset Rationale See alsoD.DOC.TRANSIT Assets in transit are only considered in TOEs that have a shared
medium interface N/A
D.DOC.JOB There is no Operator access to User Document Data after the job has been submitted
NVS
D.DOC.RETRIEVE The SCN TOE does not retain Operator User Document Data after completion of a job
DSR
D.DOC.DELETED Deleted assets are only considered in TOEs that have nonvolatile storage
NVS
D.DOC.OUTPUT There is no hardcopy output handler associated with the SCN TOE
PRT, NVS
D.FUNC.REST The SCN TOE does not have any User Function Data assets that must always be protected from either unauthorized disclosure or alteration while in the TOE.
N/A
D.FUNC.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.PROT.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.CONF.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
8.2.2 SCN Threats
This section describes threats to assets described in the previous section.
Table 23 —Threats to User Data for the SCN TOEThere are no threats associated with User Data that the SCN TOE must be protected from.
Table 24 Threats to TSF Data for the SCN TOE
Threat Affected asset(s) DescriptionT.PROT.REST.ALT D.PROT.REST TSF Protected Data in the TOE may be altered by
unauthorized personsT.CONF.REST.DIS D.CONF.REST TSF Confidential Data in the TOE may be disclosed to
unauthorized personsT.CONF.REST.ALT D.CONF.REST TSF Confidential Data in the TOE may be altered by
unauthorized persons
8.2.3 SCN Organizational Security Policies
This section describes the Organizational Security Policies (OSPs) that apply to the SCN TOE. OSPs are used to provide a basis for security objectives that are commonly desired by TOE owners in this operational environment but for which it is not possible to make uniform defintions of the threats that are being mitigated or the assets that are being threatened.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
40
1
2
1
2
3
4
5
6
7
8
9101112
34
IEEE P2600.5/D31b31a, December 2007
Table 25 —Organizational Security Policies for the SCN TOE
Name DefinitionP.OPERATOR.AUTHORIZATION To preserve accountability, Operators will be authorized to use the
TOE only as permitted by the TOE OwnerP.ADMIN.AUTHORIZATION To preserve security, Administrators will be authorized to manage
the TOE only as permitted by the TOE OwnerP.SOFTWARE.VERIFICATION To detect malicious modification of TOE software, procedures will
exist to verify that the currently installed software in the TOE is consistent with the authorized installed software
P.AUDIT.LOGGING To preserve accountability and security, records that provide an audit trail of TOE use and security-relevant events will be maintained and protected from unauthorized disclosure or alteration by the TOE, and will be reviewed by authorized personnel
8.2.4 SCN Assumptions
The Security Objectives and Security Functional Requirements defined in subsequent sections of this Protection Profile are based on the condition that all of the assumptions described in this section are satisfied.
Table 26 —Assumptions for the SCN TOE
Assumption DefinitionA.LOCATION.SECURITY The TOE is located in secure or monitored area which limits the
opportunity for unauthorized physical access to the TOE.A.OPERATOR.TRAINING Operators are aware of the security policies and procedures of their
organization, and are trained and competent to follow those policies and procedures.
A.OPERATOR.TRUST Operators do not use their privileged access rights for malicious purposes.A.ADMIN.TRAINING Administrators are aware of the security policies and procedures of their
organization, and are trained and competent to follow the manufacturer’s guidance and documentation to configure and operate the TOE in accordance those policies and procedures.
A.ADMIN.TRUST Administrators do not use their privileged access rights for malicious purposes.
8.3 SCN Security objectives (APE_OBJ)
8.3.1 SCN Security objectives
This section describes the security objectives that the SCN TOE shall fulfill.
Table 27 —SCN Security objectives for the TOE
Objective DefinitionO.OPERATOR.AUTHORIZED The TOE shall require identification and authentication of Operators, and
shall ensure that Operators are authorized in accordance with security policies before allowing them to use the TOE.
O.PROT.REST.NO_ALT The TOE shall protect TSF Protected Data in the TOE from unauthorized alteration.
O.CONF.REST.NO_DIS The TOE shall protect TSF Confidential Data in the TOE from unauthorized disclosure.
O.CONF.REST.NO_ALT The TOE shall protect TSF Confidential Data in the TOE from unauthorized alteration.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
41
1
2
1
2
345
6
7
8
9
10
34
IEEE P2600.5/D31b31a, December 2007
Objective DefinitionO.ADMIN.AUTHORIZED The TOE shall require identification and authentication of
Administrators, and shall ensure that Administrators, are authorized in accordance with security policies before allowing them to manage the TOE.
O.SOFTWARE.VERIFIED The TOE shall provide procedures to verify that the currently installed software in the TOE is consistent with the authorized installed TOE software.
O.AUDIT.LOGGED The TOE shall create and maintain a log of TOE use and security-relevant events, and prevent its unauthorized disclosure or alteration.
8.3.2 SCN Security objectives for the development environment
There are no security objectives for the development environment for the SCN TOE.
8.3.3 SCN Objectives for the IT operational environment
There are no security objectives for the IT operational environment for the SCN TOE.
8.3.4 SCN Objectives for the non-IT operational environment
This section describes the security objectives that must be fulfilled by non-IT methods in the operational environment for the SCN TOE.
Table 28 —Non-IT Objectives for the operational environment
Objective DefinitionOE.LOCATION.SECURED The TOE shall be placed in secure or monitored area which limits the
opportunity for unauthorized physical access to the TOE.OE.OPERATOR.TRAINED The TOE owner shall ensure that TOE Operators are aware of the security
policies and procedures of their organization, and have the training and competence to follow those policies and procedures.
OE.OPERATOR.TRUSTED The TOE owner shall take steps to establish trust that TOE Operators will not use their privileged access rights for malicious purposes.
OE.ADMIN.TRAINED The TOE owner shall ensure that TOE Administrators are aware of the security policies and procedures of their organization, and have the training, competence, and time to follow the manufacturer’s guidance and documentation to correctly configure and operate the TOE in accordance those policies and procedures.
OE.ADMIN.TRUSTED The TOE owner shall establish trust that TOE administrators will not use their privileged access rights for malicious purposes.
OE.AUDIT.REVIEWED The TOE owner shall ensure that audit logs are reviewed at appropriate intervals for security violations or unusual patterns of activity.
8.3.5 SCN Security objectives rationale
This section demonstrates that each threat, organizational security policy, and assumption, are mitigated by at least one security objective for the SCN TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
42
1
2
1
2
3
4
5
67
8
9
1011
34
IEEE P2600.5/D31b31a, December 2007
Table 29 —SCN objectives rationale
Threats. Policies, and Assumptions O.P
RO
T.R
EST.
NO
_ALT
O.C
ON
F.R
EST.
NO
_DIS
O.C
ON
F.R
EST.
NO
_ALT
O.O
PER
ATO
R.A
UTH
OR
IZD
O.A
DM
IN.A
UTH
OR
IZED
O.S
OFT
WA
RE.
VER
IFIE
DO
.AU
DIT
.LO
GG
EDO
E.A
UD
IT.R
EVIE
WED
OE.
LOC
ATI
ON
.SEC
UR
EDO
E.A
DM
IN.T
RA
INED
OE.
AD
MIN
.TR
UST
ED
OE.
OPE
RA
TOR
.TR
AIN
ED
OE.
OPE
RA
TOR
.TR
UST
ED
T.PROT.REST.ALT T.CONF.REST.DIS T.CONF.REST.ALT P.OPERATOR.AUTHORIZATION P.ADMIN.AUTHORIZATION P.SOFTWARE.VERIFICATION P.AUDIT.LOGGING A.LOCATION.SECURITY A.ADMIN.TRAINING A.ADMIN.TRUST A.OPERATOR.TRAINING A.OPERATOR.TRUST
8.4 SCN Extended components definition (APE_ECD)
The SCN Protection Profile does not define any extended components.
8.5 SCN Security functional requirements (APE_REQ)
This section defines the security functional policies and requirements for the SCN TOE.
8.5.1 Security Function Policies
The Security Function Policy (SFP) described in this section is referenced in one or more SFR Class sections that follow.
8.5.1.1 SCN Access Control SFP
Table 30 — SCN Access Control SFP
Entity Access control rule(s)U.ORIGINATOR S.SCN authorizes U.ORIGINATOR to bind with S.SCN to create a job and
perform subsequent SCN job operations if granted permission to do so by U.ADMINISTRATOR.
U.ADMINISTRATOR S.SCN requires identification and authentication.S.SCN authorizes U.ADMINISTRATOR to bind with S.SCN to perform SCN management operations if previously granted permission to do so by a U.ADMINISTRATOR.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
43
1
2
1
2
3
4
5
6
78
9
10
34
IEEE P2600.5/D31b31a, December 2007
Entity Access control rule(s)D.PROT.REST S.SCN may read on behalf of any authorized Operator.
S.SCN may write on behalf of U.ADMINISTRATOR.S.SCN may write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
D.CONF.REST S.SCN may read or write on behalf of U.ADMINISTRATOR.S.SCN may read or write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
8.5.2 Class FAU: Security audit
FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
{FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
[assignment:other specifically defined auditable event]. }
FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
events listed in Table 31—SCN Audit data requirements”; assignment:other specifically defined auditable event].
PP APPLICATION NOTE— Table 32—SCN Audit data recommendations” lists additional auditable events that are recommended for consideration in FAU_GEN.1.1
{FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
44
1
2
1
2
4
5
67
8
91011
121314
1516
17
181920
21222324
2526
2728
2930
34
IEEE P2600.5/D31b31a, December 2007
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment:other audit relevant informatio]. }
FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, additional information listed in Table 31—SCN Audit data requirements”; assignment:other audit relevant informatio].
PP APPLICATION NOTE—Table 32—SCN Audit data recommendations” lists additional audit information that is recommended for consideration in FAU_GEN.1.2
Table 31 —SCN Audit data requirements
Auditable event Audit level Additional information Relevant SFRDeletion of audit records None None FAU_SAR.1Audit storage full None None FAU_STG.4Job initiation None Type of job FDP_ACF.1Job completion None Type of job FDP_ACF.1Unsuccessful user authentication Basic None FIA_UAU.1Successful user authentication Basic None FIA_UAU.1Unsuccessful user identification Basic Attempted user identity, if
availableFIA_UID.1
Successful user identification Basic None FIA_UID.1Management function initiation Minimal None FMT_SMF.1Modification of administrative user/role assignments
Minimal None FMT_SMR.1
Set/change system time Minimal None FPT_STM.1
Table 32 —SCN Audit data recommendations
Auditable event Audit level Additional information Relevant SFRJob initiation None Type of job FDP_ACF.1Attempts to authenticate reach failure limit
Minimal User identity, actions taken as a result, and if appropriate, subsequent restoration to the normal state
FIA_AFL.1
PP APPLICATION NOTE— FAU_GEN.1 is a dependency of FAU_SAR.1
PP APPLICATION NOTE— FAU_GEN.1 performs audit recommendations of FAU_SAR.1, FAU_SAR.2, FAU_STG.4, FDP_ACF.1, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UAU.7, FIA_UID.1, FMT_MSA.1, FMT_MSA.3, FMT_MTD.1, FMT_SMF.1, FMT_SMR.1, FPT_STM.1, and FPT_TST.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
45
1
2
1234
56
78
91011121314
1516
17
18
19
20
21222324
34
IEEE P2600.5/D31b31a, December 2007
FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
{FAU_SAR.1.1The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of audit information] from the audit records.}
FAU_SAR.1.1The TSF shall provide [assignment: authorised operators] with the capability to read [assignment: list of audit information] from the audit records.
{FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the user to interpret the information.}
FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the operator to interpret the information.
PP APPLICATION NOTE— FAU_SAR.1 is a dependency of FAU_SAR.2
FAU_SAR.2 Restricted audit review
Hierarchical to: No other components.
Dependencies: FAU_SAR.1 Audit review
FAU_SAR.2.1The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access.
FAU_SAR.2.1The TSF shall prohibit all users read access to the audit records, except those operators that have been granted explicit read-access.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
46
1
2
1
2
4
5
678
91011
121314
151617
18
19
21
22
232425
262728
29
34
IEEE P2600.5/D31b31a, December 2007
FAU_STG.1 Protected audit trail storage
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG.1.1The TSF shall protect the stored audit records in the audit trail from unauthorised deletion.
FAU_STG.1.2The TSF shall be able to [selection, choose one of: prevent, detect] unauthorised modifications to the stored audit records in the audit trail.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.4 Prevention of audit data loss
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
{FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthoriseduserwithspecialrights”,“overwritetheoldest
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
47
1
2
1
3
4
567
89
10
11
12
14
15
16171819202122232425262728293031323334353637383940
34
IEEE P2600.5/D31b31a, December 2007
storedauditrecords”]and[assignment: otheractions to be taken in case of audit storage failure] if the audit trailisfull.}
FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthorisedoperatorwithspecialrights”,“overwritetheoldeststoredauditrecords”]and[assignment: otheractions to be taken in case of audit storage failure] if the audit trailisfull.
PP APPLICATION NOTE— FAU_STG.4 is a requirement which fulfills O.AUDIT.LOGGED
8.5.3 Class FCO: Communication
There are no Class FCO security functional requirements for the SCN Protection Profile.
8.5.4 Class FCS: Cryptographic support
There are no Class FCS security functional requirements for the SCN Protection Profile.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
48
1
2
12345678
91011121314151617181920212223242526272829303132333435363738394041
42
43
44
45
46
34
IEEE P2600.5/D31b31a, December 2007
8.5.5 Class FDP: User data protection
FDP_ACC.1 Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
{FDP_ACC.1.1The TSF shall enforce the [assignment: access control SFP] on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].}
FDP_ACC.1.1The TSF shall enforce the SCN Access Control SFP on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].
PP APPLICATION NOTE— FDP_ACC.1 is a dependency of FMT_MSA.1.
FDP_ACF.1 Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access controlFMT_MSA.3 Static attribute initialisation
{FDP_ACF.1.1The TSF shall enforce the [assignment: access control SFP] to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].}
FDP_ACF.1.1The TSF shall enforce the SCN Access Control SFP to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].
FDP_ACF.1.2The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects].
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
49
1
2
1
2
4
5
678
91011
12
13
15
161718
1920212223
2425262728
2930313233
34
IEEE P2600.5/D31b31a, December 2007
FDP_ACF.1.3The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects].
FDP_ACF.1.4The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].
PP APPLICATION NOTE— FDP_AC F.1 is a dependency of FDP_ACC.1.
8.5.6 Class FIA: Identification and authentication
FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to [assignment: list of authentication events].
FIA_AFL.1.2When the defined number of unsuccessful authentication attempts has been [selection: met, surpassed] the TSF shall [assignment: list of actions].
PP APPLICATION NOTE— FDP_AC C.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_ATD.1.1The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: list of security attributes].}
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
50
1
2
1234
567
8
9
10
12
13
1415161718
192021
2223
24
26
27
282930
34
IEEE P2600.5/D31b31a, December 2007
FIA_ATD.1.1The TSF shall maintain the following list of security attributes belonging to individual operators: [assignment: list of security attributes].
FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_SOS.1.1The TSF shall provide a mechanism to verify that secrets meet [assignment: a defined quality metric].
PP APPLICATION NOTE— FIA_SOS.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
PP APPLICATION NOTE— The suggested minimum for password quality is eight (8) alphanumeric characters.
FIA_UAU.1 Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated.}
FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the operator to be performed before the operator is authenticated.
{FIA_UAU.1.2The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UAU.1.2The TSF shall require each operator to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UAU.1 is a dependency of FIA_AFL.1 and FIA_UAU.7.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
51
1
2
123
4
6
7
89
10
1112
13
14
16
17
181920
212223
242526
272829
30
34
IEEE P2600.5/D31b31a, December 2007
FIA_UAU.7 Protected authentication feedback
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the user while the authentication is in progress.}
FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the operator while the authentication is in progress.
PP APPLICATION NOTE— FIA_UAU.7 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
FIA_UID.1 Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is identified.}
FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the operator to be performed before the operator is identified.
{FIA_UID.1.2The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UID.1.2The TSF shall require each operator to be successfully identified before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UID.1 is a dependency of FIA_UAU.1, and FMT_SMR.1.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
52
1
2
1
3
4
567
89
10
1112
13
15
16
171819
202122
232425
262728
29
34
IEEE P2600.5/D31b31a, December 2007
8.5.7 Class FMT: Security management
FMT_MSA.1 Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, orFDP_IFC.1 Subset information flow control]FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
{FMT_MSA.1.1The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].}
FMT_MSA.1.1The TSF shall enforce the SCN Access Control SFP to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MSA.1 is a dependency of FMT_MSA.3
PP APPLICATION NOTE— FMT_MSA.1 performs management recommendations of FDP_ACF.1
FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributesFMT_SMR.1 Security roles
{FMT_MSA.3.1The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection, choose one of: restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.}
FMT_MSA.3.1The TSF shall enforce the SCN Access Control SFP to provide [selection, choose one of:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
53
1
2
1
2
4
56789
1011121314
1516171819
20
21
22
24
252627
28293031
3233
34
IEEE P2600.5/D31b31a, December 2007
restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial values to override the default values when an object or information is created.
PP APPLICATION NOTE— FMT_MSA.3 is a dependency of FDP_ACF.1
FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations]] the [assignment: list of TSF data] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MTD.1 is a required to fulfill O.PROT.REST.NO_ALT, O.CONF.REST.NO_DIS, O.CONF.REST.NO_ALT
PP APPLICATION NOTE— In typical applications, an U.ADMINISTRATOR can perform operations on most or all TSF data. U.ORIGINATOR can modify some TSF Data when such data was created for that operator (for example, an Operator’s own password). Refer to the SCN Access Control SFP.
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1The TSF shall be capable of performing the following management functions: [assignment: list of management functions to be provided by the TSF].
PP APPLICATION NOTE— the management functions listed in Table 33—SCN Management functionrecommendations” are recommended for consideration in FMT_SMF.1. The ST author should consider specifying other management functions that support administrative functionality of the ST target of evaluation.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
54
1
2
12
3456
7
8
10
111213
14151617
1819
202122
23
25
26
272829
303132
34
IEEE P2600.5/D31b31a, December 2007
Table 33 —SCN Management function recommendations
Management function Relevant SFRMaintenance of group of users who are authorized to access audit records
FAU_SAR.1
Management of the user identities FAU_UID.1Management of system time FPT_STM.1
PP APPLICATION NOTE— FMT_SMF.1 is a dependency of FMT_MSA.1 and FMT_MTD.1
PP APPLICATION NOTE— FMT_MSA.1 performs management recommendations of FDP_ACF.1 FAU_SAR.1, FAU_STG.4, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UID.1, FMT_MSA.1, FMT_MSA.3, FMT_SMR.1, and FPT_STM.1
FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1The TSF shall maintain the roles [assignment: the authorised identified roles].
PP APPLICATION NOTE— recommended minimum to be specified in FMT_SMR.1: Administrator
{FMT_SMR.1.2The TSF shall be able to associate users with roles.}
FMT_SMR.1.2The TSF shall be able to associate operators with roles.
PP APPLICATION NOTE— FMT_SMR.1 is a dependency of FMT_MSA.1, FMT_MSA.3, and FMT_MTD.1.
8.5.8 Class FPR: Privacy
There are no Class FPR security functional requirements for the SCN Protection Profile.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
55
1
2
1
2
3
456
7
9
10
1112
13
1415
1617
18
19
20
34
IEEE P2600.5/D31b31a, December 2007
8.5.9 Class FPT: Protection of the TSF
FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_STM.1.1The TSF shall be able to provide reliable time stamps.
PP APPLICATION NOTE— FPT_STM.1 is a dependency of FAU_GEN.1
FPT_TST.
TSF testin
Hierarchical to: No other components.
Dependencies: No dependencies.
{FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorised user, at theconditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF]}
FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorisedoperator, at theconditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF].
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF data].}
FPT_TST.1.The TSF shall provide authorised
operators with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
56
1
2
1
2
4
5
67
8
91011
14
15
161718192021
222324252627
28293031
32333435
34
IEEE P2600.5/D31b31a, December 2007
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of stored TSF executable code.}
FPT_TST.1.The TSF shall provide authorised
operators with the capability to verify the integrity of stored TSF executable code.
PP APPLICATION NOTE— FPT_TST.1 is a requirement which fulfills O.SOFTWARE.VERIFIED.
8.5.10 Class FRU: Resource utilization
There are no Class FRU security functional requirements for the SCN Protection Profile.
8.5.11 Class FTA: TOE access
There are no Class FTA security functional requirements for the SCN Protection Profile.
8.5.12 Class FTP: Trusted paths/channels
There are no Class FTP security functional requirements for the SCN Protection Profile.
8.6 SCN Security requirements rationale
Table 34 and Table 35demonstrate the completeness and sufficiency of SFRs that fulfill the objectives of the SCN TOE. Bold typefaced items provide primary (P) fulfillment of the objectives, and normal typefaced items are support (S) fulfillment.
Table 34 —Completeness of SCN security requirements
SFR O.P
RO
T.R
EST
.NO
_AL
TO
.CO
NF.
RE
ST.N
O_D
ISO
.CO
NF.
RE
ST.N
O_A
LT
O.O
PER
AT
OR
.AU
TH
OR
IZE
DO
.AD
MIN
.AU
TH
OR
IZE
DO
.SO
FTW
AR
E.V
ER
IFIE
DO
.AU
DIT
.LO
GG
ED
FAU_GEN.1 PFAU_SAR.1 PFAU_SAR.2 SFAU_STG.1 SFAU_STG.4 SFDP_ACC.1 FDP_ACF.1 FIA_AFL.1 S S
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
57
1
2
1234
567
9
10
11
12
13
14
15
16
171819
20
34
IEEE P2600.5/D31b31a, December 2007
SFR O.P
RO
T.R
EST
.NO
_AL
TO
.CO
NF.
RE
ST.N
O_D
ISO
.CO
NF.
RE
ST.N
O_A
LT
O.O
PER
AT
OR
.AU
TH
OR
IZE
DO
.AD
MIN
.AU
TH
OR
IZE
DO
.SO
FTW
AR
E.V
ER
IFIE
DO
.AU
DIT
.LO
GG
ED
FIA_ATD.1 S S FIA_SOS.1 S SFIA_UAU.1 P P FIA_UAU.7 S S FIA_UID.1 S S S P P SFMT_MSA.1 FMT_MSA.3 FMT_MTD.1 P P P FMT_SMF.1 S S S FMT_SMR.1 S S S FPT_STM.1 SFPT.TST.1 P
Table 35 —Sufficiency of SCN security requirements
Objectives Description SFRs PurposeO.CONF.REST.NO_DIS, Protection of
TSF Data from unauthorized disclosure
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1
Prevents disclosure by restricting access.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.PROT.REST.NO_ALT, O.CONF.REST.NO_ALT
Protection of TSF Data from unauthorized alteration
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1
Prevents alteration by restricting access.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.OPERATOR.AUTHORIZED,O.ADMIN.AUTHORIZED
Authorization of users and administrators to use the TOE.
FIA_AFL.1 Supports authorization by policy for handling authentication failures.
FIA_ATD.1 Supports authorization by associating attributes with authorized users.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
58
1
2
1
2
34
IEEE P2600.5/D31b31a, December 2007
Objectives Description SFRs PurposeFIA_SOS.1 Supports authentication by
requiring minimum strength of authentication secrets.
FIA_UAU.1 Provides authorization by requiring user authentication.
FIA_UAU.7 Supports authentication by policy of limited authentication feedback.
FIA_UID.1 Provides authorization by requiring user identification.
O.SOFTWARE.VERIFIED Verification of software integrity
FPT_TST.1 Requires the capability to perform TSF self-tests
O.AUDIT.LOGGED Logging and authorized access to audit events.
FAU_GEN.1 Requires audit logging of relevant events.
FAU_SAR.1 Ensures that audit records can be reviewed by authorized users.
FAU_SAR.2 Supports audit review by preventing unauthorized access.
FAU_STG.1 Supports audit integrity by preventing unauthorized deletion.
FAU_STG.4 Supports audit integrity by policy against loss of records.
FIA_UID.1 Supports audit function by requiring user ID.
FPT_STM.1 Supports audit function by requiring timestamps.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
59
1
2
1
34
IEEE P2600.5/D31b31a, December 2007
9 Copy Protection Profile: P2600.5-CPY
9.1 CPY TOE Overview (APE_INT)
9.1.1 CPY TOE Model
The Copy TOE is composed of the essential input, output, and processing elements required to duplicate a hardcopy document:
a) An Originator inputs User Document Data in hardcopy form to a input document handler, and may supply User Function Data (e.g. copying instructions) through an Interface.
b) The Copy subject receives the User Function Data and duplicates the hardcopy User Document Data input into hardcopy User Document Data output.
c) The Originator retrieves the hardcopy User Document Data from an output document handler.
d) The Originator may query or modify User Function Data after submitting a job and before its completion.
User Function Data (e.g. copy status) and TSF Data (e.g. job or audit logs) may be created or updated during the Copy process.
The Copy TOE also provides the essential processing elements required to manage the Copy process and its authorized Operators:
e) An Administrator can retrieve, modify, and store TSF Protected Data.
f) An Administrator can retrieve, modify, and store TSF Confidential Data.
g) The Originator may be able to retrieve, modify, and store his own TSF Protected Data or TSF Confidential Data (e.g. operator profile information, operator password).
Additional TSF data (e.g. audit logs) may be created or updated the performance of administrative tasks.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
60
1
2
1
2
3
45678
910
11
1213
14151617181920
21
2223
24
34
IEEE P2600.5/D31b31a, December 2007
Figure 11 —Copy TOE model
Copy
User Function Data
User
Originator
Input Handler Output Handler
Hardcopy
Channel
Interface
REST
Figure 12 —CPY TOE Administration model
TSF Data
Administrator
User
Originator
Originators may havepermission to access ormodify some TSF Data,such as their own profile,preferences, or passwords.
Channel
Copy
REST
9.1.2 Major security features of the CPY TOE
The major security features of the Copy TOE are:
a) All operators are identified and authenticated, and are authorized before being granted permission to perform security-related CPY functions.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
61
1
2
1
23
456
7
89
1011
34
IEEE P2600.5/D31b31a, December 2007
b) Information associated with processing CPY jobs is protected from alteration by anyone except for the Originator and authorized Administrators.
c) TSF Data, of which unauthorized disclosure threatens operational security, is protected from disclosure to anyone except for the originating operator and authorized Administrators.
d) TSF Data, of which unauthorized alteration threatens operational security, is protected from alteration by anyone except for the originating operator and authorized Administrators.
e) Document processing operations and security-relevant system events (successful and unsuccessful) are recorded, and such records are protected from disclosure or alteration by anyone except for authorized administrators.
PP APPLICATION NOTE— Additional support for protecting nonvolatile stored data may be supplied by the Nonvolatile Storage TOE (P2600.5-NVS). For evaluation purposes, it should be assumed that nonvolatile storage is not present in the CPY TOE.
9.2 CPY Security problem definition (APE_SPD)
9.2.1 CPY Assets
This section describes the security-relevant assets and asset-state pairs that apply to the CPY TOE. These assets and states are a subset of assets and states defined for the Family of Protection Profiles in 5.5.3, “Objects (Assets)”. A PP application note provides additional information about some assets and states that are associated with the practical function of the CPY TOE but that are not within the scode of the TOE.
Table 36 —User Data assets of the CPY TOEThere are no User Data Assets associated with the CPY TOE that must be protected from either unauthorized disclosure or unauthorized alteration.
PP APPLICATION NOTE – In the case where there are User Data assets that need to be protected, it is required that ST authors define those User Data assets for their TOEs and then appropriately categorize those User Data assets according to whether they require protection from unauthorized alteration or protection from both unauthorized disclosure and unauthorized alteration.
Table 37 TSF Data assets of the CPY TOE
Asset State Name ExamplesTSF Protected Data
In the TOE D.PROT.REST Authentication data, security attributes, selected resources (e.g., fonts) and other security-relevant data in the TOE, which must be protected from unauthorized alteration
TSF Confidential Data
In the TOE D.CONF.REST Authentication data, security attributes, selected resources (e.g., signature files) and other security-relevant data in the TOE, which must be protected from unauthorized disclosure or alteration
PP APPLICATION NOTE – Some of the assets defined in 5.5.3 “Objects (Assets)” are not applicable to the CPY TOE model. Rationale for inapplicability is described in Table 38:
Table 38 —Assets not applicable to the CPY TOE
Asset Rationale See alsoD.DOC.TRANSIT Assets in transit are only considered in TOEs that have a
shared medium interface N/A
D.DOC.JOB There is no User access to User Document Data after the job has been submitted
NVS
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
62
1
2
12
34
56
789
101112
13
14
15161718
19
2021
22232425
26
2728
29
34
IEEE P2600.5/D31b31a, December 2007
Asset Rationale See alsoD.DOC.RETRIEVE The CPY TOE does not retain User User Document Data after
completion of a jobDSR
D.DOC.DELETED Deleted assets are only considered in TOEs that have nonvolatile storage
NVS
D.DOC.OUTPUT The hardcopy output handler is not considered in the CPY TOE because the originating Operator is physically present when User Document Data are supplied to the hardcopy input handler.
PRT, NVS
D.FUNC.REST The CPY TOE does not have any User Function Data assets that must always be protected from either unauthorized disclosure or alteration while in the TOE.
N/A
D.FUNC.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.PROT.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.CONF.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
9.2.2 CPY Threats
This section describes threats to assets described in the previous section.
Table 39 —Threats to User Data for the CPY TOEThere are no threats associated with User Data that the CPY TOE must be protected from.
Table 40 — Threats to TSF Data for the CPY TOE
Threat Affected asset(s) DescriptionT.PROT.REST.ALT D.PROT.REST TSF Protected Data in the TOE may be altered by
unauthorized personsT.CONF.REST.DIS D.CONF.REST TSF Confidential Data in the TOE may be disclosed to
unauthorized personsT.CONF.REST.ALT D.CONF.REST TSF Confidential Data in the TOE may be altered by
unauthorized persons
9.2.3 CPY Organizational Security Policies
This section describes the Organizational Security Policies (OSPs) that apply to the CPY TOE. OSPs are used to provide a basis for security objectives that are commonly desired by TOE owners in this operational environment but for which it is not possible to make uniform defintions of the threats that are being mitigated or the assets that are being threatened.
Table 41 Organizational Security Policies for the CPY TOE
Name DefinitionP.OPERATOR.AUTHORIZATION To preserve accountability, Operators will be authorized to use the
TOE only as permitted by the TOE OwnerP.ADMIN.AUTHORIZATION To preserve security, Administrators will be authorized to manage
the TOE only as permitted by the TOE OwnerP.SOFTWARE.VERIFICATION To detect malicious modification of TOE software, procedures will
exist to verify that the currently installed software in the TOE is consistent with the authorized installed software
P.AUDIT.LOGGING To preserve accountability and security, records that provide an audit trail of TOE use and security-relevant events will be
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
63
1
2
1
2
3
45
6
7
89
1011
12
34
IEEE P2600.5/D31b31a, December 2007
maintained and protected from unauthorized disclosure or alteration by the TOE, and will be reviewed by authorized personnel
9.2.4 CPY Assumptions
The Security Objectives and Security Functional Requirements defined in subsequent sections of this Protection Profile are based on the condition that all of the assumptions described in this section are satisfied.
Table 42 —Assumptions for the CPY TOE
Assumption DefinitionA.LOCATION.SECURITY The TOE is located in secure or monitored area which limits the
opportunity for unauthorized physical access to the TOE.A.OPERATOR.TRAINING Operators are aware of the security policies and procedures of their
organization, and are trained and competent to follow those policies and procedures.
A.OPERATOR.TRUST Operators do not use their privileged access rights for malicious purposes.A.ADMIN.TRAINING Administrators are aware of the security policies and procedures of their
organization, and are trained and competent to follow the manufacturer’s guidance and documentation to configure and operate the TOE in accordance those policies and procedures.
A.ADMIN.TRUST Administrators do not use their privileged access rights for malicious purposes.
9.3 CPY Security objectives (APE_OBJ)
9.3.1 CPY Security objectives
This section describes the security objectives that the CPY TOE shall fulfill.
Table 43 —CPY Security objectives for the TOE
Objective DefinitionO.OPERATOR.AUTHORIZED The TOE shall require identification and authentication of Operators, and
shall ensure that Operators are authorized in accordance with security policies before allowing them to use the TOE.
O.PROT.REST.NO_ALT The TOE shall protect TSF Protected Data in the TOE from unauthorized alteration.
O.CONF.REST.NO_DIS The TOE shall protect TSF Confidential Data in the TOE from unauthorized disclosure.
O.CONF.REST.NO_ALT The TOE shall protect TSF Confidential Data in the TOE from unauthorized alteration.
O.ADMIN.AUTHORIZED The TOE shall require identification and authentication of Administrators, and shall ensure that Administrators, are authorized in accordance with security policies before allowing them to manage the TOE.
O.SOFTWARE.VERIFIED The TOE shall provide procedures to verify that the currently installed software in the TOE is consistent with the authorized installed TOE software.
O.AUDIT.LOGGED The TOE shall create and maintain a log of TOE use and security-relevant events, and prevent its unauthorized disclosure or alteration.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
64
1
2
1
234
5
6
7
8
9
34
IEEE P2600.5/D31b31a, December 2007
9.3.2 CPY Security objectives for the development environment
There are no security objectives for the development environment for the CPY TOE.
9.3.3 CPY Objectives for the IT operational environment
There are no IT Objectives for the operational environment for the CPY TOE.
9.3.4 CPY Objectives for the non-IT operational environment
This section describes the security objectives that must be fulfilled by non-IT methods in the operational environment for the CPY TOE.
Table 44 —Non-IT Objectives for the operational environment
Objective DefinitionOE.LOCATION.SECURED The TOE shall be placed in secure or monitored area which limits the
opportunity for unauthorized physical access to the TOE.OE.OPERATOR.TRAINED The TOE owner shall ensure that TOE Operators are aware of the security
policies and procedures of their organization, and have the training and competence to follow those policies and procedures.
OE.OPERATOR.TRUSTED The TOE owner shall take steps to establish trust that TOE Operators will not use their privileged access rights for malicious purposes.
OE.ADMIN.TRAINED The TOE owner shall ensure that TOE Administrators are aware of the security policies and procedures of their organization, and have the training, competence, and time to follow the manufacturer’s guidance and documentation to correctly configure and operate the TOE in accordance those policies and procedures.
OE.ADMIN.TRUSTED The TOE owner shall establish trust that TOE administrators will not use their privileged access rights for malicious purposes.
OE.AUDIT.REVIEWED The TOE owner shall ensure that audit logs are reviewed at appropriate intervals for security violations or unusual patterns of activity.
9.3.5 CPY Security objectives rationale
This section demonstrates that each threat, organizational security policy, and assumption, are mitigated by at least one security objective for the CPY TOE.
Table 45 — CPY objectives rationale
Threats, Policies, and Assumptions O.P
RO
T.R
EST.
NO
_ALT
O.C
ON
F.R
EST.
NO
_DIS
O.C
ON
F.R
EST.
NO
_ALT
O.O
PER
ATO
R.A
UTH
OR
IZD
O.A
DM
IN.A
UTH
OR
IZED
O.S
OFT
WA
RE.
VER
IFIE
D
O.A
UD
IT.L
OG
GED
OE.
AU
DIT
.REV
IEW
EDO
E.LO
CA
TIO
N.S
ECU
RED
OE.
AD
MIN
.TR
AIN
ED
OE.
AD
MIN
.TR
UST
ED
OE.
OPE
RA
TOR
.TR
AIN
ED
OE.
OPE
RA
TOR
.TR
UST
ED
T.PROT.REST.ALT T.CONF.REST.DIS T.CONF.REST.ALT P.OPERATOR.AUTHORIZATION
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
65
1
2
1
2
3
4
5
67
8
9
1011
12
34
IEEE P2600.5/D31b31a, December 2007
Threats, Policies, and Assumptions O.P
RO
T.R
EST.
NO
_ALT
O.C
ON
F.R
EST.
NO
_DIS
O.C
ON
F.R
EST.
NO
_ALT
O.O
PER
ATO
R.A
UTH
OR
IZD
O.A
DM
IN.A
UTH
OR
IZED
O.S
OFT
WA
RE.
VER
IFIE
D
O.A
UD
IT.L
OG
GED
OE.
AU
DIT
.REV
IEW
EDO
E.LO
CA
TIO
N.S
ECU
RED
OE.
AD
MIN
.TR
AIN
ED
OE.
AD
MIN
.TR
UST
ED
OE.
OPE
RA
TOR
.TR
AIN
ED
OE.
OPE
RA
TOR
.TR
UST
ED
P.ADMIN.AUTHORIZATION P.SOFTWARE.VERIFICATION P.AUDIT.LOGGING A.LOCATION.SECURITY A.ADMIN.TRAINING A.ADMIN.TRUST A.OPERATOR.TRAINING A.OPERATOR.TRUST
9.4 CPY Extended components definition (APE_ECD)
The CPY Protection Profile does not define any extended components.
9.5 CPY Security functional requirements (APE_REQ)
This section defines the security functional policies and requirements for the CPY TOE.
9.5.1 Security Function Policies
The Security Function Policy (SFP) described in this section is referenced in one or more SFR Class sections that follow.
9.5.1.1 CPY Access Control SFP
Table 46 — CPY Access Control SFP
Entity Access control rule(s)U.ORIGINATOR S.CPY authorizes U.ORIGINATOR to bind with S.CPY to create a job and
perform subsequent CPY job operations if granted permission to do so by U.ADMINISTRATOR.
U.ADMINISTRATOR S.CPY requires identification and authentication.S.CPY authorizes U.ADMINISTRATOR to bind with S.CPY to perform CPY management operations if previously granted permission to do so by a U.ADMINISTRATOR.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
66
1
2
1
2
3
4
5
67
8
9
34
IEEE P2600.5/D31b31a, December 2007
Entity Access control rule(s)D.DOC.JOB S.CPY may delete on behalf of U.ADMINISTRATOR.
S.CPY may delete on behalf of U.ORIGINATOR.S.CPY may read or write on behalf of U.ORIGINATOR if data was created on behalf of U.ORIGINATOR.S.CPY may read on behalf of U.DELEGATE if authorized by U.ADMINISTRATOR.S.CPY may read on behalf of U.DELEGATE if authorized by U.ORIGINATOR and if data was created on behalf of U.ORIGINATOR.
D.PROT.REST S.CPY may read on behalf of any authorized Operator.S.CPY may write on behalf of U.ADMINISTRATOR.S.CPY may write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
D.CONF.REST S.CPY may read or write on behalf of U.ADMINISTRATOR.S.CPY may read or write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
9.5.2 Class FAU: Security audit
FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
{FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
[assignment:other specifically defined auditable event]. }
FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
events listed in Table 47—CPY Audit data requirements”; assignment:other specifically defined auditable event].
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
67
1
2
1
2
4
5
67
8
91011
121314
1516
17
181920
21222324
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— Table 48—CPY Audit data recommendations” lists additional auditable events that are recommended for consideration in FAU_GEN.1.1
{FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment:other audit relevant informatio]. }
FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, additional information listed in Table 47—CPY Audit data requirements”; assignment:other audit relevant informatio].
PP APPLICATION NOTE— Table 48—CPY Audit data recommendations” lists additional audit information that is recommended for consideration in FAU_GEN.1.2
Table 47 —CPY Audit data requirements
Auditable event Audit level Additional information Relevant SFRDeletion of audit records None None FAU_SAR.1Audit storage full None None FAU_STG.4Job initiation None Type of job FDP_ACF.1Job completion None Type of job FDP_ACF.1Unsuccessful user authentication Basic None FIA_UAU.1Successful user authentication Basic None FIA_UAU.1Unsuccessful user identification Basic Attempted user identity, if
availableFIA_UID.1
Successful user identification Basic None FIA_UID.1Management function initiation Minimal None FMT_SMF.1Modification of administrative user/role assignments
Minimal None FMT_SMR.1
Set/change system time Minimal None FPT_STM.1Unsuccessful attempt to use trusted path Minimal Attempted machine
identify, if availableFTP_TRP.1
Table 48 —CPY Audit data recommendations
Auditable event Audit level Additional information Relevant SFRJob initiation None Type of job FDP_ACF.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
68
1
2
12
34
56
789
10
1112
1314
151617181920
2122
23
24
25
34
IEEE P2600.5/D31b31a, December 2007
Attempts to authenticate reach failure limit
Minimal User identity, actions taken as a result, and if appropriate, subsequent restoration to the normal state
FIA_AFL.1
PP APPLICATION NOTE— FAU_GEN.1 is a dependency of FAU_SAR.1
PP APPLICATION NOTE— FAU_GEN.1 performs audit recommendations of FAU_SAR.1, FAU_SAR.2, FAU_STG.4, FDP_ACF.1, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UAU.7, FIA_UID.1, FMT_MSA.1, FMT_MSA.3, FMT_MTD.1, FMT_SMF.1, FMT_SMR.1, FPT_STM.1, and FPT_TST.1
FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
{FAU_SAR.1.1The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of audit information] from the audit records.}
FAU_SAR.1.1The TSF shall provide [assignment: authorised operators] with the capability to read [assignment: list of audit information] from the audit records.
{FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the user to interpret the information.}
FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the operator to interpret the information.
PP APPLICATION NOTE— FAU_SAR.1 is a dependency of FAU_SAR.2
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
69
1
2
1
2345
6
8
9
101112
131415
161718
192021
22
34
IEEE P2600.5/D31b31a, December 2007
FAU_SAR.2 Restricted audit review
Hierarchical to: No other components.
Dependencies: FAU_SAR.1 Audit review
{FAU_SAR.2.1The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access.}
FAU_SAR.2.1The TSF shall prohibit all users read access to the audit records, except those operators that have been granted explicit read-access.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.1 Protected audit trail storage
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG.1.1The TSF shall protect the stored audit records in the audit trail from unauthorised deletion.
FAU_STG.1.2The TSF shall be able to [selection, choose one of: prevent, detect] unauthorised modifications to the stored audit records in the audit trail.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.4 Prevention of audit data loss
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
{FAU_STG.4.1The TSF shall[selection,choose
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
70
1
2
1
3
4
567
89
10
11
12
14
15
161718
192021
22
23
25
26
27282930
34
IEEE P2600.5/D31b31a, December 2007
oneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthoriseduserwithspecialrights”,“overwritetheoldeststoredauditrecords”]and [assignment: otheractions to be taken in case of audit storage failure] if the audit trailisfull.}
FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthorisedoperatorwithspecialrights”,“overwritetheoldeststored
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
71
1
2
123456789
10111213141516171819202122232425262728
2930313233343536373839404142434445464748495051525354
34
IEEE P2600.5/D31b31a, December 2007
auditrecords”]and [assignment: otheractions to be taken in case of audit storage failure] if the audit trailisfull.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
9.5.3 Class FCO: Communication
There are no Class FCO security functional requirements for the CPY Protection Profile.
9.5.4 Class FCS: Cryptographic support
There are no Class FCS security functional requirements for the CPY Protection Profile.
9.5.5 Class FDP: User data protection
FDP_ACC.1 Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
{FDP_ACC.1.1The TSF shall enforce the [assignment: access control SFP] on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].}
FDP_ACC.1.1The TSF shall enforce the CPY Access Control SFP on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].
PP APPLICATION NOTE— FDP_AC C.1 is a dependency of FMT_MSA.1.
FDP_ACF.1 Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access controlFMT_MSA.3 Static attribute initialisation
{FDP_ACF.1.1The TSF shall enforce the [assignment: access control SFP] to objects based on the
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
72
1
2
123456
7
8
9
10
11
12
13
15
16
171819
202122
23
24
26
2728
2930
34
IEEE P2600.5/D31b31a, December 2007
following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].}
FDP_ACF.1.1The TSF shall enforce the CPY Access Control SFP to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].
FDP_ACF.1.2The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects].
FDP_ACF.1.3The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects].
FDP_ACF.1.4The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].
PP APPLICATION NOTE— FDP_AC F.1 is a dependency of FDP_ACC.1.
9.5.6 Class FIA: Identification and authentication
FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to [assignment: list of authentication events].
FIA_AFL.1.2When the defined number of unsuccessful authentication attempts has been selection: met, surpassed] the TSF shall [assignment: list of actions].
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
73
1
2
123
45678
910111213
14151617
181920
21
22
23
25
26
2728293031
323334
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— FDP_AC C.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_ATD.1.1The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: list of security attributes].}
FIA_ATD.1.1The TSF shall maintain the following list of security attributes belonging to individual operators: [assignment: list of security attributes].
FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_SOS.1.1The TSF shall provide a mechanism to verify that secrets meet [assignment: a defined quality metric].
PP APPLICATION NOTE— FIA_SOS.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
PP APPLICATION NOTE— The suggested minimum for password quality is eight (8) alphanumeric characters.
FIA_UAU.1 Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated.}
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
74
1
2
12
3
5
6
789
101112
13
15
16
171819
2021
22
23
25
26
272829
34
IEEE P2600.5/D31b31a, December 2007
FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the operator to be performed before the operator is authenticated.
{FIA_UAU.1.2The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UAU.1.2The TSF shall require each operator to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UAU.1 is a dependency of FIA_AFL.1 and FIA_UAU.7.
FIA_UAU.7 Protected authentication feedback
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the user while the authentication is in progress.}
FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the operator while the authentication is in progress.
PP APPLICATION NOTE— FIA_UAU.7 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
FIA_UID.1 Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is identified.}
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
75
1
2
123
456
789
10
11
13
14
151617
181920
2122
23
25
26
272829
34
IEEE P2600.5/D31b31a, December 2007
FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the operator to be performed before the operator is identified.
{FIA_UID.1.2The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UID.1.2The TSF shall require each operator to be successfully identified before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UID.1 is a dependency of FIA_UAU.1, and FMT_SMR.1.
9.5.7 Class FMT: Security management
FMT_MSA.1 Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, orFDP_IFC.1 Subset information flow control]FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
{FMT_MSA.1.1The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].}
FMT_MSA.1.1The TSF shall enforce the CPY Access Control SFP to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MSA.1 is a dependency of FMT_MSA.3
PP APPLICATION NOTE— FMT_MSA.1 performs management recommendations of FDP_ACF.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
76
1
2
123
456
789
10
11
12
14
1516171819
2021222324
2526272829
30
31
34
IEEE P2600.5/D31b31a, December 2007
FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributesFMT_SMR.1 Security roles
{FMT_MSA.3.1The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection, choose one of: restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.}
FMT_MSA.3.1The TSF shall enforce the CPY Access Control SFP to provide [selection, choose one of: restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial values to override the default values when an object or information is created.
PP APPLICATION NOTE— FMT_MSA.3 is a dependency of FDP_ACF.1
FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations]] the [assignment: list of TSF data] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MTD.1 is a required to fulfill O.PROT.REST.NO_ALT, O.CONF.REST.NO_DIS, O.CONF.REST.NO_ALT
PP APPLICATION NOTE— In typical applications, an U.ADMINISTRATOR can perform operations on most or all TSF data. U.ORIGINATOR can modify some TSF Data when such data was created for that operator (for example, an Operator’s own password). Refer to the CPY Access Control SFP.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
77
1
2
1
3
456
789
10
11121314
15161718
19
20
22
232425
26272829
3031
323334
34
IEEE P2600.5/D31b31a, December 2007
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1The TSF shall be capable of performing the following management functions: [assignment: list of management functions to be provided by the TSF].
PP APPLICATION NOTE— the management functions listed in “Table 49—CPY Management functionrecommendations” are recommended for consideration in FMT_SMF.1. The ST author should consider specifying other management functions that support administrative functionality of the ST target of evaluation.
Table 49 —CPY Management function recommendations
Management function Relevant SFRMaintenance of group of users who are authorized to access audit records
FAU_SAR.1
Management of the user identities FAU_UID.1Management of system time FPT_STM.1
PP APPLICATION NOTE— FMT_SMF.1 is a dependency of FMT_MSA.1 and FMT_MTD.1
PP APPLICATION NOTE— FMT_MSA.1 performs management recommendations of FDP_ACF.1 FAU_SAR.1, FAU_STG.4, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UID.1, FMT_MSA.1, FMT_MSA.3, FMT_SMR.1, and FPT_STM.1
FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1The TSF shall maintain the roles [assignment: the authorised identified roles].
PP APPLICATION NOTE— recommended minimum to be specified in FMT_SMR.1: Administrator
{FMT_SMR.1.2The TSF shall be able to associate users with roles.}
FMT_SMR.1.2The TSF shall be able to associate operators with roles.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
78
1
2
1
3
4
567
89
10
11
12
13
141516
17
19
20
2122
23
2425
2627
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— FMT_SMR.1 is a dependency of FMT_MSA.1, FMT_MSA.3, and FMT_MTD.1.
9.5.8 Class FPR: Privacy
There are no Class FPR security functional requirements for the CPY Protection Profile.
9.5.9 Class FPT: Protection of the TSF
FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_STM.1.1The TSF shall be able to provide reliable time stamps.
PP APPLICATION NOTE— FPT_STM.1 is a dependency of FAU_GEN.1
FPT_TST.
TSF testin
Hierarchical to: No other components.
Dependencies: No dependencies.
{FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorised user, at theconditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF]}
FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorisedoperator, at theconditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF].
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF data]}
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
79
1
2
1
2
3
4
5
7
8
910
11
121314
17
18
192021222324
252627282930
31323334
34
IEEE P2600.5/D31b31a, December 2007
FPT_TST.1.The TSF shall provide authorised
operator with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of stored TSF executable code}
FPT_TST.1.The TSF shall provide authorised
operator with the capability to verify the integrity of stored TSF executable code.
PP APPLICATION NOTE— FPT_TST.1 is a requirement which fulfills O.SOFTWARE.VERIFIED.
9.5.10 Class FRU: Resource utilization
There are no Class FRU security functional requirements for the CPY Protection Profile.
9.5.11 Class FTA: TOE access
There are no Class FTA security functional requirements for the CPY Protection Profile.
9.5.12 Class FTP: Trusted paths/channels
There are no Class FTP security functional requirements for the CPY Protection Profile.
9.6 CPY Security requirements rationale
Table 50 and Table 51 demonstrate the completeness and sufficiency of SFRs that fulfill the objectives of the CPY TOE. Bold typefaced items provide primary (P) fulfillment of the objectives, and normal typefaced items are support (S) fulfillment.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
80
1
2
12345
6789
11121314
16
17
18
19
20
21
22
23
242526
34
IEEE P2600.5/D31b31a, December 2007
Table 50 —Completeness of CPY security requirements
SFR O.P
RO
T.R
EST
.NO
_AL
T
O.C
ON
F.R
EST
.NO
_DIS
O.C
ON
F.R
EST
.NO
_AL
T
O.O
PER
AT
OR
.AU
TH
OR
IZE
DO
.AD
MIN
.AU
TH
OR
IZE
D
O.S
OFT
WA
RE
.VE
RIF
IED
O.A
UD
IT.L
OG
GE
DFAU_GEN.1 PFAU_SAR.1 PFAU_SAR.2 SFAU_STG.1 SFAU_STG.4 SFDP_ACC.1 FDP_ACF.1 FIA_AFL.1 S S FIA_ATD.1 S S FIA_SOS.1 S SFIA_UAU.1 P P FIA_UAU.7 S S FIA_UID.1 S S S P P SFIA_USB.1 P P FMT_MSA.1 FMT_MSA.3 FMT_MTD.1 P P P FMT_SMF.1 S S S FMT_SMR.1 S S S FPT_AMT.1 SFPT_STM.1 SFPT_TST.1 P
Table 51 —Sufficiency of CPY security requirements
Objectives Description SFRs PurposeO.CONF.REST.NO_DIS, Protection of
TSF Data from unauthorized disclosure
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1 Prevents disclosure by restricting access.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
81
1
2
1
2
3
4
34
IEEE P2600.5/D31b31a, December 2007
Objectives Description SFRs PurposeO.PROT.REST.NO_ALT, O.CONF.REST.NO_ALT
Protection of TSF Data from unauthorized alteration
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1 Prevents alteration by restricting access.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.USER.AUTHORIZED,O.ADMIN.AUTHORIZED
Authorization of users and administrators to use the TOE.
FIA_AFL.1 Supports authorization by policy for handling authentication failures.
FIA_ATD.1 Supports authorization by associating attributes with authorized users.
FIA_SOS.1 Supports authentication by requiring minimum strength of authentication secrets.
FIA_UAU.1 Provides authorization by requiring user authentication.
FIA_UAU.7 Supports authentication by policy of limited authentication feedback.
FIA_UID.1 Provides authorization by requiring user identification.
O.SOFTWARE.VERIFIED Verification of software integrity
FPT_TST.1 Requires the capability to perform TSF self-tests
O.AUDIT.LOGGED Logging and authorized access to audit events.
FAU_GEN.1 Requires audit logging of relevant events.
FAU_SAR.1 Ensures that audit records can be reviewed by authorized users.
FAU_SAR.2 Supports audit review by preventing unauthorized access.
FAU_STG.1 Supports audit integrity by preventing unauthorized deletion.
FAU_STG.4 Supports audit integrity by policy against loss of records.
FIA_UID.1 Supports audit function by requiring user ID.
FPT_STM.1 Supports audit function by requiring timestamps.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
82
1
2
12
34
IEEE P2600.5/D31b31a, December 2007
10 Document Storage and Retrieval Protection Profile: P2600.5-DSR
10.1 DSR TOE Overview (APE_INT)
10.1.1 DSR TOE Model
The Document Storage and Retrieval TOE is composed of the essential processing elements required to store and retrieve an electronic copy of a document:
a) An Originator stores a Document in the TOE through a channel and may supply User Function Data (e.g. storage or Delegate access instructions).
b) The Originator or an authorized Delegate retrieves User Document Data from the TOE.
c) The Originator or Delegate may query or modify User Function Data after submitting a job and before its completion.
User Function Data (e.g. storage or retrieval instructions) and TSF Data (e.g. job or audit logs) may be created or updated during the Document Storage and Retrieval process.
PP APPLICATION NOTE— The DSR TOE does not specify the channels through which Operators may store and retrieve User Document Data or the interfaces through which they may supply or demand User Function Data. In practice, the DSR TOE depends upon the presence of one or more of the PRT, SCN, and CPY TOEs to complete its function, and will use the channel(s) and interface(s) provided by that or those TOEs. For purposes of evaluation, it should be assumed that the DSR TOE receives and produces User Document Data in electronic form.
The Document Storage and Retrieval TOE also provides the essential processing elements required to manage the Document Storage and Retrieval process and it’s authorized Operators:
d) An Administrator can retrieve, modify, and store TSF Protected Data.
e) An Administrator can retrieve, modify, and store TSF Confidential Data.
f) An Originator may be able to retrieve, modify, and store his own TSF Protected Data or TSF Confidential Data (e.g. operator profile information, operator password, access controls for his own User Document Data).
Additional TSF data (e.g. audit logs) may be created or updated the performance of administrative tasks.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
83
1
2
1
2
3
45678
9
1011
1213
14151617181920212223
24
252627
2829
34
IEEE P2600.5/D31b31a, December 2007
Figure 13 —Document Storage and Retrieval TOE model
Doc. Store/Retrieve
User
Originator
RETREIVE
User Document Data User Function Data
Channel
Delegate
REST
Figure 14 —DSR TOE Administration model
TSF Data
Administrator
User
Originator
Originators may havepermission to access ormodify some TSF Data,such as their own profile,preferences, or passwords.
Channel
Doc. Store/ Retrieve
REST
Interface
10.1.2 Major security features of the DSR TOE
The major security features of the Document Storage and Retrieval TOE are:
a) All operators are identified and authenticated, and are authorized before being granted permission to perform security-related DSR functions.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
84
1
2
1
23
45
6
789
10
34
IEEE P2600.5/D31b31a, December 2007
b) Information associated with processing DSR jobs is protected from alteration by anyone except for the Originator, authorized Delegates, and authorized Administrators.
c) TSF Data, of which unauthorized disclosure threatens operational security, is protected from disclosure to anyone except for the originating operator and authorized Administrators.
d) TSF Data, of which unauthorized alteration threatens operational security, is protected from alteration by anyone except for the originating user and authorized Administrators.
e) Document processing operations and security-relevant system events (successful and unsuccessful) are recorded, and such records are protected from disclosure or alteration by anyone except for authorized administrators.
PP APPLICATION NOTE— Additional support for protecting nonvolatile stored data may be supplied by the Nonvolatile Storage TOE (P2600.5-NVS). For evaluation purposes, it should be assumed that nonvolatile storage is not present in the DSR TOE.
10.2 DSR Security problem definition (APE_SPD)
10.2.1 DSR Assets
This section describes the security-relevant assets and asset-state pairs that apply to the DSR TOE. These assets and states are a subset of assets and states defined for the Family of Protection Profiles in 5.5.3, “Objects (Assets)”. A PP application note provides additional information about some assets and states that are associated with the practical function of the DSR TOE but that are not within the scode of the TOE.
Table 52 User Data assets of the DSR TOE
Asset State Name ExamplesUser Document Data
Stored in the TOE
D.DOC.RETRIEVE User Document Data in the TOE after completing a job and retrievable by a new job
There are no User Function Data Assets associated with the PRT TOE that must be protected from either unauthorized disclosure or unauthorized alteration.
PP APPLICATION NOTE – In the case where User Function Data assets such as job instructions or job status inquiries do need to be protected, it is required that ST authors define those User Function Data assets for their TOEs and then appropriately categorize those assets according to whether they require protection from unauthorized alteration or protection from both unauthorized disclosure and unauthorized alteration.
Table 53 TSF Data assets of the DSR TOE
Asset State Name ExamplesTSF Protected Data
In the TOE D.PROT.REST Authentication data, security attributes, and other security-relevant data in the TOE, which must be protected from unauthorized alteration
TSF Confidential Data
In the TOE D.CONF.REST Authentication data, security attributes, and other security-relevant data in the TOE, which must be protected from unauthorized disclosure or alteration
PP APPLICATION NOTE – Some of the assets defined in 5.5.3 “Objects (Assets)” are not applicable to the DSR TOE model. Rationale for inapplicability is described in Table 54:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
85
1
2
12
34
56
789
10111213
14
15
16171819
20
2122
2324252627
28
2930
34
IEEE P2600.5/D31b31a, December 2007
Table 54 —Assets not applicable to the DSR TOE
Asset Rationale See alsoD.DOC.TRANSIT Assets in transit are only considered in TOEs that have a
shared medium interface N/A
D.DOC.JOB There is no Operator access to User Document Data after the job has been submitted. In the DSR TOE, User Document Data is only accessible in the RETRIEVE state after it has been submitted by a previous job.
NVS
D.DOC.DELETED Deleted assets are only considered in TOEs that have nonvolatile storage
NVS
D.DOC.OUTPUT There is no hardcopy output handler associated with the DSR TOE
PRT, NVS
D.FUNC.REST The DSR TOE does not have any User Function Data assets that must always be protected from either unauthorized disclosure or alteration while they are in the TOE.
N/A
D.FUNC.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.PROT.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.CONF.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
10.2.2 DSR Threats
This section describes threats to assets described in the previous section.
Table 55 —Threats to User Data for the DSR TOE
Threat Affected asset(s) DescriptionT.DOC.RETRIEVE.DIS D.DOC.RETRIEVE User Document Data that are retrievable from the TOE
may be disclosed to unauthorized personsT.DOC.RETRIEVE.ALT D.DOC.RETRIEVE User Document Data that are retrievable from the TOE
may be altered by unauthorized persons
Table 56 Threats to TSF Data for the DSR TOE
Threat Affected asset(s) DescriptionT.PROT.REST.ALT D.PROT.REST TSF Protected Data in the TOE may be altered by
unauthorized personsT.CONF.REST.DIS D.CONF.REST TSF Confidential Data in the TOE may be disclosed to
unauthorized personsT.CONF.REST.ALT D.CONF.REST TSF Confidential Data in the TOE may be altered by
unauthorized persons
10.2.3 DSR Organizational Security Policies
This section describes the Organizational Security Policies (OSPs) that apply to the DSR TOE. OSPs are used to provide a basis for security objectives that are commonly desired by TOE owners in this operational environment but for which it is not possible to make uniform defintions of the threats that are being mitigated or the assets that are being threatened.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
86
1
2
1
2
3
4
5
6
7
89
1011
34
IEEE P2600.5/D31b31a, December 2007
Table 57 —Organizational Security Policies for the DSR TOE
Name DefinitionP.OPERATOR.AUTHORIZATION To preserve accountability, Operators will be authorized to use the
TOE only as permitted by the TOE OwnerP.ADMIN.AUTHORIZATION To preserve security, Administrators will be authorized to manage the
TOE only as permitted by the TOE OwnerP.SOFTWARE.VERIFICATION To detect malicious modification of TOE software, procedures will
exist to verify that the currently installed software in the TOE is consistent with the authorized installed software
P.AUDIT.LOGGING To preserve accountability and security, records that provide an audit trail of TOE use and security-relevant events will be maintained and protected from unauthorized disclosure or alteration by the TOE, and will be reviewed by authorized personnel
10.2.4 DSR Assumptions
The Security Objectives and Security Functional Requirements defined in subsequent sections of this Protection Profile are based on the condition that all of the assumptions described in this section are satisfied.
Table 58 —Assumptions for the DSR TOE
Assumption DefinitionA.LOCATION.SECURITY The TOE is located in secure or monitored area which limits the
opportunity for unauthorized physical access to the TOE.A.OPERATOR.TRAINING Operators are aware of the security policies and procedures of their
organization, and are trained and competent to follow those policies and procedures.
A.OPERATOR.TRUST Operators do not use their privileged access rights for malicious purposes.A.ADMIN.TRAINING Administrators are aware of the security policies and procedures of their
organization, and are trained and competent to follow the manufacturer’s guidance and documentation to configure and operate the TOE in accordance those policies and procedures.
A.ADMIN.TRUST Administrators do not use their privileged access rights for malicious purposes.
10.3 DSR Security objectives (APE_OBJ)
10.3.1 DSR Security objectives
This section describes the security objectives that the DSR TOE shall fulfill.
Table 59 —DSR Security objectives for the TOE
Objective DefinitionO.DOC.RETRIEVE.NO_DIS The TOE shall protect User Document Data that are retrievable from the
TOE from unauthorized disclosure.O.DOC.RETRIEVE.NO_ALT The TOE shall protect User Document Data that are retrievable from the
TOE from unauthorized alteration.O.OPERATOR.AUTHORIZED The TOE shall require identification and authentication of Operators, and
shall ensure that Operatorsare authorized in accordance with security policies before allowing them to use the TOE.
O.PROT.REST.NO_ALT The TOE shall protect TSF Protected Data in the TOE from unauthorized alteration.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
87
1
2
1
2
345
6
7
8
9
10
34
IEEE P2600.5/D31b31a, December 2007
Objective DefinitionO.CONF.REST.NO_DIS The TOE shall protect TSF Confidential Data in the TOE from
unauthorized disclosure.O.CONF.REST.NO_ALT The TOE shall protect TSF Confidential Data in the TOE from
unauthorized alteration.O.ADMIN.AUTHORIZED The TOE shall require identification and authentication of
Administrators, and shall ensure that Administrators, are authorized in accordance with security policies before allowing them to manage the TOE.
O.SOFTWARE.VERIFIED The TOE shall provide procedures to verify that the currently installed software in the TOE is consistent with the authorized installed TOE software.
O.AUDIT.LOGGED The TOE shall create and maintain a log of TOE use and security-relevant events, and prevent its unauthorized disclosure or alteration.
10.3.2 DSR Security objectives for the development environment
There are no security objectives for the development environment for the DSR TOE.
10.3.3 DSR Objectives for the IT operational environment
There are no IT Objectives for the operational environment for the DSR TOE.
10.3.4 DSR Objectives for the non-IT operational environment
This section describes the security objectives that must be fulfilled by non-IT methods in the operational environment for the DSR TOE.
Table 60 —Non-IT Objectives for the operational environment
Objective DefinitionOE.LOCATION.SECURED The TOE shall be placed in secure or monitored area which limits the
opportunity for unauthorized physical access to the TOE.OE.OPERATOR.TRAINED The TOE owner shall ensure that TOE Operatorsare aware of the security
policies and procedures of their organization, and have the training and competence to follow those policies and procedures.
OE.OPERATOR.TRUSTED The TOE owner shall take steps to establish trust that TOE Operatorswill not use their privileged access rights for malicious purposes.
OE.ADMIN.TRAINED The TOE owner shall ensure that TOE Administrators are aware of the security policies and procedures of their organization, and have the training, competence, and time to follow the manufacturer’s guidance and documentation to correctly configure and operate the TOE in accordance those policies and procedures.
OE.ADMIN.TRUSTED The TOE owner shall establish trust that TOE administrators will not use their privileged access rights for malicious purposes.
OE.AUDIT.REVIEWED The TOE owner shall ensure that audit logs are reviewed at appropriate intervals for security violations or unusual patterns of activity.
10.3.5 DSR Security objectives rationale
This section demonstrates that each threat, organizational security policy, and assumption, are mitigated by at least one security objective for the DSR TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
88
1
2
1
2
3
4
5
67
8
9
1011
34
IEEE P2600.5/D31b31a, December 2007
Table 61 —DSR objectives rationale
Threats, Policies, and Assumptions O.D
OC
.RET
RIE
VE.
NO
_DIS
O.D
OC
.RET
RIE
VE.
NO
_ALT
O.P
RO
T.R
EST.
NO
_ALT
O.C
ON
F.R
EST.
NO
_DIS
O.C
ON
F.R
EST.
NO
_ALT
O.O
PER
ATO
R.A
UTH
OR
IZED
O.A
DM
IN.A
UTH
OR
IZED
O.S
OFT
WA
RE.
VER
IFIE
DO
.AU
DIT
.LO
GG
EDO
E.A
UD
IT.R
EVIE
WED
OE.
LOC
ATI
ON
.SEC
UR
EDO
E.A
DM
IN.T
RA
INED
OE.
AD
MIN
.TR
UST
ED
OE.
OPE
RA
TOR
.TR
AIN
ED
OE.
OPE
RA
TOR
.TR
UST
ED
T.DOC.RETRIEVE.DIS T.DOC.RETRIEVE.ALT T.PROT.REST.ALT T.CONF.REST.DIS T.CONF.REST.ALT P.OPERATOR.AUTHORIZATION P.ADMIN.AUTHORIZATION P.SOFTWARE.VERIFICATION P.AUDIT.LOGGING A.LOCATION.SECURITY A.ADMIN.TRAINING A.ADMIN.TRUST A.OPERATOR.TRAINING A.OPERATOR.TRUST
10.4 DSR Extended components definition (APE_ECD)
The DSR Protection Profile does not define any extended components.
10.5 DSR Security functional requirements (APE_REQ)
This section defines the security functional policies and requirements for the DSR TOE.
10.5.1 Security Function Policies
The Security Function Policy (SFP) described in this section is referenced in one or more SFR Class sections that follow.
10.5.1.1 DSR Access Control SFP
Table 62 — DSR Access Control SFP
Entity Access control rule(s)U.ORIGINATOR S.DSR authorizes U.ORIGINATOR to bind with S.DSR to create a job and
perform subsequent DSR job operations if granted permission to do so by U.ADMINISTRATOR.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
89
1
2
1
2
3
4
5
6
78
9
10
34
IEEE P2600.5/D31b31a, December 2007
Entity Access control rule(s)U.DELEGATE S.DSR authorizes U.DELEGATE to bind with S.DSR to perform DSR job
operations if granted permission to do so by U.ORIGINATOR or U.ADMINISTRATOR.
U.ADMINISTRATOR S.DSR requires identification and authentication.S.DSR authorizes U.ADMINISTRATOR to bind with S.DSR to perform DSR management operations if previously granted permission to do so by U.ADMINISTRATOR.
D.DOC.RETRIEVE S.DSR may read/write on behalf of U.ORIGINATOR or U.ADMINISTRATOR, and on behalf of U.DELEGATE if granted permission to do so by U.ORIGINATOR or U.ADMINISTRATOR.
D.PROT.REST S.DSR may read on behalf of any authorized Operator.S.DSR may write on behalf of U.ADMINISTRATOR.S.DSR may write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
D.CONF.REST S.DSR may read or write on behalf of U.ADMINISTRATOR.S.DSR may read or write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
10.5.2 Class FAU: Security audit
FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
{FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
[assignment:other specifically defined auditable event]. }
FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
events listed in Table 63—DSR Audit data requirements”; assignment:other specifically defined auditable event].
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
90
1
2
1
2
4
5
67
8
91011
121314
1516
17
181920
21222324
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— Table 64—DSR Audit data recommendations” lists additional auditable events that are recommended for consideration in FAU_GEN.1.1
{FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment:other audit relevant informatio]. }
FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, additional information listed in Table 63—DSR Audit data requirements”; assignment:other audit relevant informatio].
PP APPLICATION NOTE— Table 64—DSR Audit data recommendations” lists additional audit information that is recommended for consideration in FAU_GEN.1.2
Table 63 —DSR Audit data requirements
Auditable event Audit level Additional information Relevant SFRDeletion of audit records None None FAU_SAR.1Audit storage full None None FAU_STG.4Job initiation None Type of job FDP_ACF.1Job completion None Type of job FDP_ACF.1Unsuccessful user authentication Basic None FIA_UAU.1Successful user authentication Basic None FIA_UAU.1Unsuccessful user identification Basic Attempted user identity, if
availableFIA_UID.1
Successful user identification Basic None FIA_UID.1Management function initiation Minimal None FMT_SMF.1Modification of administrative user/role assignments
Minimal None FMT_SMR.1
Set/change system time Minimal None FPT_STM.1
Table 64 —DSR Audit data recommendations
Auditable event Audit level Additional information Relevant SFRJob initiation None Type of job FDP_ACF.1Attempts to authenticate reach failure limit
Minimal User identity, actions taken as a result, and if appropriate, subsequent restoration to the normal state
FIA_AFL.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
91
1
2
12
34
56
789
10
1112
1314
151617181920
2122
23
24
25
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— FAU_GEN.1 is a dependency of FAU_SAR.1
PP APPLICATION NOTE— FAU_GEN.1 performs audit recommendations of FAU_SAR.1, FAU_SAR.2, FAU_STG.4, FDP_ACF.1, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UAU.7, FIA_UID.1, FMT_MSA.1, FMT_MSA.3, FMT_MTD.1, FMT_SMF.1, FMT_SMR.1, FPT_STM.1, and FPT_TST.1
FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
{FAU_SAR.1.1The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of audit information] from the audit records.}
FAU_SAR.1.1The TSF shall provide [assignment: authorised operators] with the capability to read [assignment: list of audit information] from the audit records.
{FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the user to interpret the information.}
FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the operator to interpret the information.
PP APPLICATION NOTE— FAU_SAR.1 is a dependency of FAU_SAR.2
FAU_SAR.2 Restricted audit review
Hierarchical to: No other components.
Dependencies: FAU_SAR.1 Audit review
{FAU_SAR.2.1The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access.}
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
92
1
2
1
2345
6
8
9
101112
131415
161718
192021
22
23
25
26
272829
34
IEEE P2600.5/D31b31a, December 2007
FAU_SAR.2.1The TSF shall prohibit all users read access to the audit records, except those operators that have been granted explicit read-access.
PP APPLICATION NOTE— FAU_SAR.2 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.1 Protected audit trail storage
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG.1.1The TSF shall protect the stored audit records in the audit trail from unauthorised deletion.
FAU_STG.1.2The TSF shall be able to [selection, choose one of: prevent, detect] unauthorised modifications to the stored audit records in the audit trail.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.4 Prevention of audit data loss
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
{FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbythe
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
93
1
2
123
4
5
7
8
91011
121314
15
16
18
19
2021222324252627282930313233343536
34
IEEE P2600.5/D31b31a, December 2007
authoriseduserwithspecialrights”,“overwritetheoldeststoredauditrecords”]and[assignment: otheractions to be taken in case of audit storage failure] if the audit trail isfull.}
FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthorisedoperatorwithspecialrights”,“overwritetheoldeststoredauditrecords”]and[assignment: otheractions to be taken in case of audit storage failure] if the audit trail isfull.
PP APPLICATION NOTE— FAU_STG.4 is a requirement which fulfills O.AUDIT.LOGGED
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
94
1
2
123456789
101112131415
1617181920212223242526272829303132333435363738394041424344454647
48
34
IEEE P2600.5/D31b31a, December 2007
10.5.3 Class FCO: Communication
There are no Class FCO security functional requirements for the DSR Protection Profile.
10.5.4 Class FCS: Cryptographic support
There are no Class FCS security functional requirements for the DSR Protection Profile.
10.5.5 Class FDP: User data protection
FDP_ACC.1 Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
{FDP_ACC.1.1The TSF shall enforce the [assignment: access control SFP] on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].}
FDP_ACC.1.1The TSF shall enforce the DSR Access Control SFP on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].
PP APPLICATION NOTE— FDP_ACC.1 is a dependency of FMT_MSA.1.
FDP_ACF.1 Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access controlFMT_MSA.3 Static attribute initialisation
{FDP_ACF.1.1The TSF shall enforce the [assignment: access control SFP] to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].}
FDP_ACF.1.1The TSF shall enforce the DSR Access Control SFP to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
95
1
2
1
2
3
4
5
6
8
9
101112
131415
16
17
19
202122
2324252627
2829303132
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— recommended subjects and objects for consideration in FDP_ACF.1.1: S.DSR: D.DOC.RETRIEVE, D.FUNC.REST, D.PROT.REST, D.CONF.REST
FDP_ACF.1.2The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects].
FDP_ACF.1.3The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects].
FDP_ACF.1.4The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].
PP APPLICATION NOTE— FDP_AC F.1 is a dependency of FDP_ACC.1.
10.5.6 Class FIA: Identification and authentication
FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to [assignment: list of authentication events].
FIA_AFL.1.2When the defined number of unsuccessful authentication attempts has been [selection: met, surpassed] the TSF shall [assignment: list of actions].
PP APPLICATION NOTE— FIA_AFL.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
96
1
2
12
34567
89
1011
121314
15
16
17
19
20
2122232425
262728
2930
34
IEEE P2600.5/D31b31a, December 2007
FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_ATD.1.1The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: list of security attributes].}
FIA_ATD.1.1The TSF shall maintain the following list of security attributes belonging to individual operators: [assignment: list of security attributes].
FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_SOS.1.1The TSF shall provide a mechanism to verify that secrets meet [assignment: a defined quality metric].
PP APPLICATION NOTE— FIA_SOS.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
PP APPLICATION NOTE— The suggested minimum for password quality is eight (8) alphanumeric characters.
FIA_UAU.1 Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated.}
FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the operator to be performed before the operator is authenticated.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
97
1
2
1
3
4
567
89
10
11
13
14
151617
1819
20
21
23
24
252627
282930
34
IEEE P2600.5/D31b31a, December 2007
{FIA_UAU.1.2The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UAU.1.2The TSF shall require each operator to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UAU.1 is a dependency of FIA_AFL.1 and FIA_UAU.7.
FIA_UAU.7 Protected authentication feedback
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the user while the authentication is in progress.}
FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the operator while the authentication is in progress.
PP APPLICATION NOTE— FIA_UAU.7 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.
FIA_UID.1 Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is identified.}
FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the operator to be performed before the operator is identified.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
98
1
2
123
456
7
8
10
11
121314
151617
1819
20
22
23
242526
272829
34
IEEE P2600.5/D31b31a, December 2007
{FIA_UID.1.2The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UID.1.2The TSF shall require each operator to be successfully identified before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UID.1 is a dependency of FIA_UAU.1, and FMT_SMR.1.
10.5.7 Class FMT: Security management
FMT_MSA.1 Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, orFDP_IFC.1 Subset information flow control]FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
{FMT_MSA.1.1The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].}
FMT_MSA.1.1The TSF shall enforce the DSR Access Control SFP to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MSA.1 is a dependency of FMT_MSA.3
PP APPLICATION NOTE— FMT_MSA.1 performs management recommendations of FDP_ACF.1
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
99
1
2
123
456
7
8
9
11
12131415
1617181920
2122232425
26
27
34
IEEE P2600.5/D31b31a, December 2007
FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributesFMT_SMR.1 Security roles
{FMT_MSA.3.1The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection, choose one of: restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.}
FMT_MSA.3.1The TSF shall enforce the DSR Access Control SFP to provide [selection, choose one of: restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial values to override the default values when an object or information is created.
PP APPLICATION NOTE— FMT_MSA.3 is a dependency of FDP_ACF.1
FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations]] the [assignment: list of TSF data] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MTD.1 is a required to fulfill O.PROT.REST.NO_ALT, O.CONF.REST.NO_DIS, O.CONF.REST.NO_ALT
PP APPLICATION NOTE— In typical applications, an U.ADMINISTRATOR can perform operations on most or all TSF data. U.ORIGINATOR can modify some TSF Data when such data was created for that user (for example, an Operator’s own password). Refer to the DSR Access Control SFP.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
100
1
2
1
3
45
6789
10111213
14151617
18
19
21
2223
24252627
2829
303132
34
IEEE P2600.5/D31b31a, December 2007
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1The TSF shall be capable of performing the following management functions: [assignment: list of management functions to be provided by the TSF].
PP APPLICATION NOTE— the management functions listed in “Error: Reference source not foundError: Referencesource not found” are recommended for consideration in FMT_SMF.1. The ST author should consider specifying other management functions that support administrative functionality of the ST target of evaluation.
Table 65 —DSR Management function recommendations
Management function Relevant SFRMaintenance of group of users who are authorized to access audit records
FAU_SAR.1
Management of the user identities FAU_UID.1Management of system time FPT_STM.1
PP APPLICATION NOTE— FMT_SMF.1 is a dependency of FMT_MSA.1 and FMT_MTD.1.
PP APPLICATION NOTE— FMT_MSA.1 performs management recommendations of FDP_ACF.1 FAU_SAR.1, FAU_STG.4, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UID.1, FMT_MSA.1, FMT_MSA.3, FMT_SMR.1, and FPT_STM.1
FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1The TSF shall maintain the roles [assignment: the authorised identified roles].
PP APPLICATION NOTE— recommended minimum to be specified in FMT_SMR.1: Administrator and DSR Operator
{FMT_SMR.1.2The TSF shall be able to associate users with roles.}
FMT_SMR.1.2The TSF shall be able to associate operators with roles.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
101
1
2
1
3
4
567
89
10
11
12
13
141516
17
19
20
2122
2324
2526
2728
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE— FMT_SMR.1 is a dependency of FMT_MSA.1, FMT_MSA.3, and FMT_MTD.1.
10.5.8 Class FPR: Privacy
There are no Class FPR security functional requirements for the DSR Protection Profile.
10.5.9 Class FPT: Protection of the TSF
FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_STM.1.1The TSF shall be able to provide reliable time stamps.
PP APPLICATION NOTE— FPT_STM.1 is a dependency of FAU_GEN.1
FPT_TST.
TSF testin
Hierarchical to: No other components.
Dependencies: No dependencies.
{FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorised user, at theconditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF]}
FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorisedoperator, at theconditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF].
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF data]}
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
102
1
2
1
2
3
4
5
7
8
910
11
121314
17
18
192021222324
252627282930
31323334
34
IEEE P2600.5/D31b31a, December 2007
FPT_TST.1.The TSF shall provide authorised
operators with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of stored TSF executable code}
FPT_TST.1.The TSF shall provide authorised
operators with the capability to verify the integrity of stored TSF executable code.
PP APPLICATION NOTE— FPT_TST.1 is a requirement which fulfills O.SOFTWARE.VERIFIED.
10.5.10 Class FRU: Resource utilization
There are no Class FRU security functional requirements for the DSR Protection Profile.
10.5.11 Class FTA: TOE access
There are no Class FTA security functional requirements for the DSR Protection Profile.
10.5.12 Class FTP: Trusted paths/channels
There are no Class FTA security functional requirements for the DSR Protection Profile.
10.6 DSR Security requirements rationale
Table 66 and Table 67 demonstrate the completeness and sufficiency of SFRs that fulfill the objectives of the DSR TOE. Bold typefaced items provide primary (P) fulfillment of the objectives, and normal typefaced items are support (S) fulfillment.
Table 66 —Completeness of DSR security requirements
SFR O.D
OC
.RE
TR
IEV
E.N
O_D
ISO
.DO
C.R
ET
RIE
VE
.NO
_AL
TO
.PR
OT
.RE
ST.N
O_A
LT
O.C
ON
F.R
EST
.NO
_DIS
O.C
ON
F.R
EST
.NO
_AL
TO
.USE
R.A
UT
HO
RIZ
ED
O.A
DM
IN.A
UT
HO
RIZ
ED
O.S
OFT
WA
RE
.VE
RIF
IED
O.A
UD
IT.L
OG
GE
D
FAU_GEN.1 PFAU_SAR.1 P
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
103
1
2
1234
5678
101112
14
15
16
17
18
19
20
21
222324
25
34
IEEE P2600.5/D31b31a, December 2007
SFR O.D
OC
.RE
TR
IEV
E.N
O_D
ISO
.DO
C.R
ET
RIE
VE
.NO
_AL
TO
.PR
OT
.RE
ST.N
O_A
LT
O.C
ON
F.R
EST
.NO
_DIS
O.C
ON
F.R
EST
.NO
_AL
TO
.USE
R.A
UT
HO
RIZ
ED
O.A
DM
IN.A
UT
HO
RIZ
ED
O.S
OFT
WA
RE
.VE
RIF
IED
O.A
UD
IT.L
OG
GE
D
FAU_SAR.2 SFAU_STG.1 SFAU_STG.4 SFDP_ACC.1 P P FDP_ACF.1 S S FIA_AFL.1 S S FIA_ATD.1 S S FIA_SOS.1 S SFIA_UAU.1 P P FIA_UAU.7 S S FIA_UID.1 S S S S S P P SFIA_USB.1 P P FMT_MSA.1 S S FMT_MSA.3 S S FMT_MTD.1 P P P FMT_SMF.1 S S S S S FMT_SMR.1 S S S S S FPT_AMT.1 SFPT_STM.1 SFPT_TST.1 P
Table 67 —Sufficiency of DSR security requirements
Objectives Description SFRs PurposeO.DOC.RETRIEVE.NO_DIS Protection of
User Data from unauthorized disclosure
FDP_ACC.1 Prevents disclosure by enforcing access control policy.
FDP_ACF.1 Supports policy by providing access control function.
FIA_UID.1 Supports security roles by requiring user ID.
FMT_MSA.1 Supports access control function by enforcing control of security attributes.
FMT_MSA.3 Supports access control function by enforcing control of security attribute defaults.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
104
1
2
1
2
34
IEEE P2600.5/D31b31a, December 2007
Objectives Description SFRs PurposeFMT_SMR.1 Supports control of security
attributes by requiring security roles.O.DOC.RETRIEVE.NO_ALT
Protection of User Data from unauthorized alteration
FDP_ACC.1 Prevents alteration by enforcing access control policy.
FDP_ACF.1 Supports policy by providing access control function.
FIA_UID.1 Supports security roles by requiring user ID.
FMT_MSA.1 Supports access control function by enforcing control of security attributes.
FMT_MSA.3 Supports access control function by enforcing control of security attribute defaults.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.CONF.REST.NO_DIS Protection of TSF Data from unauthorized disclosure
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1
Prevents disclosure by restricting access.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.PROT.REST.NO_ALT, O.CONF.REST.NO_ALT
Protection of TSF Data from unauthorized alteration
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1
Prevents alteration by restricting access.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.USER.AUTHORIZED,O.ADMIN.AUTHORIZED
Authorization of users and administrators to use the TOE.
FIA_AFL.1 Supports authorization by policy for handling authentication failures.
FIA_ATD.1 Supports authorization by associating attributes with authorized users.
FIA_SOS.1 Supports authentication by requiring minimum strength of authentication secrets.
FIA_UAU.1 Provides authorization by requiring user authentication.
FIA_UAU.7 Supports authentication by policy of limited authentication feedback.
FIA_UID.1 Provides authorization by requiring user identification.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
105
1
2
34
IEEE P2600.5/D31b31a, December 2007
Objectives Description SFRs PurposeO.SOFTWARE.VERIFIED Verification
of software integrity
FPT_TST.1 Requires the capability to perform TSF self-tests
O.AUDIT.LOGGED Logging and authorized access to audit events.
FAU_GEN.1 Requires audit logging of relevant events.
FAU_SAR.1 Ensures that audit records can be reviewed by authorized users.
FAU_SAR.2 Supports audit review by preventing unauthorized access.
FAU_STG.1 Supports audit integrity by preventing unauthorized deletion.
FAU_STG.4 Supports audit integrity by policy against loss of records.
FIA_UID.1 Supports audit function by requiring user ID.
FPT_STM.1 Supports audit function by requiring timestamps.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
106
1
2
34
IEEE P2600.5/D31b31a, December 2007
11 Nonvolatile Storage Protection Profile: P2600.5-NVS
11.1 NVS TOE Overview (APE_INT)
11.1.1 NVS TOE Model
The Nonvolatile Storage TOE is composed of the essential processing elements required to prevent the recovery of the User Document Data of the Subject of another TOE from nonvolatile storage devices which might be removed and analyzed by unauthorized persons:
a) The NVS subject performs operations (e.g. overwriting data) on behalf of the Subject of another TOE to make residual User Document Data that has been dereferenced or released after it is no longer needed by those Subjects unavailable for offline salvage by unauthorized persons.
b) The NVS subject performs operations (e.g. encryption) on behalf of the Subject of another TOE to make temporarily and persistently stored User Document Data unavailable for offline salvage by unauthorized persons.
TSF data (e.g. audit logs) may be created or updated during the Nonvolatile Storage process.
The NVS TOE may also provide the essential processing elements required to manage the NVS process:
c) An Administrator can retrieve, modify, and store TSF Protected Data.
d) An Administrator can retrieve, modify, and store TSF Confidential Data.
Additional TSF data (e.g. audit logs) may be created or updated the performance of administrative tasks.
Figure 15 —Nonvolatile storage TOE model
Nonvol. Storage
User Data
User Document Data
Administrator
TSF Data
User
REST DELETEDREST
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
107
1
2
1
2
3
456789
10
111213
1415161718
19
2021
22
232425
34
IEEE P2600.5/D31b31a, December 2007
11.1.2 Major security features of the NVS TOE
The major security features of the Nonvolatile Storage TOE are:
a) User Document Data of the Subject of another TOE are protected from offline salvage by unauthorized persons.
b) All operators are identified and authenticated, and are authorized before being granted permission to manage NVS functions.
c) TSF Data, of which unauthorized disclosure threatens operational security, is protected from disclosure to anyone except for the originating operator and authorized Administrators.
d) TSF Data, of which unauthorized alteration threatens operational security, is protected from alteration by anyone except for the originating operator and authorized Administrators.
e) NVS operations and security-relevant system events (successful and unsuccessful) are recorded, and such records are protected from disclosure or alteration by anyone except for authorized administrators.
11.2 NVS Security problem definition (APE_SPD)
11.2.1 NVS Assets
This section describes the security-relevant assets and asset-state pairs that apply to the NVS TOE. These assets and states are a subset of assets and states defined for the Family of Protection Profiles in 5.5.3, “Objects (Assets)”. A PP application note provides additional information about some assets and states that are associated with the practical function of the NVS TOE but that are not within the scode of the TOE.
Table 68 —User Data assets of NVS TOE
Asset State Name ExamplesUser Document Data
In the TOE D.DOC(+OTHERTOE).REST User Document Data of the Subject of another TOE in this TOE
User Document Data
Deleted D.DOC(+OTHERTOE).DELETED Residual data from User Document Data of the Subject of another TOE that have been dereferenced (deleted) during or after processing a job
PP APPLICATION NOTE— D.DOC(+OTHERTOE).REST is only an asset from the point of view of Salvage threats. See also Table 70.
Table 69 TSF Data assets of the NVS TOE
Asset State Name ExamplesTSF Protected Data
In the TOE D.PROT.REST Authentication data, security attributes, and other security-relevant data in the TOE, which must be protected from unauthorized alteration
TSF Confidential Data
In the TOE D.CONF.REST Authentication data, security attributes, and other security-relevant data in the TOE, which must be protected from unauthorized disclosure or alteration
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
108
1
2
1
2345
67
89
1011
121314
15
16
17181920
21
2223
24
34
IEEE P2600.5/D31b31a, December 2007
PP APPLICATION NOTE – Some of the assets defined in 5.5.3 “Objects (Assets)” are not applicable to the NVS TOE model. Rationale for inapplicability is described in Table 70:
Table 70 —Assets not applicable to the NVS TOE
Asset Rationale See alsoD.DOC(+OTHERTOE).REST
(Partially applicable) Only Salvage threats are considered in the NVS TOE. Disclosure and Alteration threats are considered in other TOEs.
PRT, SCN, CPY
D.DOC.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.FUNC.REST The NVS TOE does not have any User Function Data assets that must always be protected from either unauthorized disclosure or alteration while they are in the TOE.
N/A
D.FUNC.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.PROT.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
D.CONF.TRANSIT Assets in transit are only considered in TOEs that have a shared medium interface
N/A
11.2.2 NVS Threats
This section describes threats to assets described in the previous section.
Table 71 —Threats to User Data for the NVS TOE
Threat Affected asset(s) DescriptionT.DOC(+OTHERTOE).REST.SAL
D.DOC(+OTHERTOE).REST
User Document Data of the Subject of another TOE in a nonvolatile storage medium that has been removed from TOE may be salvaged by unauthorized persons
T.DOC(+OTHERTOE).DELETED.SAL
D.DOC(+OTHERTOE).DELETED
Deleted User Document Data of the Subject of another TOE in a nonvolatile storage medium that has been removed from TOE may be salvaged by unauthorized persons
Table 72 Threats to TSF Data for the NVS TOE
Threat Affected asset(s) DescriptionT.PROT.REST.ALT D.PROT.REST TSF Protected Data in the TOE may be altered by
unauthorized personsT.CONF.REST.DIS D.CONF.REST TSF Confidential Data in the TOE may be
disclosed to unauthorized personsT.CONF.REST.ALT D.CONF.REST TSF Confidential Data in the TOE may be altered
by unauthorized persons
11.2.3 NVS Organizational Security Policies
This section describes the Organizational Security Policies (OSPs) that apply to the NVS TOE. OSPs are used to provide a basis for security objectives that are commonly desired by TOE owners in this operational environment but for which it is not possible to make uniform defintions of the threats that are being mitigated or the assets that are being threatened.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
109
1
2
12
3
4
5
6
7
8
9101112
34
IEEE P2600.5/D31b31a, December 2007
Table 73 Organizational Security Policies for the NVS TOE
Name DefinitionP.ADMIN.AUTHORIZATION Administrators will be authorized according to security policies before
being permitted to manage the TOEP.SOFTWARE.VERIFICATION Procedures will exist to verify that the currently installed software in
the TOE is consistent with the authorized installed softwareP.AUDIT.LOGGING Records that provide an audit trail of TOE use and security-relevant
events will be maintained and protected from unauthorized disclosure or alteration
11.2.4 NVS Assumptions
The Security Objectives and Security Functional Requirements defined in subsequent sections of this Protection Profile are based on the condition that all of the assumptions described in this section are satisfied.
Table 74 —Assumptions for the NVS TOE
Assumption DefinitionA.LOCATION.SECURITY The TOE is located in secure or monitored area which limits the opportunity
for unauthorized physical access to the TOE.A.ADMIN.TRAINING Administrators are aware of the security policies and procedures of their
organization, and are trained and competent to follow the manufacturer’s guidance and documentation to configure and operate the TOE in accordance those policies and procedures.
A.ADMIN.TRUST Administrators do not use their privileged access rights for malicious purposes.
11.3 NVS Security objectives (APE_OBJ)
11.3.1 NVS Security objectives for the TOE
This section describes the security objectives that the NVS TOE shall fulfill.
Table 75 —NVS Security objectives
Objective DefinitionO.DOC(+OTHERTOE).REST.NO_SAL The TOE shall protect User Document Data of the Subject
of another TOE in a nonvolatile storage medium that has been removed from TOE from unauthorized salvage.
O.DOC(+OTHERTOE).DELETED.NO_SAL The TOE shall protect deleted User Document Data of the Subject of another TOE in a nonvolatile storage medium that has been removed from TOE from unauthorized salvage.
O.PROT.REST.NO_ALT The TOE shall protect TSF Protected Data in the TOE from unauthorized alteration.
O.CONF.REST.NO_DIS The TOE shall protect TSF Confidential Data in the TOE from unauthorized disclosure.
O.CONF.REST.NO_ALT The TOE shall protect TSF Confidential Data in the TOE from unauthorized alteration.
O.ADMIN.AUTHORIZED The TOE shall require identification and authentication of Administrators, and shall ensure that Administrators, are authorized in accordance with security policies before allowing them to manage the TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
110
1
2
1
2
345
6
7
8
9
10
34
IEEE P2600.5/D31b31a, December 2007
Objective DefinitionO.SOFTWARE.VERIFIED The TOE shall provide procedures to verify that the
currently installed software in the TOE is consistent with the authorized installed TOE software.
O.AUDIT.LOGGED The TOE shall create and maintain a log of TOE use and security-relevant events, and prevent its unauthorized disclosure or alteration.
11.3.2 NVS Security objectives for the development environment
There are no security objectives for the development environment for the NVS TOE.
11.3.3 NVS Objectives for the IT operational environment
There are no IT Objectives for the operational environment for the NVS TOE.
11.3.3.1 —NVS Objectives for the non-IT operational environment
This section describes the security objectives that must be fulfilled by non-IT methods in the operational environment for the NVS TOE.
Table 76 —Non-IT Objectives for the operational environment
Objective DefinitionOE.LOCATION.SECURED The TOE shall be placed in secure or monitored area which limits the
opportunity for unauthorized physical access to the TOE.OE.ADMIN.TRAINED The TOE owner shall ensure that TOE Administrators are aware of the
security policies and procedures of their organization, and have the training, competence, and time to follow the manufacturer’s guidance and documentation to correctly configure and operate the TOE in accordance those policies and procedures.
OE.ADMIN.TRUSTED The TOE owner shall establish trust that TOE administrators will not use their privileged access rights for malicious purposes.
OE.AUDIT.REVIEWED The TOE owner shall ensure that audit logs are reviewed at appropriate intervals for security violations or unusual patterns of activity.
11.3.4 Security objectives rationale
This section demonstrates that each threat, organizational security policy, and assumption, are mitigated by at least one security objective for the NVS TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
111
1
2
1
2
3
4
5
67
8
9
1011
34
IEEE P2600.5/D31b31a, December 2007
Table 77 —NVS objectives rationale
Threats, Policies, and Assumptions O.D
OC
(+O
THER
TOE)
.DEL
ETED
.NO
_SA
LO
.PR
OT.
RES
T.N
O_A
LTO
.CO
NF.
RES
T.N
O_D
ISO
.CO
NF.
RES
T.N
O_A
LTO
.AD
MIN
.AU
THO
RIZ
EDO
.SO
FTW
AR
E.V
ERIF
IED
O.A
UD
IT.L
OG
GED
OE.
AU
DIT
.REV
IEW
EDO
E.LO
CA
TIO
N.S
ECU
RED
OE.
AD
MIN
.TR
AIN
EDO
E.A
DM
IN.T
RU
STED
T.DOC(+OTHERTOE).REST.SALT.DOC(+OTHERTOE).DELETED.SAL T.PROT.REST.ALT T.CONF.REST.DIS T.CONF.REST.ALT P.ADMIN.AUTHORIZATION P.SOFTWARE.VERIFICATION P.AUDIT.LOGGING A.LOCATION.SECURITY A.ADMIN.TRAINING A.ADMIN.TRUST
11.4 NVS Extended components definition (APE_ECD)
The NVS Protection Profile does not define any extended components.
11.5 NVS Security functional requirements (APE_REQ)
This section defines the security functional policies and requirements for the NVS TOE.
11.5.1 Security Function Policies
The Security Function Policy (SFP) described in this section is referenced in one or more SFR Class sections that follow.
11.5.1.1 NVS Access Control SFP
Table 78 — NVS Access Control SFP
Entity Access control rule(s)U.ADMINISTRATOR S.NVS requires identification and authentication
S.NVS authorizes U.ADMINISTRATOR to bind with S.NVS to perform NVS management operations if previously granted permission to do so by a U.ADMINISTRATOR.
D.PROT.REST S.NVS may read on behalf of any authorized Operator.S.NVS may write on behalf of U.ADMINISTRATOR.
D.CONF.REST S.NVS may read or write on behalf of U.ADMINISTRATOR.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
112
1
2
1
2
3
4
5
6
78
9
10
34
IEEE P2600.5/D31b31a, December 2007
11.5.2 Class FAU: Security audit
FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
{FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
[assignment:other specifically defined auditable event]. }
FAU_GEN.1.1The TSF shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [selection, choose one of:minimum, basic, detailed, not specifie] level of audit; and
events listed in Table 79—NVS Audit data requirements”; assignment:other specifically defined auditable event].
PP APPLICATION NOTE— Table 80—NVS Audit data recommendations” lists additional auditable events that are recommended for consideration in FAU_GEN.1.1
{FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identit (if applicable), and th outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment:other audit relevant informatio]. }
FAU_GEN.1.2The TSF shall record within each audit record at least the following information:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
113
1
2
1
2
4
5
67
8
91011
121314
1516
17
181920
21222324
2526
2728
293031
32333435
3637
34
IEEE P2600.5/D31b31a, December 2007
Date and time of the event, type of event, subject identit (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, additional information listed in Table 79—NVS Audit data requirements”; assignment:other audit relevant informatio].
PP APPLICATION NOTE— Table 80—NVS Audit data recommendations” lists additional audit information that is recommended for consideration in FAU_GEN.1.2
Table 79 —NVS Audit data requirements
Auditable event Audit level Additional information Relevant SFRDeletion of audit records None None FAU_SAR.1Audit storage full None None FAU_STG.4Unsuccessful user authentication Basic None FIA_UAU.1Successful user authentication Basic None FIA_UAU.1Unsuccessful user identification Basic Attempted user identity, if
availableFIA_UID.1
Successful user identification Basic None FIA_UID.1Management function initiation Minimal None FMT_SMF.1Modification of administrative user/role assignments
Minimal None FMT_SMR.1
Set/change system time Minimal None FPT_STM.1
Table 80 —NVS Audit data recommendations
Auditable event Audit level Additional information Relevant SFRAttempts to authenticate reach failure limit
Minimal User identity, actions taken as a result, and if appropriate, subsequent restoration to the normal state
FIA_AFL.1
PP APPLICATION NOTE— FAU_GEN.1 is a dependency of FAU_SAR.1
PP APPLICATION NOTE— FAU_GEN.1 performs audit recommendations of FAU_SAR.1, FAU_SAR.2, FAU_STG.4, FIA_AFL.1, FIA_UAU.1, FIA_UAU.7, FIA_UID.1, FMT_MSA.1, FMT_MSA.2, FMT_MTD.1, FMT_SMF.1, FMT_SMR.1, FPT_STM.1, and FPT_TST.1
FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
{FAU_SAR.1.1The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of audit information] from the audit records.}
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
114
1
2
12
345678
910
11
12
13
14
151617
18
20
21
222324
34
IEEE P2600.5/D31b31a, December 2007
FAU_SAR.1.1The TSF shall provide [assignment: authorised operators] with the capability to read [assignment: list of audit information] from the audit records.
{FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the user to interpret the information.}
FAU_SAR.1.2The TSF shall provide the audit records in a manner suitable for the operator to interpret the information.
PP APPLICATION NOTE— FAU_SAR.1 is a dependency of FAU_SAR.2
FAU_SAR.2 Restricted audit review
Hierarchical to: No other components.
Dependencies: FAU_SAR.1 Audit review
{FAU_SAR.2.1The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access.}
FAU_SAR.2.1The TSF shall prohibit all operators read access to the audit records, except those operators that have been granted explicit read-access.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.1 Protected audit trail storage
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG.1.1The TSF shall protect the stored audit records in the audit trail from unauthorised deletion.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
115
1
2
123
456
789
10
11
13
14
151617
181920
21
22
24
25
262728
34
IEEE P2600.5/D31b31a, December 2007
FAU_STG.1.2The TSF shall be able to [selection, choose one of: prevent, detect] unauthorised modifications to the stored audit records in the audit trail.
PP APPLICATION NOTE— FAU_STG.1 is a requirement which fulfills O.AUDIT.LOGGED
FAU_STG.4 Prevention of audit data loss
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
{FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthoriseduserwithspecialrights”,“overwritetheoldeststoredauditrecords”]and[assignment:otheractions to be taken in case of audit storage failure] if the audit trailisfull.}
FAU_STG.4.1The TSF shall[selection,
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
116
1
2
123
4
5
7
8
9101112131415161718192021222324252627282930313233343536373839404142
434445
34
IEEE P2600.5/D31b31a, December 2007
chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthorisedoperatorwithspecialrights”,“overwritetheoldeststoredauditrecords”]and[assignment:otheractions to be taken in case of audit storage failure] if the audit trailisfull.
PP APPLICATION NOTE— FAU_STG.4 is a requirement which fulfills O.AUDIT.LOGGED
11.5.3 Class FCO: Communication
There are no Class FCO security functional requirements for the NVS Protection Profile.
11.5.4 Class FCS: Cryptographic support
There are no Class FCS security functional requirements for the NVS Protection Profile.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
117
1
2
123456789
10111213141516171819202122232425262728293031
32
33
34
35
36
34
IEEE P2600.5/D31b31a, December 2007
11.5.5 Class FDP: User data protection
FDP_RIP.1 Subset residual information protection
Hierarchical to: No other components.
Dependencies: No dependencies.
{FDP_RIP.1.1The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the resource from] the following objects: [assignment: list of objects].}
FDP_RIP.1.1The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from the following objects: O.DOC(+OTHERTOE).REST.NO_SAL and D.DOC(+OTHERTOE).DELETED.
PP APPLICATION NOTE— FDP_RIP.1 is a requirement which fulfills O.DOC(+OTHERTOE).REST.NO_SAL and O.DOC(+OTHERTOE).DELETED.NO_SAL.
11.5.6 Class FIA: Identification and authentication
FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to [assignment: list of authentication events].
FIA_AFL.1.2When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall [assignment: list of actions].
PP APPLICATION NOTE— FDP_AC C.1 is a requirement which fulfills O.ADMIN.AUTHORIZED.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
118
1
2
1
2
4
5
6789
10111213
1415
16
17
19
20
2122232425
262728
29
34
IEEE P2600.5/D31b31a, December 2007
FIA_UAU.1 Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated.}
FIA_UAU.1.1The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the operator to be performed before the operator is authenticated.
{FIA_UAU.1.2The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UAU.1.2The TSF shall require each operator to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UAU.1 is a dependency of FIA_AFL.1 and FIA_UAU.7.
FIA_UAU.7 Protected authentication feedback
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
{FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the user while the authentication is in progress.}
FIA_UAU.7.1The TSF shall provide only [assignment: list of feedback] to the operator while the authentication is in progress.
PP APPLICATION NOTE— FIA_UAU.7 is a requirement which fulfills O.ADMIN.AUTHORIZED.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
119
1
2
1
3
4
567
89
10
111213
141516
17
18
20
21
222324
252627
28
34
IEEE P2600.5/D31b31a, December 2007
FIA_UID.1 Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
{FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is identified.}
FIA_UID.1.1The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the operator to be performed before the operator is identified.
{FIA_UID.1.2The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.}
FIA_UID.1.2The TSF shall require each operator to be successfully identified before allowing any other TSF-mediated actions on behalf of that operator.
PP APPLICATION NOTE— FIA_UID.1 is a dependency of FIA_UAU.1, and FMT_SMR.1.
11.5.7 Class FMT: Security management
FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security rolesFMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations]] the [assignment: list of TSF data] to [assignment: the authorised identified roles].
PP APPLICATION NOTE— FMT_MTD.1 is a required to fulfill O.PROT.REST.NO_ALT, O.CONF.REST.NO_DIS, O.CONF.REST.NO_ALT
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
120
1
2
1
3
4
567
89
10
111213
141516
17
18
19
21
222324
25262728
2930
34
IEEE P2600.5/D31b31a, December 2007
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1The TSF shall be capable of performing the following management functions: [assignment: list of management functions to be provided by the TSF].
PP APPLICATION NOTE— the management functions listed in Table 81—NVS Management functionrecommendations” are recommended for consideration in FMT_SMF.1. The ST author should consider specifying other management functions that support administrative functionality of the ST target of evaluation.
Table 81 —NVS Management function recommendations
Management function Relevant SFRMaintenance of group of users who are authorized to access audit records
FAU_SAR.1
Management of the user identities FAU_UID.1Management of system time FPT_STM.1
PP APPLICATION NOTE— FMT_SMF.1 is a dependency of FMT_MTD.1.
PP APPLICATION NOTE— FMT_MSA.1 performs management recommendations of FAU_SAR.1, FAU_STG.4, FIA_AFL.1, FIA_UAU.1, FIA_UID.1, FIA_USB.1, FMT_SMR.1, and FPT_STM.1
FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1The TSF shall maintain the roles [assignment: the authorised identified roles].
PP APPLICATION NOTE— recommended minimum to be specified in FMT_SMR.1: Administrator
{FMT_SMR.1.2The TSF shall be able to associate users with roles.}
FMT_SMR.1.2The TSF shall be able to associate operators with roles.
PP APPLICATION NOTE— FMT_SMR.1 is a dependency of FMT_MTD.1.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
121
1
2
1
3
4
567
89
10
11
12
13
1415
16
18
19
2021
22
2324
2526
27
34
IEEE P2600.5/D31b31a, December 2007
11.5.8 Class FPR: Privacy
There are no Class FPR security functional requirements for the NVS Protection Profile.
11.5.9 Class FPT: Protection of the TSF
FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_STM.1.1The TSF shall be able to provide reliable time stamps.
PP APPLICATION NOTE— FPT_STM.1 is a dependency of FAU_GEN.1
FPT_TST.
TSF testin
Hierarchical to: No other components.
Dependencies: No dependencies.
{FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorised user, at the condition [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF]}
FPT_TST.1.The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorisedoperator, at the condition [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF].
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF data]}
FPT_TST.1.The TSF shall provide
authorized operators with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
122
1
2
1
2
3
4
6
7
89
10
111213
16
17
18192021222324
252627282930
31323334
35363738
34
IEEE P2600.5/D31b31a, December 2007
{FPT_TST.1.The TSF shall provide authorised users with the capability to verify the
integrity of stored TSF executable code}
FPT_TST.1.The TSF shall provide authorised
operators with the capability to verify the integrity of stored TSF executable code.
PP APPLICATION NOTE— FPT_TST.1 is a requirement which fulfills O.SOFTWARE.VERIFIED.
11.5.10 Class FRU: Resource utilization
There are no Class FRU security functional requirements for the NVS Protection Profile.
11.5.11 Class FTA: TOE access
There are no Class FTA security functional requirements for the NVS Protection Profile.
11.5.12 Class FTP: Trusted paths/channels
There are no Class FTP security functional requirements for the NVS Protection Profile.
11.6 NVS Security requirements rationale
Table 82 and Table 83 demonstrate the completeness and sufficiency of SFRs that fulfill the objectives of the NVS TOE. Bold typefaced items provide primary (P) fulfillment of the objectives, and normal typefaced items are support (S) fulfillment.
Table 82 —Completeness of NVS security requirements
SFRs O.D
OC
(+O
THER
TOE)
.DE
LE
TE
D.N
O_S
AL
O.P
RO
T.R
EST
.NO
_AL
T
O.C
ON
F.R
EST
.NO
_DIS
O.C
ON
F.R
EST
.NO
_AL
T
O.A
DM
IN.A
UT
HO
RIZ
ED
O.S
OFT
WA
RE
.VE
RIF
IED
O.A
UD
IT.L
OG
GE
D
FAU_GEN.1 PFAU_SAR.1 PFAU_SAR.2 SFAU_STG.1 SFAU_STG.4 SFDP_RIP.1 PFIA_AFL.1 S
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
123
1
2
1234
678
10
11
12
13
14
15
16
17
181920
21
34
IEEE P2600.5/D31b31a, December 2007
SFRs O.D
OC
(+O
THER
TOE)
.DE
LE
TE
D.N
O_S
AL
O.P
RO
T.R
EST
.NO
_AL
T
O.C
ON
F.R
EST
.NO
_DIS
O.C
ON
F.R
EST
.NO
_AL
T
O.A
DM
IN.A
UT
HO
RIZ
ED
O.S
OFT
WA
RE
.VE
RIF
IED
O.A
UD
IT.L
OG
GE
D
FIA_UAU.1 P FIA_UAU.7 S FIA_UID.1 S S S P SFMT_MTD.1 P P P FMT_SMF.1 S S SFMT_SMR.1 S S S FPT_STM.1 SFPT_TST.1 P
Table 83 —Sufficiency of NVS security requirements
Objectives Description SFRs PurposeO.DOC(+OTHERTOE).REST.NO_SAL
Protection of stored User Data from unauthorized salvage from offline nonvolatile storage
FDP_RIP.1 Prevents salvaging by ensuring that stored User Document Data is unavailable.
O.DOC(+OTHERTOE).DELETED.NO_SAL
Protection of deleted User Data from unauthorized salvage from offline nonvolatile storage
FDP_RIP.1 Prevents salvaging by ensuring that residual User Document Data is unavailable.
O.CONF.REST.NO_DIS Protection of TSF Data from unauthorized disclosure
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1
Prevents disclosure by restricting access.
FMT_SMF.1 Supports control of security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.PROT.REST.NO_ALT, O.CONF.REST.NO_ALT
Protection of TSF Data from unauthorized alteration
FIA_UID.1 Supports access control and security roles by requiring user ID.
FMT_MTD.1
Prevents alteration by restricting access.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
124
1
2
1
2
34
IEEE P2600.5/D31b31a, December 2007
Objectives Description SFRs PurposeFMT_SMF.1 Supports control of
security attributes by requiring functions to control attributes.
FMT_SMR.1 Supports control of security attributes by requiring security roles.
O.ADMIN.AUTHORIZED Authorization of users and administrators to use the TOE.
FIA_AFL.1 Supports authorization by policy for handling authentication failures.
FIA_ATD.1 Supports authorization by associating attributes with authorized users.
FIA_UAU.1 Provides authorization by requiring user authentication.
FIA_UAU.7 Supports authentication by policy of limited authentication feedback.
FIA_UID.1 Provides authorization by requiring user identification.
FIA_USB.1 Provides authorization by associating attributes with authenticated users.
O.SOFTWARE.VERIFIED Verification of software integrity
FPT_AMT.1 Supports TSF testing by providing capability of testing the underlying abstract machine
FPT_TST.1 Requires the capability to perform TSF self-tests
O.AUDIT.LOGGED Logging and authorized access to audit events.
FAU_GEN.1 Requires audit logging of relevant events.
FAU_SAR.1 Ensures that audit records can be reviewed by authorized users.
FAU_SAR.2 Supports audit review by preventing unauthorized access.
FAU_STG.1 Supports audit integrity by preventing unauthorized deletion.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
125
1
2
34
IEEE P2600.5/D31b31a, December 2007
Objectives Description SFRs PurposeFAU_STG.4 Supports audit
integrity by policy against loss of records.
FIA_UID.1 Supports audit function by requiring user ID.
FPT_STM.1 Supports audit function by requiring timestamps.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
126
1
2
34
IEEE P2600.5/D31b31a, December 2007
12 Security assurance requirements (APE_REQ)
Table 84 —P2600.5 Security Assurance Requirements
Assurance Class Assurance componentsADV: Development ADV_ARC.1 Security architecture description
ADV_FSP.2 Security-enforcing functional specification ADV_TDS.1 Basic design
AGD: Guidance documents AGD_OPE.1 Operational user guidanceAGD_PRE.1 Preparative procedures
ALC: Life-cycle support ALC_CMC.2 Use of a CM systemALC_CMS.2 Parts of the TOE CM coverageALC_DEL.1 Delivery proceduresALC_FLR.1 Basic flaw remediation (augmentation of EAL2)
ASE: Security Target evaluation ASE_CCL.1 Conformance claimsASE_ECD.1 Extended components definitionASE_INT.1 ST introductionASE_OBJ.2 Security objectivesASE_REQ.2 Derived security requirementsASE_SPD.1 Security problem definitionASE_TSS.1 TOE summary specification
ATE: Tests ATE_COV.1 Evidence of coverageATE_FUN.1 Functional testingATE_IND.2 Independent testing - sample
AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis
12.1 ADV_ARC.1 Security architectural description
Dependencies: ADV_FSP.1 Basic functional specification ADV_TDS.1 Basic design
Developer action elements:
ADV_ARC.1.1D The developer shall design and implement the TOE so that security features of the TSF cannot be bypassed.
ADV_ARC.1.2D The developer shall design and implement the TSF so that it is able to protect itself from tampering by untrusted active entities.
ADV_ARC.1.3D The developer shall provide a security architecture description of the TSF.
Content and presentation elements:
ADV_ARC.1.1C The security architecture description shall be at a level of detail commensurate with the description of the SFR-enforcing abstractions described in the TOE design document.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
127
1
2
1
2
3
45
6
78
910
11
12
131415
34
IEEE P2600.5/D31b31a, December 2007
ADV_ARC.1.2C The security architecture description shall describe the security domains maintained by the TSF consistently with the SFRs.
ADV_ARC.1.3C The security architectural description shall describe how the TSF initialisation process is secure.
ADV_ARC.1.4C The security architectural description shall demonstrate that the TSF protects itself from tampering.
ADV_ARC.1.5C The security architectural description shall demonstrate that the TSF prevents bypass of the SFR-enforcing functionality.
Evaluator action elements:
ADV_ARC.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.2 ADV_FSP.2 Security-enforcing functional specification
Dependencies: ADV_TDS.1 Basic design
Developer action elements:
ADV_FSP.2.1D The developer shall provide a functional specification.
ADV_FSP2.2D The developer shall provide a tracing from the functional specification to the SFRs.
Content and presentation elements:
ADV_FSP.2.1C The functional specification shall completely represent the TSF.
ADV_FSP.2.2C The functional specification shall describe the purpose and method of use for all TSFI.
ADV_FSP.2.3C The functional specification shall identify and describe all parameters associated with each TSFI.
ADV_FSP.2.4C For SFR-enforcing TSFIs, the functional specification shall describe the SFR-enforcing operations associated with the TSFI.
ADV_FSP.2.5C For SFR-enforcing TSFIs, the functional specification shall describe direct error messages resulting from processing associated with the SFR-enforcing actions.
ADV_FSP2.6C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.
Evaluator action elements:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
128
1
2
12
34
56
78
9
1011
12
13
14
15
16
17
18
19
2021
2223
2425
26
27
34
IEEE P2600.5/D31b31a, December 2007
ADV_FSP.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_FSP.2.2E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.
12.3 ADV_TDS.1 Basic design
Dependencies: ADV_FSP.2 Security-enforcing functional specification
Developer action elements:
ADV_TDS.1.1D The developer shall provide the design of the TOE.
ADV_TDS.1.2D The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design.
Content and presentation elements:
ADV_TDS.1.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.1.2C The design shall identify all subsystems of the TSF.
ADV_TDS.1.3C The design shall describe the behavior of each SFR-supporting or SFR –non-interfering TSF subsystem in sufficient detail to determine that it is not SFR-enforcing.
ADV_TDS.1.4C The design shall summarise the SFR-enforcing behaviour of the SFR-enforcing subsystems.
ADV_TDS.1.5C The design shall provide a description of the interactions among SFR-enforcing subsystems of the TSF, and between the SFR-enforcing subsystems of the TSF and other subsystems of the TSF.
ADV_TSD.1.6C The mapping shall demonstrate that all behavior described in the TOE design is mapped to the TSFIs that invoke it.
Evaluator action elements:
ADV_TDS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_TDS.1.2E The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements.
12.4 AGD_OPE.1 Operational user guidance
Dependencies: ADV_FSP.1 Basic functional specification
Developer action elements:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
129
1
2
12
34
5
6
7
8
910
11
12
13
1415
1617
181920
2122
23
2425
2627
28
29
30
34
IEEE P2600.5/D31b31a, December 2007
AGD_OPE.1.1D The developer shall provide operational user guidance.
Content and presentation elements:
AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.
AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner.
AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.
AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation.
AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST.
AGD_OPE.1.7C The operational user guidance shall be clear and reasonable.
Evaluator action elements:
AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.5 AGD_PRE.1 Preparative procedures
Dependencies: No dependencies.
Developer action elements:
AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures.
Content and presentation elements:
AGD_PRE.1.1C The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with developer's delivery procedures.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
130
1
2
1
2
345
67
89
10
111213
141516
171819
20
21
2223
24
25
26
27
28
2930
34
IEEE P2600.5/D31b31a, December 2007
AGD_PRE.1.2C The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.
Evaluator action elements:
AGD_PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AGD_PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation.
12.6 ALC_CMC.2 Use of a CM system
Dependencies: ALC_CMS.1 TOE CM coverage
Developer action elements:
ALC_CMC.2.1D The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.2.2D The developer shall provide the CM documentation.
ALC_CMC.2.3D The developer shall use a CM system.
Content and presentation elements:
ALC_CMC.2.1C The TOE shall be labelled with its reference.
ALC_CMC.2.2C The CM documentation shall describe the method used to uniquely identify the configuration items.
ALC_CMC.2.3C The CM system shall uniquely identify all configuration items.
Evaluator action elements:
ALC_CMC.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.7 ALC_CMS.2 Parts of the TOE CM coverage
Dependencies: No dependencies.
Developer action elements:
ALC_CMS.2.1D The developer shall provide a configuration list for the TOE.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
131
1
2
123
4
56
78
9
10
11
12
13
14
15
16
1718
19
20
2122
23
24
25
26
34
IEEE P2600.5/D31b31a, December 2007
Content and presentation elements:
ALC_CMS.2.1C The configuration list includes the following: the TOE itself; the evaluation evidence required by the SARs; and the parts that comprise the TOE.
ALC_CMS.2.2C The configuration list shall uniquely identify the configuration items.
ALC_CMS.2.3C For each TSF relevant configuration item, the configuration list shall indicate the developer of the item.
Evaluator action elements:
ALC_CMS.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.8 ALC_DEL.1 Delivery procedures
Dependencies: No dependencies.
Developer action elements:
ALC_DEL.1.1D The developer shall document procedures for delivery of the TOE or parts of it to the consumer.
ALC_DEL.1.1D The developer shall use the delivery procedures.
Content and presentation elements:
ALC_DEL.1.1C The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to the consumer.
Evaluator action elements:
ALC_DEL.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.9 ALC_FLR.1 Basic flaw remediation
Dependencies: No dependencies.
Developer action elements:
ALC_FLR.1.1D The developer shall document flaw remediation procedures addressed to TOE developers.
Content and presentation elements:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
132
1
2
1
23
4
56
7
89
10
11
12
1314
15
16
1718
19
2021
22
23
24
25
26
34
IEEE P2600.5/D31b31a, December 2007
ALC_FLR.1.1C The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.
ALC_FLR.1.2C The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw.
ALC_FLR.1.3C The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.
ALC_FLR.1.4C The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.
Evaluator action elements:
ALC_FLR.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.10 ATE_COV.1 Evidence of coverage
Dependencies: ADV_FSP.2 Security-enforcing functional specification ATE_FUN.1 Functional testing
Developer action elements:
ATE_COV.1.1D The developer shall provide evidence of the test coverage.
Content and presentation elements:
ATE_COV.1.1C The evidence of the test coverage shall show the correspondence between the tests in the test documentation and the TSFIs in the functional specification.
Evaluator action elements:
ATE_COV.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.11 ATE_FUN.1 Functional testing
Dependencies: ATE_COV.1 Evidence of coverage
Developer action elements:
ATE_FUN.1.1D The developer shall test the TSF and document the results.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
133
1
2
12
34
56
78
9
1011
12
1314
15
16
17
1819
20
2122
23
24
25
26
34
IEEE P2600.5/D31b31a, December 2007
ATE_FUN.1.2D The developer shall provide test documentation.
Content and presentation elements:
ATE_FUN.1.1C The test documentation shall consist of test plans, expected test results and actual test results.
ATE_FUN.1.2C The test plans shall identify the tests to be performed and describe the scenarios for performing each test. These scenarios shall include any ordering dependencies on the results of other tests.
ATE_FUN.1.3C The expected test results shall show the anticipated outputs from a successful execution of the tests.
ATE_FUN.1.4C The actual test results shall be consistent with the expected test results.
Evaluator action elements:
ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.12 ATE_IND.2 Independent testing - sample
Dependencies: ADV_FSP.2 Security-enforcing functional specification AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ATE_COV.1 Evidence of coverage ATE_FUN.1 Functional testing
Developer action elements:
ATE_IND.2.1D The developer shall provide the TOE for testing.
Content and presentation elements:
ATE_IND.2.1C The TOE shall be suitable for testing.
ATE_IND.2.2C The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF.
Evaluator action elements:
ATE_IND.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ATE_IND.2.2E The evaluator shall execute a sample of tests in the test documentation to verify the developer test results.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
134
1
2
1
2
34
567
89
10
11
1213
14
1516171819
20
21
22
23
2425
26
2728
2930
34
IEEE P2600.5/D31b31a, December 2007
ATE_IND.2.3E The evaluator shall test a subset of the TSF interfaces to confirm that the TSF operates as specified.
12.13 AVA_VAN.2 Vulnerability analysis
Dependencies: ADV_ARC.1 Security architectural description ADV_FSP.1 Basic functional specification ADV_TDS.1 Basic design AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures
Developer action elements:
AVA_VAN.2.1D The developer shall provide the TOE for testing.
Content and presentation elements:
AVA_VAN.2.1C The TOE shall be suitable for testing.
Evaluator action elements:
AVA_VAN.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AVA_VAN.2.2E The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE.
AVA_VAN.2.3E The evaluator shall perform an independent vulnerability analysis of the TOE using the guidance documentation, functional specification, TOE design and security architecture description to identify potential vulnerabilities in the TOE.
AVA_VAN.2.4E The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential.
12.14 ASE_CCL.1 Conformance claims
Dependencies: ASE_INT.1 ST introduction ASE_ECD.1 Extended components definition ASE_REQ.1 Stated security requirements
Developer action elements:
ASE_CCL.1.1D The developer shall provide a conformance claim.
ASE_CCL.1.2D The developer shall provide a conformance claim rationale.
Content and presentation elements:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
135
1
2
12
3
45678
9
10
11
12
13
1415
1617
181920
212223
24
252627
28
29
30
31
34
IEEE P2600.5/D31b31a, December 2007
ASE_CCL.1.1C The conformance claim shall contain a CC conformance claim that identifies the version of the CC to which the ST and the TOE claim conformance.
ASE_CCL.1.2C The CC conformance claim shall describe the conformance of the ST to CC Part 2 as either CC Part 2 conformant or CC Part 2 extended.
ASE_CCL.1.3C The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either CC Part 3 conformant or CC Part 3 extended.
ASE_CCL.1.4C The CC conformance claim shall be consistent with the extended components definition.
ASE_CCL.1.5C The conformance claim shall identify all PPs and security requirement packages to which the ST claims conformance.
ASE_CCL.1.6C The conformance claim shall describe any conformance of the ST to a package as either package-conformant or package-augmented.
ASE_CCL.1.7C The conformance claim rationale shall demonstrate that the TOE type is consistent with the TOE type in the PPs for which conformance is being claimed.
ASE_CCL.1.8C The conformance claim rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the PPs for which conformance is being claimed.
ASE_CCL.1.9C The conformance claim rationale shall demonstrate that the statement of security objectives is consistent with the statement of security objectives in the PPs for which conformance is being claimed.
ASE_CCL.1.10C The conformance claim rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the PPs for which conformance is being claimed.
Evaluator action elements:
ASE_CCL.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.15 ASE_OBJ.2 Security objectives
Dependencies: ASE_SPD.1 Security problem definition
Developer action elements:
ASE_OBJ.2.1D The developer shall provide a statement of security objectives.
ASE_OBJ.2.2D The developer shall provide a security objectives rationale.
Content and presentation elements:
ASE_OBJ.2.1C The statement of security objectives shall describe the security objectives for the TOE and the security objectives for the operational environment.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
136
1
2
12
34
56
7
89
1011
1213
141516
171819
202122
23
2425
26
27
28
29
30
31
3233
34
IEEE P2600.5/D31b31a, December 2007
ASE_OBJ.2.2C The security objectives rationale shall trace each security objective for the TOE back to threats countered by that security objective and OSPs enforced by that security objective.
ASE_OBJ.2.3C The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective.
ASE_OBJ.2.4C The security objectives rationale shall demonstrate that the security objectives counter all threats.
ASE_OBJ.2.5C The security objectives rationale shall demonstrate that the security objectives enforce all OSPs.
ASE_OBJ.2.6C The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions.
Evaluator action elements:
ASE_OBJ.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.16 ASE_ECD.1 Extended components definition
Dependencies: No dependencies.
Developer action elements:
ASE_ECD.1.1D The developer shall provide a statement of security requirements.
ASE_ECD.1.2D The developer shall provide an extended components definition.
Content and presentation elements:
ASE_ECD.1.1C The statement of security requirements shall identify all extended security requirements.
ASE_ECD.1.2C The extended components definition shall define an extended component for each extended security requirement.
ASE_ECD.1.3C The extended components definition shall describe how each extended component is related to the existing CC components, families, and classes.
ASE_ECD.1.4C The extended components definition shall use the existing CC components, families, classes, and methodology as a model for presentation.
ASE_ECD.1.5C The extended components shall consist of measurable and objective elements such that conformance or nonconformance to these elements can be demonstrated.
Evaluator action elements:
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
137
1
2
12
345
67
89
1011
12
1314
15
16
17
18
19
20
21
2223
2425
2627
2829
30
34
IEEE P2600.5/D31b31a, December 2007
ASE_ECD.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ASE_ECD.1.2E The evaluator shall confirm that no extended component can be clearly expressed using existing components.
12.17 ASE_INT.1 ST introduction
Dependencies: No dependencies.
Developer action elements:
ASE_INT.1.1D The developer shall provide an ST introduction.
Content and presentation elements:
ASE_INT.1.1C The ST introduction shall contain an ST reference, a TOE reference, a TOE overview and a TOE description.
ASE_INT.1.2C The ST reference shall uniquely identify the ST.
ASE_INT.1.3C The TOE reference shall identify the TOE.
ASE_INT.1.4C The TOE overview shall summarise the usage and major security features of the TOE.
ASE_INT.1.5C The TOE overview shall identify the TOE type.
ASE_INT.1.6C The TOE overview shall identify any non-TOE hardware/software/firmware required by the TOE.
ASE_INT.1.7C The TOE description shall describe the physical scope of the TOE.
ASE_INT.1.8C The TOE description shall describe the logical scope of the TOE.
Evaluator action elements:
ASE_INT.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ASE_INT.1.2E The evaluator shall confirm that the TOE reference, the TOE overview, and the TOE description are consistent with each other.
12.18 ASE_SPD.1 Security problem definition
Dependencies: No dependencies.
Developer action elements:
ASE_SPD.1.1D The developer shall provide a security problem definition.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
138
1
2
12
34
5
6
7
8
9
1011
12
13
14
15
1617
18
19
20
2122
2324
25
26
27
28
34
IEEE P2600.5/D31b31a, December 2007
Content and presentation elements:
ASE_SPD.1.1C The security problem definition shall describe the threats.
ASE_SPD.1.2C All threats shall be described in terms of a threat agent, an asset, and an adverse action.
ASE_SPD.1.3C The security problem definition shall describe the OSPs.
ASE_SPD.1.4C The security problem definition shall describe the assumptions about the operational environment of the TOE.
Evaluator action elements:
ASE_SPD.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.19 ASE_REQ.2 Derived security requirements
Dependencies: ASE_OBJ.2 Security objectives ASE_ECD.1 Extended components definition
Developer action elements:
ASE_REQ.2.1D The developer shall provide a statement of security requirements.
ASE_REQ.2.2D The developer shall provide a security requirements rationale.
Content and presentation elements:
ASE_REQ.2.1C The statement of security requirements shall describe the SFRs and the SARs.
ASE_REQ.2.2C All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined.
ASE_REQ.2.3C The statement of security requirements shall identify all operations on the security requirements.
ASE_REQ.2.4C All operations shall be performed correctly.
ASE_REQ.2.5C Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied.
ASE_REQ.2.6C The security requirements rationale shall trace each SFR back to the security objectives for the TOE.
ASE_REQ.2.7C The security requirements rationale shall demonstrate that the SFRs meet all security objectives for the TOE.
ASE_REQ.2.8C The security requirements rationale shall explain why the SARs were chosen.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
139
1
2
1
2
3
4
56
7
89
10
1112
13
14
15
16
17
1819
2021
22
2324
2526
2728
29
34
IEEE P2600.5/D31b31a, December 2007
ASE_REQ.2.9C The statement of security requirements shall be internally consistent.
Evaluator action elements:
ASE_REQ.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
12.20 ASE_TSS.1 TOE summary specification
Dependencies: ASE_INT.1 ST introduction ASE_REQ.1 Stated security requirements
Developer action elements:
ASE_TSS.1.1D The developer shall provide a TOE summary specification.
Content and presentation elements:
ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR.
Evaluator action elements:
ASE_TSS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ASE_TSS.1.2E The evaluator shall confirm that the TOE summary specification is consistent with the TOE overview and the TOE description.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
140
1
2
1
2
34
5
67
8
9
10
11
12
1314
1516
17
34
IEEE P2600.5/D31b31a, December 2007
Annex A normative) Glossary
For the purposes of this draft standard, the following terms and definitions apply. The Authoritative Dictionary of IEEE Standards, Seventh Edition, should be referenced for terms not defined in this clause.
Access: Interaction between an entity and an object that results in the flow or modification of data.
Access Control: Security service that controls the use of hardware and software resources and the disclosure and modification of stored or communicated data.
Accountability: Property that allows activities in an IT system to be traced to the entity responsible for the activity.
Administrator: An Operator who has been specifically granted the authority to manage some portion or all of the TOE and whose actions may affect the TSP. Administrators may possess special privileges that provide capabilities to override portions of the TSP.
Asset: An entity upon which the TOE owner places value.
Authentication: Security measure that verifies a claimed identity.
Authentication data: Information used to verify a claimed identity.
Authorization: Permission, granted by an entity authorized to do so, to perform functions and access data.
Authorized User: An authenticated user who may, in accordance with the TSP, perform an operation, including users who are permitted to perform some operations but may be able to attempt or perform operations that are beyond those permissions.
Compromise: Violation of a security policy.
Confidential: A condition in which information is accessible only to those authorized to have access.
Evaluation Assurance Level: An assurance package, consisting of assurance requirements drawn from CC Part 3, representing a point on the CC predefined assurance scale.
Identity: A representation (e.g., a string) uniquely identifying an authorized user, which can either be the full or abbreviated name of that user or a pseudonym.
Information assurance: Information operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities.
Information Technology (IT): The hardware, firmware and software used as part of a system to collect, create, communicate, compute, disseminate, process, store or control data or information.
Job: [formulate a definition based on PWG semantic model definition?, extended to include other hardcopy operations].
Object: An entity within the TSF scope of control that contains or receives information and upon which subjects perform operations.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
141
1
2
1
234
5
67
89
101112
13
14
15
16
171819
20
21
2223
2425
26272829
3031
3233
3435
34
IEEE P2600.5/D31b31a, December 2007
Operational Environment: The total environment in which a TOE operates. It includes the physical facility and any physical, procedural, administrative and personnel controls.
Protected: A condition in which data has not been changed or destroyed in an unauthorized way.
Security attributes: TSF data associated with subjects, objects, and users that are used for the enforcement of the TSP.
Subject: An entity within the TSC that causes operations to be performed.
Telephone Line: An electrical interface used to connect the TOE to the public switch telephone network for transmitting and receiving facsimiles.
Threat: Capabilities, intentions and attack methods of adversaries, or any circumstance or event, with the potential to violate the TOE security policy.
TSF scope of control (TSC): The set of interactions that can occur with or within a TOE and are subject to the rules of the TSP.
TOE Owner: person or group with overall responsibility for TOE assets and related security policies.
TOE security function (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.
TOE security policy (TSP): A description of the security properties of a TOE in the form of a set of SFRs in a protection profile or security target.
Unauthorized User: An Operator who is not permitted to access or use the TOE for a defined purpose, including users who are permitted to access and use the TOE for other defined purposes in addition to those who are permitted to be physically proximate to the TOE or who are permitted to access a network to which the TOE is connected.
User: An entity (human user or external IT entity) outside the TOE that interacts with the TOE.
User Document Data: Information contained in an Operator's document, including the original document itself in either hardcopy or electronic form, image data or residually-stored data created by the hardcopy device while processing an original document and printed hardcopy output.
User Function Data: Information about users that the HCD applications use, excluding authentication data (e.g. passwords), but including user identifiers for access control, destination lists for scanning and address books for facsimile delivery.
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
142
1
2
12
3
45
6
78
910
1112
13
1415
1617
18192021
22
232425
262728
34
IEEE P2600.5/D31b31a, December 2007
Annex B Acronyms
Acronym DefinitionA. assumptionADMIN. administratorALT alterationCC Common CriteriaC/IA IEEE Computer Society Information AssuranceCM configuration managementCONF. confidentialCPY copyD. dataDIS disclosureDOC. documentDSR document storage and retrievalEAL evaluation assurance levelFUNC functionHCD hardcopy deviceID identificationIEEE Institute of Electrical and Electronics EngineersIT information technologyMFD multifunctional deviceMFP multifunctional product / peripheral / printerNIC network interface cardNVS nonvolatile storageO. security objective (of the TOE)OE. security objective (of the operational environment)OTHERTOE another TOEOSP organizational security policyP primaryP. organizational security policyPP protection profilePROT protectedPRT printS supportS. subjectSAL salvageSAR security assurance requirementSCN scanSFP security function policySFR security functional requirementST security targetStd standardT. threatTOE target of evaluationTSF TOE security functionalityTSC TOE scope of controlTSFI TOE security functionality interfaceTSP TOE security policyU. user
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
143
1
2
1
34
IEEE P2600.5/D31b31a, December 2007
Annex B
Copyright © 2007 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.
144
1
2
1
34
Recommended