grouper.ieee.orggrouper.ieee.org/groups/2600/email/doc00074.doc · Web viewPrepared by the Hardcopy Device and System Security Working Group of the IEEE Computer Society Information

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


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


ii

1

2

123456789

10111213

34


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)


iii

1

2

1

23456789

1011121314151617

18

1920212223

24

25262728

29

30

31323334353637

38394041424344

4546474849

505152535455

34


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


iii

1

2

1

2345678

34


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


iii

1

2

1

2

34

5

6

7

8

910111213

14

15161718

19

202122232425

26

272829303132

33

34353637

34


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


iv

1

2

12

3

456789

10

111213141516

17

1819202122232425262728293031323334353637

38

39

40

4142

34


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


1

1

2

1

2

3

4

56789

10

11

121314

15

1617181920

212223

242526

34


[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]


2

1

2

123

456

78

9

101112

34

http://www.commoncriteriaportal.org/public/files/CEMV3.1R1.pdf


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


3

1

2

1

23456789

1011

1213

14151617181920212223242526272829303132

333435363738394041424344

45464748495051

34

bsmithson, 06/15/07,

When publishing this PP for evaluation, we will have a different cover page and start the document here. The PP front matter will need to provide some acknowledgement and reference to the IEEE standard.


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.


4

1

2

12345

6789

101112131415161718

19202122232425262728293031

34


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


5

1

2

1

2

3456789

101112131415161718192021

22

232425

26

27

2829

30

313233343536373839404142434445

34


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.


6

1

2

1234

5

6789

1011

12

13

141516

17

1819

2021

2223242526

27

28293031323334353637

34


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’.


7

1

2

1

2

3

4

56

7

89

1011

34


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:


8

1

2

1

23

4

56

7

89

10

111213

34


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


9

1

2

12345

67

89

10111213

1415

1617181920

212223

24

25

34


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


10

1

2

1

2

34


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.


11

1

2

123

4567

89

10111213

14

15161718

19

20

21

2223242526272829303132333435363738

34


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.


12

1

2

1

2

345

34


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.


13

1

2

1

2

34

5

6

7

89

10

11121314151617

18192021

2223

34


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.


14

1

2

1

2

3

45678

910

1112

1314

15161718192021

22

2324

252627

34


Figure 7—Print TOE model

Print

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

Print

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.


15

1

2

1

23

4

5

6

789

10

1112

34


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:


16

1

2

12

34

567

89

10

11

12

13141516

17

1819

20212223

24

2526

34


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


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.


17

1

2

1

2

3

4

56

7

8

9101112

34


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.


18

1

2

1

2

345

6

7

8

9

10

34


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.


19

1

2

1

2

3

4

5

67

8

9

1011

34


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.


20

1

2

1

2

3

4

5

6

78

9

10

34


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:



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


21

1

2

1

2

4

5

67

8

91011

121314

1516

17

181920

21222324

2526

34


{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:


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


22

1

2

12

34

5678

910

1112

131415161718

1920

21

22

23

24

34


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


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


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.


23

1

2

1234

5

7

8

91011

121314

151617

181920

21

22

24

25

262728

293031

34


PP APPLICATION NOTE— FAU_SAR.2 is a requirement which fulfills O.AUDIT.LOGGED

FAU_STG.1 Protected audit trail storage



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”,


24

1

2

1

2

4

5

678

91011

12

13

15

16

17181920212223242526272829303132333435363738

34


“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.


7.5.3 Class FCO: Communication

There are no Class FCO security functional requirements for the PRT TOE.


25

1

2

123456789

10

1112131415161718192021222324252627282930313233343536373839404142

43

44

45

34


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


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


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


26

1

2

1

2

3

4

6

7

89

10

111213

14

15

17

1819

2021222324

2526272829

3031

34


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


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.


27

1

2

123

4567

89

10

11

12

13

15

16

1718192021

222324

2526

34


FIA_ATD.1 User attribute definition


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



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


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.


28

1

2

1

3

4

567

89

10

11

13

14

151617

1819

20

21

23

24

252627

282930

34


For PP-B,C,D: four (4) numeric characters


{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



{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



{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.


29

1

2

123

456

7

8

10

11

121314

151617

1819

20

22

23

242526

272829

34


(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


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


30

1

2

123

456

7

8

9

11

12131415

1617181920

2122232425

26

27

34


FMT_MSA.3 Static attribute initialisation


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


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.


31

1

2

1

3

456

789

10

11121314

15161718

19

20

22

232425

26272829

3031

323334

34


FMT_SMF.1 Specification of Management Functions



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


32

1

2

1

3

4

567

8

10

11

121314

151617

18

19

20

212223

34


FMT_SMR.1 Security roles



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



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


33

1

2

1

3

4

56

7

89

1011

12

13

14

15

16

18

19

2021

22

34


FPT_TST.1 TSF testing


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].


integrity of stored TSF executable code}


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.


34

1

2

1

3

4

56789

10

111213141516

17181920

2122232425

26272829

31323334

36

37

38

39

40

34


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.


35

1

2

1

2

3

456

7

8

9

34


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


FMT_MTD.1

Prevents alteration by restricting access.



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.


36

1

2

1

34


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.


37

1

2

1

2

3

45678

91011

1213

14151617181920212223

24

2526

2728

34


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


Channel

Scan

REST

8.1.2 Major security features of the SCN TOE

The major security features of the Scan TOE are:


38

1

2

1

23

45

6

78

34


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.



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




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:


39

1

2

12

34

56

78

91011

121314

15

16

17181920

21

2223

24252627

28

29

3031

34


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


N/A


N/A


N/A

8.2.2 SCN Threats


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





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.


40

1

2

1

2

3

4

5

6

7

8

9101112

34


Table 25 —Organizational Security Policies for the SCN TOE



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


8.2.4 SCN Assumptions


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





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.CONF.REST.NO_ALT The TOE shall protect TSF Confidential Data in the TOE from unauthorized alteration.


41

1

2

1

2

345

6

7

8

9

10

34


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.



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.









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.


42

1

2

1

2

3

4

5

67

8

9

1011

34


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.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.


43

1

2

1

2

3

4

5

6

78

9

10

34


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.












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




44

1

2

1

2

4

5

67

8

91011

121314

1516

17

181920

21222324

2526

2728

2930

34





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



Table 32 —SCN Audit data recommendations


Minimal User identity, actions taken as a result, and if appropriate, subsequent restoration to the normal state

FIA_AFL.1




45

1

2

1234

56

78

91011121314

1516

17

18

19

20

21222324

34













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.



46

1

2

1

2

4

5

678

91011

121314

151617

18

19

21

22

232425

262728

29

34











{FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthoriseduserwithspecialrights”,“overwritetheoldest


47

1

2

1

3

4

567

89

10

11

12

14

15

16171819202122232425262728293031323334353637383940

34


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.



There are no Class FCO security functional requirements for the SCN Protection Profile.


There are no Class FCS security functional requirements for the SCN Protection Profile.


48

1

2

12345678

91011121314151617181920212223242526272829303132333435363738394041

42

43

44

45

46

34







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.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].


49

1

2

1

2

4

5

678

91011

12

13

15

161718

1920212223

2425262728

2930313233

34










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.






50

1

2

1234

567

8

9

10

12

13

1415161718

192021

2223

24

26

27

282930

34


















51

1

2

123

4

6

7

89

10

1112

13

14

16

17

181920

212223

242526

272829

30

34















{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.}




52

1

2

1

3

4

567

89

10

1112

13

15

16

171819

202122

232425

262728

29

34







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].







FMT_MSA.3.1The TSF shall enforce the SCN Access Control SFP to provide [selection, choose one of:


53

1

2

1

2

4

56789

1011121314

1516171819

20

21

22

24

252627

28293031

3233

34


restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP.







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.





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.


54

1

2

12

3456

7

8

10

111213

14151617

1819

202122

23

25

26

272829

303132

34


Need to decide which to include as a minimum set


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










There are no Class FPR security functional requirements for the SCN Protection Profile.


55

1

2

1

2

3

456

7

9

10

1112

13

1415

1617

18

19

20

34








FPT_TST.

TSF testin








integrity of [selection: [assignment: parts of TSF], TSF data].}


operators with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].


56

1

2

1

2

4

5

67

8

91011

14

15

161718192021

222324252627

28293031

32333435

34



integrity of stored TSF executable code.}


operators with the capability to verify the integrity of stored TSF executable code.



There are no Class FRU security functional requirements for the SCN Protection Profile.


There are no Class FTA security functional requirements for the SCN Protection Profile.


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


57

1

2

1234

567

9

10

11

12

13

14

15

16

171819

20

34


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


FMT_MTD.1







FMT_MTD.1




O.OPERATOR.AUTHORIZED,O.ADMIN.AUTHORIZED





58

1

2

1

2

34


Objectives Description SFRs PurposeFIA_SOS.1 Supports authentication by

requiring minimum strength of authentication secrets.















59

1

2

1

34


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



60

1

2

1

2

3

45678

910

11

1213

14151617181920

21

2223

24

34


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


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.


61

1

2

1

23

456

7

89

1011

34


b) Information associated with processing CPY jobs is protected from alteration by anyone except for the Originator and 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




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


62

1

2

12

34

56

789

101112

13

14

15161718

19

2021

22232425

26

2728

29

34


Asset Rationale See alsoD.DOC.RETRIEVE The CPY TOE does not retain User User Document Data after

completion of a jobDSR


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


N/A


N/A


N/A

9.2.2 CPY Threats


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





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



the TOE only as permitted by the TOE OwnerP.SOFTWARE.VERIFICATION To detect malicious modification of TOE software, procedures will


P.AUDIT.LOGGING To preserve accountability and security, records that provide an audit trail of TOE use and security-relevant events will be


63

1

2

1

2

3

45

6

7

89

1011

12

34


maintained and protected from unauthorized disclosure or alteration by the TOE, and will be reviewed by authorized personnel

9.2.4 CPY Assumptions


Table 42 —Assumptions for the CPY TOE







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.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.




64

1

2

1

234

5

6

7

8

9

34


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.









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


65

1

2

1

2

3

4

5

67

8

9

1011

12

34


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.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.


66

1

2

1

2

3

4

5

67

8

9

34


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.












events listed in Table 47—CPY Audit data requirements”; assignment:other specifically defined auditable event].


67

1

2

1

2

4

5

67

8

91011

121314

1516

17

181920

21222324

34


PP APPLICATION NOTE— Table 48—CPY Audit data recommendations” lists additional auditable events that are recommended for consideration in FAU_GEN.1.1






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


availableFIA_UID.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


68

1

2

12

34

56

789

10

1112

1314

151617181920

2122

23

24

25

34


Attempts to authenticate reach failure limit


FIA_AFL.1












69

1

2

1

2345

6

8

9

101112

131415

161718

192021

22

34

















{FAU_STG.4.1The TSF shall[selection,choose


70

1

2

1

3

4

567

89

10

11

12

14

15

161718

192021

22

23

25

26

27282930

34


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


71

1

2

123456789

10111213141516171819202122232425262728

2930313233343536373839404142434445464748495051525354

34


auditrecords”]and [assignment: otheractions to be taken in case of audit storage failure] if the audit trailisfull.



There are no Class FCO security functional requirements for the CPY Protection Profile.


There are no Class FCS security functional requirements for the CPY Protection Profile.






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.1The TSF shall enforce the [assignment: access control SFP] to objects based on the


72

1

2

123456

7

8

9

10

11

12

13

15

16

171819

202122

23

24

26

2728

2930

34


Need to complete this assignment


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].










FIA_AFL.1.2When the defined number of unsuccessful authentication attempts has been selection: met, surpassed] the TSF shall [assignment: list of actions].


73

1

2

123

45678

910111213

14151617

181920

21

22

23

25

26

2728293031

323334

34










PP APPLICATION NOTE— FDP_AC C.1 is a requirement which fulfills O.OPERATOR.AUTHORIZED and O.ADMIN.AUTHORIZED.

















74

1

2

12

3

5

6

789

101112

13

15

16

171819

2021

22

23

25

26

272829

34



















75

1

2

123

456

789

10

11

13

14

151617

181920

2122

23

25

26

272829

34











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].




76

1

2

123

456

789

10

11

12

14

1516171819

2021222324

2526272829

30

31

34






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.








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.


77

1

2

1

3

456

789

10

11121314

15161718

19

20

22

232425

26272829

3031

323334

34






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


FAU_SAR.1


PP APPLICATION NOTE— FMT_SMF.1 is a dependency of FMT_MSA.1 and FMT_MTD.1










78

1

2

1

3

4

567

89

10

11

12

13

141516

17

19

20

2122

23

2425

2627

34






There are no Class FPR security functional requirements for the CPY Protection Profile.







FPT_TST.

TSF testin










79

1

2

1

2

3

4

5

7

8

910

11

121314

17

18

192021222324

252627282930

31323334

34



operator with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].




operator with the capability to verify the integrity of stored TSF executable code.



There are no Class FRU security functional requirements for the CPY Protection Profile.


There are no Class FTA security functional requirements for the CPY Protection Profile.


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.


80

1

2

12345

6789

11121314

16

17

18

19

20

21

22

23

242526

34


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


FMT_MTD.1 Prevents disclosure by restricting access.




81

1

2

1

2

3

4

34


Objectives Description SFRs PurposeO.PROT.REST.NO_ALT, O.CONF.REST.NO_ALT



FMT_MTD.1 Prevents alteration by restricting access.



O.USER.AUTHORIZED,O.ADMIN.AUTHORIZED



















82

1

2

12

34


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



83

1

2

1

2

3

45678

9

1011

1213

14151617181920212223

24

252627

2829

34


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


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.


84

1

2

1

23

45

6

789

10

34


b) Information associated with processing DSR jobs is protected from alteration by anyone except for the Originator, authorized Delegates, 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.


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


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


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:


85

1

2

12

34

56

789

10111213

14

15

16171819

20

2122

2324252627

28

2930

34


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


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


N/A


N/A


N/A

10.2.2 DSR Threats


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





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.


86

1

2

1

2

3

4

5

6

7

89

1011

34


Table 57 —Organizational Security Policies for the DSR TOE


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



10.2.4 DSR Assumptions


Table 58 —Assumptions for the DSR TOE







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.



87

1

2

1

2

345

6

7

8

9

10

34


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.



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.



opportunity for unauthorized physical access to the TOE.OE.OPERATOR.TRAINED The TOE owner shall ensure that TOE Operatorsare aware of the security


OE.OPERATOR.TRUSTED The TOE owner shall take steps to establish trust that TOE Operatorswill not use their privileged access rights for malicious purposes.




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.


88

1

2

1

2

3

4

5

67

8

9

1011

34


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.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.


89

1

2

1

2

3

4

5

6

78

9

10

34


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.












events listed in Table 63—DSR Audit data requirements”; assignment:other specifically defined auditable event].


90

1

2

1

2

4

5

67

8

91011

121314

1516

17

181920

21222324

34


PP APPLICATION NOTE— Table 64—DSR Audit data recommendations” lists additional auditable events that are recommended for consideration in FAU_GEN.1.1






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


availableFIA_UID.1




Table 64 —DSR Audit data recommendations



FIA_AFL.1


91

1

2

12

34

56

789

10

1112

1314

151617181920

2122

23

24

25

34

















92

1

2

1

2345

6

8

9

101112

131415

161718

192021

22

23

25

26

272829

34



PP APPLICATION NOTE— FAU_SAR.2 is a requirement which fulfills O.AUDIT.LOGGED










{FAU_STG.4.1The TSF shall[selection,chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbythe


93

1

2

123

4

5

7

8

91011

121314

15

16

18

19

2021222324252627282930313233343536

34


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.



94

1

2

123456789

101112131415

1617181920212223242526272829303132333435363738394041424344454647

48

34



There are no Class FCO security functional requirements for the DSR Protection Profile.


There are no Class FCS security functional requirements for the DSR Protection Profile.






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.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].


95

1

2

1

2

3

4

5

6

8

9

101112

131415

16

17

19

202122

2324252627

2829303132

34






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










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.


96

1

2

12

34567

89

1011

121314

15

16

17

19

20

2122232425

262728

2930

34

























97

1

2

1

3

4

567

89

10

11

13

14

151617

1819

20

21

23

24

252627

282930

34



















98

1

2

123

456

7

8

10

11

121314

151617

1819

20

22

23

242526

272829

34










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].




99

1

2

123

456

7

8

9

11

12131415

1617181920

2122232425

26

27

34






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.








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.


100

1

2

1

3

45

6789

10111213

14151617

18

19

21

2223

24252627

2829

303132

34






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


FAU_SAR.1


PP APPLICATION NOTE— FMT_SMF.1 is a dependency of FMT_MSA.1 and FMT_MTD.1.






PP APPLICATION NOTE— recommended minimum to be specified in FMT_SMR.1: Administrator and DSR Operator




101

1

2

1

3

4

567

89

10

11

12

13

141516

17

19

20

2122

2324

2526

2728

34


Need to decide which to include as minimum set




There are no Class FPR security functional requirements for the DSR Protection Profile.







FPT_TST.

TSF testin










102

1

2

1

2

3

4

5

7

8

910

11

121314

17

18

192021222324

252627282930

31323334

34



operators with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].







There are no Class FRU security functional requirements for the DSR Protection Profile.


There are no Class FTA security functional requirements for the DSR Protection Profile.


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


103

1

2

1234

5678

101112

14

15

16

17

18

19

20

21

222324

25

34


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.



104

1

2

1

2

34


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.



O.CONF.REST.NO_DIS Protection of TSF Data from unauthorized disclosure


FMT_MTD.1







FMT_MTD.1




O.USER.AUTHORIZED,O.ADMIN.AUTHORIZED









105

1

2

34


Objectives Description SFRs PurposeO.SOFTWARE.VERIFIED Verification

of software integrity











106

1

2

34


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.


Figure 15 —Nonvolatile storage TOE model

Nonvol. Storage

User Data

User Document Data

Administrator

TSF Data

User

REST DELETEDREST


107

1

2

1

2

3

456789

10

111213

1415161718

19

2021

22

232425

34


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.



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


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


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


108

1

2

1

2345

67

89

1011

121314

15

16

17181920

21

2223

24

34


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


N/A


N/A


N/A

11.2.2 NVS Threats


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


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.


109

1

2

12

3

4

5

6

7

8

9101112

34


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


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



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.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.


110

1

2

1

2

345

6

7

8

9

10

34


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.


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.



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.



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.


111

1

2

1

2

3

4

5

67

8

9

1011

34


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.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.


112

1

2

1

2

3

4

5

6

78

9

10

34













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


Date and time of the event, type of event, subject identit (if applicable), and th outcome (success or failure) of the event; and




113

1

2

1

2

4

5

67

8

91011

121314

1516

17

181920

21222324

2526

2728

293031

32333435

3637

34



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




Table 80 —NVS Audit data recommendations

Auditable event Audit level Additional information Relevant SFRAttempts to authenticate reach failure limit


FIA_AFL.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






114

1

2

12

345678

910

11

12

13

14

151617

18

20

21

222324

34










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.







115

1

2

123

456

789

10

11

13

14

151617

181920

21

22

24

25

262728

34







{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,


116

1

2

123

4

5

7

8

9101112131415161718192021222324252627282930313233343536373839404142

434445

34


chooseoneof:“ignoreauditedevents”,“preventauditedevents,exceptthosetakenbytheauthorisedoperatorwithspecialrights”,“overwritetheoldeststoredauditrecords”]and[assignment:otheractions to be taken in case of audit storage failure] if the audit trailisfull.



There are no Class FCO security functional requirements for the NVS Protection Profile.


There are no Class FCS security functional requirements for the NVS Protection Profile.


117

1

2

123456789

10111213141516171819202122232425262728293031

32

33

34

35

36

34



FDP_RIP.1 Subset residual information protection



{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.






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.


118

1

2

1

2

4

5

6789

10111213

1415

16

17

19

20

2122232425

262728

29

34















PP APPLICATION NOTE— FIA_UAU.7 is a requirement which fulfills O.ADMIN.AUTHORIZED.


119

1

2

1

3

4

567

89

10

111213

141516

17

18

20

21

222324

252627

28

34

















120

1

2

1

3

4

567

89

10

111213

141516

17

18

19

21

222324

25262728

2930

34






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


FAU_SAR.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








PP APPLICATION NOTE— FMT_SMR.1 is a dependency of FMT_MTD.1.


121

1

2

1

3

4

567

89

10

11

12

13

1415

16

18

19

2021

22

2324

2526

27

34





There are no Class FPR security functional requirements for the NVS Protection Profile.







FPT_TST.

TSF testin




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]}


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

authorized operators with the capability to verify the integrity of [selection: [assignment: parts of TSF], TSF data].


122

1

2

1

2

3

4

6

7

89

10

111213

16

17

18192021222324

252627282930

31323334

35363738

34








There are no Class FRU security functional requirements for the NVS Protection Profile.


There are no Class FTA security functional requirements for the NVS Protection Profile.


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


123

1

2

1234

678

10

11

12

13

14

15

16

17

181920

21

34


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


FMT_MTD.1







FMT_MTD.1



124

1

2

1

2

34


Objectives Description SFRs PurposeFMT_SMF.1 Supports control of

security attributes by requiring functions to control attributes.


O.ADMIN.AUTHORIZED Authorization of users and administrators to use the TOE.






FIA_USB.1 Provides authorization by associating attributes with authenticated users.


FPT_AMT.1 Supports TSF testing by providing capability of testing the underlying abstract machine








125

1

2

34


Objectives Description SFRs PurposeFAU_STG.4 Supports audit

integrity by policy against loss of records.




126

1

2

34


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.


127

1

2

1

2

3

45

6

78

910

11

12

131415

34


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


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.


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.



128

1

2

12

34

56

78

9

1011

12

13

14

15

16

17

18

19

2021

2223

2425

26

27

34


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


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.


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.


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



129

1

2

12

34

5

6

7

8

910

11

12

13

1415

1617

181920

2122

23

2425

2627

28

29

30

34


AGD_OPE.1.1D The developer shall provide operational user guidance.


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.


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



AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures.


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.


130

1

2

1

2

345

67

89

10

111213

141516

171819

20

21

2223

24

25

26

27

28

2930

34


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.


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


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.


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.


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



ALC_CMS.2.1D The developer shall provide a configuration list for the TOE.


131

1

2

123

4

56

78

9

10

11

12

13

14

15

16

1718

19

20

2122

23

24

25

26

34



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.


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



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.


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.


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



ALC_FLR.1.1D The developer shall document flaw remediation procedures addressed to TOE developers.



132

1

2

1

23

4

56

7

89

10

11

12

1314

15

16

1718

19

2021

22

23

24

25

26

34


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.


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


ATE_COV.1.1D The developer shall provide evidence of the test coverage.


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.


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


ATE_FUN.1.1D The developer shall test the TSF and document the results.


133

1

2

12

34

56

78

9

1011

12

1314

15

16

17

1819

20

2122

23

24

25

26

34


ATE_FUN.1.2D The developer shall provide test documentation.


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.


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


ATE_IND.2.1D The developer shall provide the TOE for testing.


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.


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.


134

1

2

1

2

34

567

89

10

11

1213

14

1516171819

20

21

22

23

2425

26

2728

2930

34


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


AVA_VAN.2.1D The developer shall provide the TOE for testing.


AVA_VAN.2.1C The TOE shall be suitable for testing.


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


ASE_CCL.1.1D The developer shall provide a conformance claim.

ASE_CCL.1.2D The developer shall provide a conformance claim rationale.



135

1

2

12

3

45678

9

10

11

12

13

1415

1617

181920

212223

24

252627

28

29

30

31

34


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.


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


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.


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.


136

1

2

12

34

56

7

89

1011

1213

141516

171819

202122

23

2425

26

27

28

29

30

31

3233

34


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.


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



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.


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.



137

1

2

12

345

67

89

1011

12

1314

15

16

17

18

19

20

21

2223

2425

2627

2829

30

34


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



ASE_INT.1.1D The developer shall provide an ST introduction.


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.


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



ASE_SPD.1.1D The developer shall provide a security problem definition.


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



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.


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


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.


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.


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


ASE_REQ.2.9C The statement of security requirements shall be internally consistent.


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


ASE_TSS.1.1D The developer shall provide a TOE summary specification.


ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR.


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.


140

1

2

1

2

34

5

67

8

9

10

11

12

1314

1516

17

34


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.


141

1

2

1

234

5

67

89

101112

13

14

15

16

171819

20

21

2223

2425

26272829

3031

3233

3435

34


This is the glossary from version 22a – NEEDS A COMPLETE UPDATE


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.


142

1

2

12

3

45

6

78

910

1112

13

1415

1617

18192021

22

232425

262728

34


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


143

1

2

1

34


Annex B


144

1

2

1

34

Documents

grouper.ieee.orggrouper.ieee.org/groups/2600/email/doc00074.doc · Web viewPrepared by the Hardcopy Device and System Security Working Group of the IEEE Computer Society Information