spastyle.docgrouper.ieee.org/groups/2600/email/doc00022.doc · Web viewIEEE P2600™/PP 1.73....

IEEE P2600™/PP 1.732

Last Edited: November 26, 2004

DraftProtection Profile forHardcopy Systems and Devicesfor High Security Environments

Sponsored by theInformation Assurance Committeeof the IEEE Computer Society

Copyright © 2004 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

November 26, 2004 IEEE P2600/PP 1.7273

1 Forward

Hardcopy Systems and Devices (HSDHCDs) are a category of information technology products that process paper documents as input and/or output. For the purposes of this document, this category is composed of printing, copying, scanning, and facsimile devices, and systems that combine one or more of those functions into a multifunctional device product (MFDMFP).

Typical applications of HSDHCDs involve physical connection to other devices via telephone lines and wired and wireless networks, and logical connection to other devices using a variety of networking services and protocols. Establishing the security of HSDHCDs is therefore a critical part of any information systems security plan where HSDHCDs are present. Protection Profiles for HSDHCDs are intended to provide the basis for evaluating the security functions of HSDHCDs and help ensure that the security objectives of an information systems environment can be met.

This document, “Protection Profile for Hardcopy Systems and Devices for High Security Environments”, describes the assumptions, threats, objectives, and requirements, related to the use of HSDHCDs in an information technology environment where a relatively high level of security is required. Other Protection Profiles have been developed for HSDHCDs in other security environments. Those environments are defined within the Protection Profile documents, and their definitions are based on guidelines established by NIST.

This Protection Profile has been developed by the Hardcopy Security Working Group of the Institute of Electrical and Electronic Engineers (IEEE) as part of the IEEE P2600™ “Standard for Information Technology: Hardcopy System and Device Security”. It is designed for use in two contexts:

1. As a standalone reference document for ISO/IEC 15408 (“Common Criteria”) certification; and,2. As a section within the IEEE P2600™ standard.

This Protection Profile is based on the “Common Criteria for Information Technology Security Evaluations, Version 2.2”.

Further information about this Protection Profile and the IEEE P2600™ project, including status and updates, can be obtained at http://grouper.ieee.org/groups/2600/. Comments on this document should be directed to the Chairperson of the P2600™ working group, whose contact information is listed on that web site.

Copyright © 2004 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change. 2


Contents

Forward.................................................................................................................................................... 2

Contents................................................................................................................................................. 35

List of Tables........................................................................................................................................... 6

List of Figures.......................................................................................................................................... 6

Revision History....................................................................................................................................... 7

1 Introduction...................................................................................................................................... 8

1.1 Identification............................................................................................................................. 8

1.2 Protection Profile Overview......................................................................................................8

2 TOE Description............................................................................................................................... 9

2.1 TOE Terminology..................................................................................................................... 9

2.2 TOE Functional Description....................................................................................................11

2.2.1 Actors.............................................................................................................................. 11

2.2.2 Accesses.......................................................................................................................... 11

2.2.3 Assets.............................................................................................................................. 12

2.3 TOE Architectural Description................................................................................................13

2.3.1 Original Document Handler.............................................................................................13

2.3.2 Hardcopy Output Handler................................................................................................14

2.3.3 Data Interface.................................................................................................................. 14

2.3.4 Media Marking Path........................................................................................................ 14

2.3.5 Operator Interface............................................................................................................ 14

2.3.6 External Device Interface................................................................................................14

2.3.7 Maintenance Ports...........................................................................................................14

2.3.8 Marker/Consumables Interface.........................................................................................14

2.3.9 Input Media Interface.......................................................................................................15

2.3.10 System Processor and Memory/Storage............................................................................15

3 TOE Security Environment.............................................................................................................16

3.1 Secure Usage Assumptions......................................................................................................16



3.1.1 A.ADMIN (Administrator trust and competence).............................................................16

3.1.2 A. USER (User responsibility).........................................................................................16

3.1.3 A.ACCESS (Limited access)............................................................................................16

3.2 Threats to Security.................................................................................................................. 17

3.2.1 T.UD (Unauthorized access to User Documents)..............................................................17

3.2.2 T.RESOURCE (Unauthorized use of Resources)..............................................................17

3.2.3 T.DOS (Denial or impediment of services of the TOE)....................................................17

3.2.4 T.EA (Attacks on external systems in the IT environment)...............................................18

3.2.5 T.TSF (Accessing or altering TOE Security Functions)....................................................19

3.3 Organizational Security Policies..............................................................................................19

4 Security Objectives......................................................................................................................... 20

4.1 Security Objectives for the TOE..............................................................................................20

4.1.1 O.I&A (User identification and authentication)................................................................20

4.1.2 O.ACCESS (User authorization)......................................................................................20

4.1.3 O.DELETE (Deletion of residual data)............................................................................20

4.1.4 O.PROTECT (Protection of documents and data)............................................................20

4.1.5 O.NETWORK (Protecting transmitted data and resources)..............................................20

4.1.6 O.MONITOR (Monitoring)..............................................................................................20

4.1.7 O.RESILIENT (Mitigation of DOS attack)......................................................................20

4.1.8 O.GENUINE (Assurance of genuine TOE)......................................................................21

4.2 Security Objectives for the Environment.................................................................................22

4.2.1 Security objectives for the IT environment.......................................................................22

4.2.2 Security objectives for the non-IT environment................................................................22

5 Security Functional Requirements...................................................................................................24

5.1 TOE Security Functional Requirements...................................................................................24

5.1.1 Security audit (FAU)........................................................................................................24

5.1.2 Communication (FCO).................................................................................................2725

5.1.3 User data protection (FDP)...........................................................................................2826



5.1.4 Identification and authentication (FIA).........................................................................3027

5.1.5 Security management (FMT)........................................................................................3228

5.1.6 Protection of the TOE Security Functions (FPT)..........................................................3429

5.1.7 Trusted path/channels (FTP)........................................................................................3529

5.2 TOE Security Assurance Requirements...............................................................................3630

5.2.1 Configuration management (ACM)..............................................................................3731

5.2.2 Delivery and operation (ADO).....................................................................................3832

5.2.3 Guidance documents (AGD)........................................................................................3933

5.2.4 Life cycle support (ALC).............................................................................................4034

5.2.5 Security Target (ASE)..................................................................................................4135

5.3 Security Requirements for the IT Environment....................................................................4135

6 Rationale..................................................................................................................................... 4236

6.1 Security Objectives Rationale..............................................................................................4236

6.2 Security Requirements Rationale.........................................................................................4337

6.2.1 Functional Security Requirements Rationale................................................................4337

6.2.2 Rationale for minimum strength of function level........................................................4438

6.2.3 Rationale for assurance requirements...........................................................................4438

6.2.4 Mutual support of security requirements......................................................................4539

6.3 Dependency Rationale......................................................................................................... 4842

7 Acronyms.................................................................................................................................... 5145



List of Tables

Table 1. Asset Terminology..................................................................................................................... 9

Table 2. Actor Terminology..................................................................................................................... 9

Table 3. Access Terminology................................................................................................................. 10

Table 4. Miscellaneous Terminology......................................................................................................10

Table 5. T.UD Threats............................................................................................................................ 17

Table 6. T.DOS Threats......................................................................................................................... 18

Table 7. T.EA Threats............................................................................................................................ 18

Table 8. T.TSF Threats.......................................................................................................................... 19

Table 9. Assurance Requirements: EAL (2) …………………….………………………………………….26

Table 10. Correspondence between security needs and security objectives………………………………...33

Table 11. Functional Component to Security Objective Mapping…………...……………………………..37

Table 12. Functional and Assurance Requirements Dependencies…………..……………………………..39

List of Figures

Figure 1. TOE Functional Description....................................................................................................11

Figure 2. TOE Architectural Description................................................................................................13



Revision History

Version Date Author(s) Description

0.1 4/19/04 Ohta PP proposal

1.0 7/27/04 Nevo First draft

1.3 8/18/04 Nevo TOE description changes

1.4 8/20/04 group Typographical corrections

1.5 9/8/04 Nevo, Cybuck Sections 1-4

1.51, 1.52 10/4-8/04 group Corrections from Montreal meeting and cleanup of sections 1-4

1.60 10/25/04 Nevo, Cybuck Corrections from Lexington meeting to sections 1-4, update all sections

1.70 11/2/04 Ohta, Smithson Many changes, see associated 1.70 Change Notes document

1.71 11/7/04 Nevo, Cybuck Combines 1.60 and 1.70 to have one document according to IEEE format

1.72 11/10/04 Ohta, Smithson Chapter 4

1.73 11/23/04 Smithson Corrections and updates from San Antonio meeting to chapters 1-4



2 Introduction

2.1 Identification

Title: Protection Profile for Hardcopy Systems and Devices for High Security Environments

Version: 1.72

Date: November 26, 2004

Authors: IEEE P2600 Working Group

CC Version: 2.2

Keywords: Hardcopy, Paper, Document, Copier, Printer, Scanner, Facsimile, FAX, Multifunction Device, MFP, Network, Office

Status: Draft

2.2 Protection Profile Overview

The Target of Evaluation (TOE) of this Protection Profile is Hardcopy Systems and Devices (HSDHCDs). HSDHCDs perform one or more of the following functions and are primarily used in office environments:

Copying paper documents Printing digital documents to paper form Scanning paper documents to digital form Transmitting paper or digital documents to a facsimile device Receiving documents from a facsimile device and delivering them in paper or digital form

Many of the information objects that are processed or used by HSDHCDs may contain valuable or sensitive information that needs to be protected from unauthorized disclosure, alteration, and destruction. This includes the documents in paper and digital forms, job information stored in usage logs, user information stored in address books, and residual data stored in hard disks, other memory devices, and electrostatic components. Documents and other information may be transmitted over telephone lines and computer networks, and so protection of network services should be considered. The utility of the device itself may be considered a valuable asset which also needs to be protected, in terms of both availability for authorized use and prevention of unauthorized use. Lastly, there may be a need to ensure that the HSDHCD cannot be misused in such a way that it causes harm to external devices to which the HSDHCD is connected.

All of the aforementioned items are considered to be assets requiring some level of protection, depending upon the security requirements of the environment in which the TOE is being used. Several Protection Profiles are available for HSDHCDs in different environments:

High Security Environment Enterprise Environment Small Office / Home Office (SOHO) Environment Custom Environment

This Protection Profile addresses the security threats, objectives, and requirements that apply to the High Security Environment, which is described in 4. TOE Security Environment, below.



3 TOE Description

3.1 TOE TerminologyTable 1. Asset Terminology

Term Definition

User Document Includes all representations of documents processed by the TOE, including: original paper to be copied, electronic files to be printed, image data sent by scanning or with facsimile, printed paper output, and deliberate or residual stored data in hard disks or other memory devices.

User Function Data Data about users that the TOE applications use, excluding passwords, but including user identifiers for access control, destination lists for scanning and address books for facsimile delivery.

Management Data Data that controls the configuration of and access to the device, including: user and administrator passwords; device management data such as audit data, log data, and paper configuration; and network management data such as IP addresses. Management Data is not a direct asset in itself, but its their disclosure, alteration, or destruction is a threats to direct assets.

Resource Physical components that comprise the TOE (e.g., electronic, electrical, and mechanical items); resident digital components (e.g., fonts); and consumable supplies for the TOE (e.g., paper, toner).

Table 2. Actor Terminology

Term Definition

Internal User A person who access the TOE physically or using any interface that is not publicly accessible (including virtual private network connections). Internal User includes the Device Administrator, Network Administrator, Normal User, and Customer Engineers. For detail of those roles, see below.

External User A person who accesses the TOE from outside of the office using the Telephone Line or any other interface that is publicly accessible.

Normal User A person who accesses to the TOE for normal use (e.g. copy, print, fax and scan) using the Operator Panel or Network or Local Interfaces.

Device Administrator A person who controls administrative operations of the TOE other than its network configuration (e.g., management of users, resources of the TOE, and audit data).

Network Administrator A person who manages the network configuration of the TOE. This Protection Profile distinguishes the Network Administrator from the Device Administrator because it may be a different person and/or the roles are granted different privileges on the TOE.



Term Definition

Customer Engineer A person who works for the TOE vendor andauthorized to maintains it the TOE at a customer site.

Authorized User A person who is permitted to access and use the TOE for a defined purpose. This can include persons who are permitted to perform some operations but may be able to attempt or perform operations that are beyond those permissions.

Unauthorized User A person who is not permitted to access or use the TOE for any purpose. This can include persons who are permitted to be physically proximate to the TOE or who are permitted to access a network to which the TOE is connected.

Table 3. Access Terminology

Term Definition

Operator Panel A physical control panel used to operate the TOE. It typically consists of a keypad, keyboard, or other controls, and a display device.

Network Interface An interface used to connect the TOE to a network. Examples include IEEE 802.3, 802.5, and 802.11 interfaces.

Maintenance Port An electrical interface used for machine maintenance, service troubleshooting, and/or firmware updates.

Local Interface An electrical, optical, or electromagnetic interface intended for use with close physical proximity (typically no more than 10 meters) to the TOE. Examples include USB, FireWire, IrDA, parallel port, serial port, memory card, diskette, and BlueTooth.

Telephone Line An electrical interface used to connect the TOE to the public switch telephone network for transmitting and receiving facsimiles.

Foreign External Device Interface

An electrical interface for connecting an external device to control access to local operation of the TOE. Depending on the device and its purpose, access may be granted as a result of identifying the user or as a result of a payment. Example devices include identity card readers or biometric devices for authentication, and coin boxes or credit card readers for payment. Note that some authentication may take place using the Operator Panel (e.g., entering a PIN number or password).

Table 4. Miscellaneous Terminology

Term Definition

Temporary Data The image data that is temporarily buffered in memory before the TOE performs Application operations.



Term Definition

Stored Data Fonts, Forms and Document data.

Application Major functions that the TOE performs, e.g., copying, printing, scanning, and facsimile.

3.2 TOE Functional Description

The Target of Evaluation (TOE) of this Protection Profile is Hardcopy Systems and Devices (HSDHCDs). There are several kinds of devices and systems that comprise this category of product: copiers, printers, scanners, facsimile machines, and multifunction devices. All of these devices draw from a common set of functional characteristics, shown in Figure 1. TOE Functional Description, below.

Figure 1. TOE Functional Description

3.2.1 Actors

Several categories of users can be identified for HSDHCDs, defined by their role with regard to the device and therefore the level of access or privilege they require to fulfill that role. These categories are described in Table 2. Actor Terminology, above.

3.2.2 Accesses

Access to the HSDHCD can take several forms, depending on the function and design of the particular device. All will have some kind of Operator Panel and at least one Network Interface, Local Interface, or Telephone Interface. Some HSDHCDs may also have a ForeignExternal Device Interface for attaching external authentication and authorization devices. These Access mechanisms are described in Table 3.Access Terminology, above.



3.2.3 Assets

3.2.3.1 User Data

Data associated with users can take one or more forms. Minimally, the HSDHCD will process User Document Data in paper form, digital form, or both. Depending on the function and design of a particular device, there may also be User Function Data that is used to distinguish users, store destination addresses, log transactions, and such. Both types of User Data are described in Table 1. Asset Terminology, above.

3.2.3.2 Management Data

Management Data is information that is used to manage the device itself. It may be stored in flash memory, on a hard disk drive, or in legacy products, using switches or jumpers. Management Data is described in Table 1. Asset Terminology, above. Management Data is not a direct asset, but instead is TOE Security Function (TSF) data that could be used indirectly to threaten direct assets.

3.2.3.3 Resources

HSDHCD resources include the physical device itself, stored data such as fonts, and consumable items such as paper, ink, or toner. Resources are described in Table 1. Asset Terminology, above.



3.3 TOE Architectural Description

HSDHCD architectures vary, depending on their intended function and particular design. A generic architecture of a multifunction HSDHCD is shown in Figure 2. TOE Architectural Description, below, because it represents all of the major functions (copying, scanning, printing, and faxing) in a single unit. This generic architecture is intended only as an example; particular manufacturers and models may have different architectures. The major architectural components are described below.

Figure 2. TOE Architectural Description

3.3.1 Original Document Handler

The Original Document Handler is the part of the TOE's paper handling function that manipulates the input document into position for scanning. The input document type is not restricted to paper, and may include transparencies, slides, or film. Examples of an Original Document Handler components include: flatbed glass window, single sheet feeder, or a multiple sheet input with duplexer.



3.3.2 Hardcopy Output Handler

The Hardcopy Output Handler is the part of the TOE's paper handling function that holds or manipulates the media after it has exited the Media Marking Path (print engine). The Hardcopy Output Handler may also include certain post-printing processes (finishing options) such as stapling, hole punching, or folding. Examples include: the exit tray of a printer, mailbox attachments to an MFDmultifunction product, and a stapler/collator attachment for a copier.

3.3.3 Data Interface

The Data Interface of a hardcopy device includes any interface that transports print/scan data into or out of the HSDHCD’s system processor and memory. Some data interface designs may include independent processor and memory subsystems that should be included in any Security Target documents that are based on this Protection Profile. Note that some HSDHCD architectures may include data interfaces between specific functions of the device (e.g., scanner to print engine interface in an MFDHCD, or a printing system where the System Processor and Memory is an external computer); these should be included in the evaluation.

Data Interfaces can take several forms, including Local Interfaces, Network Interfaces, and Telephone Lines, defined in Table 3. Access Terminology, above.

3.3.4 Media Marking Path

The Media Marking Path of the TOE includes all paths in the printing function that the input media takes between the Input Media Interface and the Hardcopy Output Handler. This path may include certain intermediate media handling devices (e.g., duplexer) as well as the path through the marking mechanism.

3.3.5 Operator Interface

The Operator Interface of the TOE is any physical human interface (e.g., touch screen LCD control panel) that allows access to display and/or modify the state of the hardcopy device. This interface can be as simple as a few lights and buttons on an inkjet printer to a full screen display with keyboard. This interface does not include “remote” or reflected user interfaces that may be implemented as part of a management application that accesses the device via one of the data interfaces. The Operator Interface is further defined under Operator Panel in Table 3. Access Terminology, above.

3.3.6 ForeignExternal Device Interface

HSDHCDs may include an electrical interface for external devices that are used for identification or payment. ForeignExternal Device Interfaces are defined in Table 3. Access Terminology, above.

3.3.7 Maintenance Ports

Maintenance ports are interfaces for machine maintenance, troubleshooting, and firmware updates. Maintenance Ports are defined in Table 3. Access Terminology, above.

3.3.8 Marker/Consumables Interface

The Marker/Consumables Interface includes any method for human access to the user replaceable components (i.e., ink/toner cartridge, developer roll, waste toner bottle etc.) in a hardcopy device. An example of this interface would be the doors and latches that must be opened to replace a toner cartridge in a general-purpose laser printer.



3.3.9 Input Media Interface

The Input Media Interface includes any method for human access to the mechanisms that store and feed media (paper) to be marked on by a hardcopy device. Examples of this interface would be the sliding drawers that hold paper for an office MFDHCD or the roll paper mechanism for a production printer.

3.3.10 System Processor and Memory/Storage

The System Processor includes any microprocessor, digital signal processor, or microcontroller that has modifiable microcode or processes any type of user data or management information for the hardcopy device. All system processors should be included in Security Target documents that are based on this Protection Profile. The System Memory/Storage includes any volatile or non-volatile storage in the HSDHCD. Examples include EEPROM, DRAM, SRAM, flash memory, and hard disk drive. Note that while Figure 2. TOE Architectural Description shows the System Microprocessor/Memory system as a single entity in the HSDHCD, many of the other interfaces or components within the HSDHCD may also have their own microprocessor/memory subsystems that should be included in Security Target documents that are based on this Protection Profile.



4 TOE Security Environment

This chapter identifies assumptions (A) and threats (T) related to the TOE.

Assumptions are given to detail the expected environment and operating conditions of the system. Threats are those that are addressed by the TOE and operating environment.

The primary assets that the TOE shall protect are User Documents, User Function Data and Resources. Management Data is considered as a secondary asset because it performs a TOE Security Function (TSF), and it is necessary to protect TSF data in order to protect the primary assets.

4.1 Secure Usage Assumptions

In this section, assumptions are made about the environment in which the TOE will be deployed. The Security Objectives and Security Functional Requirements defined in subsequent sections are based on the condition that all of these assumptions are satisfied. In other words, if one or more of these assumptions are not valid in a particular environment, then there is the possibility that the TOE assets will not be protected from threats by the security functions that have been defined in this Protection Profile.

4.1.1 A.ADMIN (Administrator trust and competence)

It is assumed that the Device Administrator, Network Administrator, and Customer Engineer, (1) can be trusted to not abuse their privileged access to TOE assets, (2) follow the security guidance provided in the TOE documentation, and (3) are competent to do so. For example:

Administrators and Customer Engineers will not use their privileged access to User Documents, User Functional Data, Management Data, or Resources, for malicious purposes.

Administrators will configure the TOE in accordance with guidance and procedures that are appropriate for their environment, and not rely on manufacturer’s default configuration settings.

Administrators understand the security requirements of their environment, the value of the TOE assets in their charge, and can make informed and appropriate decisions about installing and configuring the TOE.

Customer Engineers will recognize and, upon completion of their work, restore maintain all TOE configuration settings that have been established by Administrators.

It is noted that some customers may not be willing or, by policy, able to place such trust in a Customer Engineer. For those customers, it is assumed that by organizational security policy, the actions of a Customer Engineer will be monitored and/or audited sufficiently to establish that those actions can be trusted.

4.1.2 A. USER (User responsibility)

It is assumed the Normal User of the TOE follows the instructions in the guidance documentation in order to protect his/her own User Documents. For example:

Users do not use weak passwords, as defined by convention or organizational policy. Users do not disclose or share passwords. Users monitor and protect their documents in as they are processed by the TOE in paper form,

e.g. promptly retrieve them from the Original Document Handler and the Hardcopy Output Handler.

4.1.3 A.ACCESS (Limited access)

It is assumed that (1) only authorized persons have physical access to the TOE; (2) if the TOE is connected to a network, it is protected from the public Internet by a firewall; and (3) if the TOE uses a



wireless connection, that connection employs security measures that are equivalent to a firewall to prevent unauthorized access.

4.2 Threats to Security

This section describes threats to the TOE assets described in Section 3.2.3 that may be present in the environment described in Section 4.1.

4.2.1 T.UD (Unauthorized access to User Documents)

An Authorized User or Unauthorized User might access the User Documents of a different user. Any of the following scenarios may apply:

Table 5. T.UD Threats

Threat Description

T.UD.NORMAL Accessing another’s User Document using interfaces in their normal manner, such as the Operator Panel or Network Interface.

T.UD.HACK Accessing another’s User Document using interface in an unusual manner, such as the Telephone Line or Maintenance Port.

T.UD.SNIFF Accessing another’s User Document by passively monitoring the TOE, its interfaces, or a network to which the TOE is connected. For example, someone could monitor the Network Interface, Telephone Line, electromagnetic emissions.

T.UD.IMP Accessing and/or, modifying, redirecting, and/or deleting another’s User Document by actively impersonating a TOE interface or related service, such as the Network Interface, Telephone Line, or a related Domain Name Server.

T.UD.PHY Retrieving or photographing another’s User Document in paper form from the Original Document Handler, Output Document Handler, or within the scanning or media marking path.

T.UD.SALVAGE Accessing another’s User Document by removing a nonvolatile storage component such as a hard disk drive or flash memory, and salvaging the User Documents from residual or intentionally stored data.

T.UD.ANALYZE

Accessing another’s User Document by removing and analyzing residual image data from a media marking component, such as a drum or belt.

4.2.2 T.RESOURCE (Unauthorized use of Resources)

An Unauthorized User might use Resources of the TOE, including Application functions, physical components, and consumable items.

4.2.3 T.DOS (Denial or impediment of services of the TOE)

An Authorized User or Unauthorized User might use one of the following techniques to deny or impede service to Authorized Users:

Table 6. T.DOS Threats

Threat(s) Description



T.DOS.NET Denying service of the Network InterfaceNetwork attack, e.g. by sending a large amount quantity of packets or irregular packets to the TOE.

T.DOS.PRT Denying service of the printing systemPrinting attack, e.g. by sending a print file that generates a very large amount quantity of printed output or causes the printing system processor to enter a continuous program loop.

T.DOS.FAX Denying service of the Telephone InterfaceTelephone Line attack, e.g. by continuously sending grayscale fax pages at low speed, sending excessive document volume, forcing repetitive modem negotiation, or forcing the phone line off hook.

T.DOS.PHY Physical attackly disabling all or part the TOE, e.g. by mechanically or electrically damaging the device or its components.

T.DOS.IMP Denying service of a TOE Application by impersonating a TOE interface or related service, such as the Network Interface, Telephone Line, or a related Domain Name Server or destination host, to delete or redirect the input or output of the Application.

4.2.4 T.EA (Attacks on external systems in the IT environment)

An Authorized User or Unauthorized User might attack other devices in the IT environment by using the Applications or network services of TOE.

Table 7. T.EA Threats

Threat Description

T.EA.SERVICES

Using network services of the TOE to cause harm to external systems. Examples include using an open SMTP relay to send excessive messages, or an FTP server to perform network reconnaissance.

T.EA.APPS Using TOE applications to cause harm to external systems. For example, sending crafted print jobs that generate excessive user or system notifications, or using scan or FAX applications to generate excessive document volume for target systems.



4.2.5 T.TSF (Accessing or altering TOE Security Functions)

An Authorized User or Unauthorized User might obtain access TOE Security Function data, alter User Function Data, and/or change alter the TOE configuration, and thereby expose exposing TOE assets to misuse through a subsequent attack.

Table 8. T.TSF Threats

Threat Description

T.TSF.CRED Gaining the ability to impersonate an Authorized User by obtaining that user’s credentials. Gaining the ability to access another’s User Document by altering User Function Data, e.g. address books for scan or FAX destinations.

T.TSF.AUD Gaining knowledge about Authorized Users and their TOE transactions. Gaining the ability to perform unaccounted, undetected, and/or unauthorized TOE functions.

T.TSF.CONF Gaining the ability to perform subsequent TOE attacks by altering TOE device or security configuration settings.

T.TSF.SW Gaining the ability to perform subsequent TOE attacks by installing an unauthorized application or base operating software on the TOE.

4.3 Organizational Security Policies

This Protection Profile does not prescribe any organizational security policies except as noted in 4.1.1 A.ADMIN (Administrator trust and competence).



5 Security Objectives

This chapter describes the security objectives that are concise statements of the intended response to the assumptions and threats identified in chapter 3.

5.1 Security Objectives for the TOE

In this chapter, the TOE security objectives that are needed to counter the threats in section 3.3 are defined.

5.1.1 O.I&A (User identification and authentication)

The TOE must identify and authenticate each Internal User and External User who tries to access TOE Assets or execute TOE Applications, as they are defined in Table 1. Asset Terminology and Table 4.Miscellaneous Terminology, respectively.

5.1.2 O.ACCESS (User authorization)

The TOE must ensure that Authorized Users are permitted only to access those TOE assets or execute those TOE applications that are appropriate to the role for which they are authorized. Authorized User roles are described in Table 2. Actor Terminology, above.

The TOE must also ensure that Unauthorized Users are not permitted to access TOE assets or execute TOE applications.

5.1.3 O.DELETE (Deletion of residual data)

The TOE must delete Temporary Data that has been used by TOE Applications so that it cannot be retrieved from nonvolatile storage after it is no longer needed by the Application.

5.1.4 O.PROTECT (Protection of documents and data)

The TOE must protect the User Documents, User Function Data, and Management Data from unauthorized disclosure that could result from retrieving them from nonvolatile storage devices.

5.1.5 O.NETWORK (Protecting transmitted data and resources)

The TOE must protect the User Documents, User Function Data, and the Management Data from unauthorized disclosure that could result from accessing their transmission to or from the TOE over the Network Interface or Telephone Line.

5.1.6 O.MONITOR (Monitoring)

The TOE must monitor and record security-related events, and must have capability to show this data to appropriately Authorized Users.

5.1.7 O.DOS RESILIENT (Mitigation of DOS attack)

The TOE must not allow a denial of service (DOS) attack against one Interface to affect effect a denial of service on other Interfaces, must continue to protect Assets, and upon termination of the attack, must recover without requiring human intervention.



5.1.8 O.GENUINE (Assurance of genuine TOE)

The TOE must provide an external device or software with the evidencea mechanism which confirms that the TOE is genuine (as provided by vendor).



5.2 Security Objectives for the Environment

In this chapter, the security objectives that the operating environment of the TOE must achieve are defined.

5.2.1 Security objectives for the IT environment

5.2.1.1 OIE.GENUINE (Detection of the fake TOE)

The IT environment of the TOE must have capability of confirming if the TOE is genuine, using the evidence provided by the TOE. See also O.GENUINE (Assurance of genuine TOE), above.

5.2.2 Security objectives for the non-IT environment

5.2.2.1 OE.TRAIN (Training)

Device Administrators, Network Administrators, and Normal Users must be trained to configure and operate the TOE in accordance with vendor guidance and documentation in order to make effective use of the TOE Security Functions.

5.2.2.2 OE.LOCATION (Limited physical access)

The TOE must be placed in a location that limits physical access in order to protect the physical and logical assets of the TOE.

5.2.2.3 OE.NETWORK (Limited network access)

The TOE should be installed on an internal network that is protected from attack by Unauthorized Users, e.g. by installing the TOE behind a firewall. Additionally, related devices on the network, such as mail server, DNS server, and desktop computers, must be correctly configured and appropriately protected to ensure the effectiveness of TOE Security Functions.



O.I&

A

O.A

CC

ESS

O.D

ELET

E

O.S

TOR

EDPR

OT

ECTE

D

O.N

ETW

OR

K

O.M

ON

ITO

R

O.D

OSR

ESIL

IEN

T O.G

ENU

INE

OE.

TRA

IN

OE.

LOC

ATI

ON

OE.

NET

WO

RK

T.UD.NORMAL X X X

T.UD.HACK X X X

T.UD.SNIFF X

T.UD.IMP X X X X

T.UD.PHY

T.UD.SALVAGE X X

T.RESOURCE X X X

T.DOS.NET/PRT X

T.DOS.FAX X

T.DOS.PHY

T.EA.SERVICES X X X

T.EA.APPS X X X

T.TSF.CRED X X X X

T.TSF.AUD X X X

T.TSF.CONF X X

T.TSF.SW X

A.ADMIN X

A.USER X

A.ACCESS X X

Note: The above table should be placed in chapter 6.1 by right. But I prepared it here for temporary discussion. This table will move to chapter 6.1 in the final PP.



6 Security Functional Requirements

These are the basic security functions expected of the TOE to meet an EAL2 rating

(Note: Details in this section are open to discussion and revision.)

6.1 TOE Security Functional Requirements

In this section, the security functional requirements that the TOE must satisfy in order to achieve the security objectives defined in section 4.1. In description of the requirements, the words against which the assignment or selection operation are performed are identified with [bold letters and brackets], the refinement operations are identified with bold letters and underline, and the iteration operations are identified with lower-case alphabetical suffix, e.g. “-a”. The unfinished operations identified as [operation: italic letters] shall be completed in the Security Target (ST).

FAU

_GEN

.1FA

U_S

AR

.1FA

U_S

AR

.2FA

U_S

TG.1

FAU

_STG

.4FC

S_C

OP.

1FD

P_A

CC

.2FD

P_A

CF.

1FD

P_R

IP.1

FIA

_AFL

.1FI

A_U

AU

.2FI

A_U

AU

.7FI

A_U

ID.2

FMT_

MSA

.1FM

T_M

SA.3

FMT_

MTD

.1FM

T_M

TD.2

FMT_

SMF.

1FM

T_SM

R.1

FPT_

RC

V.2

FPT_

STM

.1FP

T_TS

T.1

FTP_

ITC

.1

O.I&A X X X X X

O.ACCESS X X X X X X X X

O.DELETE X X

O.PROTECTED X

O.NETWORK X

O.MONITOR X X X X X X

O.RESILIENT X

O.GENUINE X

Note: The above table should be placed in chapter 6.2 by right. But I prepared it here for temporary discussion. This table will move to chapter 6.2 in the final PP.



6.1.1 Security audit (FAU)

6.1.1.1 FAU_ARP.1 Security alarms

FAU_ARP.1.1 The TSF shall take [assignment: list of the least disruptive actions] upon detection of a potential security violation.

Dependencies: FAU_SAA.1 Potential violation analysis

6.1.1.2 FAU_GEN.1 Audit data generation

FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:

a) Start-up and shutdown of the audit functions;

b) Modifications to HCD system or application softwareAll auditable events for the [selection: minimum, basic, detailed, not specified] level of audit; and

c) [assignment: other specifically defined auditable events].

FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:

a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and

b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment: other audit relevant information]

Dependencies: FPT_STM.1 Reliable time stamps

6.1.1.3 FAU_SAR.1 Audit review

FAU_SAR.1.1 The TSF shall provide [assignment: authorized users] with the capability to read [assignment: list of audit information] from the audit records.

FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information.

Dependencies: FAU_GEN.1 Audit data generation

6.1.1.4 FAU_SAR.2 Restricted audit review

FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access.

6.1.1.5 FAU_STG.1 Protected audit trail storage

FAU_STG.1.1 The TSF shall protect the stored audit records from unauthorised deletion.

FAU_STG.1.2 The TSF shall be able to [selection: choose one of: prevent, detect] unauthorised modifications to the audit records in the audit trail.




6.1.1.6 FAU_STG.2 Guarantees of audit data availability

FAU_STG.2.1 The TSF shall protect the stored audit records from unauthorised deletion.

FAU_STG.2.2 The TSF shall be able to [selection: choose one of: prevent, detect] unauthorised modifications to the audit records in the audit trail.

FAU_STG.2.3 The TSF shall ensure that [assignment: metric for saving audit records] audit records will be maintained when the following conditions occur: [selection: audit storage exhaustion, failure, attack].


6.1.1.7 FAU_STG.3 Action in case of possible audit data loss

FAU_STG.3.1 The TSF shall take [assignment: actions to be taken in case of possible audit storage failure] if the audit trail exceeds [assignment: pre-defined limit].

Dependencies: FAU_STG.1 Protected audit trail storage

6.1.1.8 FAU_STG.4 Prevention of audit data loss

FAU_STG.4.1 The TSF shall [selection: choose one of: ‘ignore auditable events’, ‘prevent auditable events, except those taken by the authorised user with special rights’, ‘overwrite the oldest stored audit records’] and [assignment: other actions to be taken in case of audit storage failure] if the audit trail is full.

Dependencies: FAU_STG.1 Protected audit trail storage



6.1.2 Cryptographic support (FCS)

6.1.2.1 FCS_COP.1 Cryptographic operation

FCS_COP.1.1 The TSF shall perform [assignment: list of cryptographic operations] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].

Dependencies: [FDP_ITC.1 Import of user data without security attributesorFCS_CKM.1 Cryptographic key generation]FCS_CKM.4 Cryptographic key destructionFMT_MSA.2 Secure security attributes

Note: Though FCS_COP.1 is required, FDP_ITC.1, FCS_CKM.1, CKM.4, and FMT_MSA.2 are not included in this PP at this time, i.e. dependencies are not satisfied. See the “Change Note” (another MS Word file) for detail.

6.1.3 Communication (FCO)

6.1.3.1 FCO_NRO.2 Enforced proof of origin

FCO_NRO.2.1 The TSF shall enforce the generation of evidence of origin for transmitted [assignment: list of information types] at all times.

FCO_NRO.2.2 The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the information to which the evidence applies.

FCO_NRO.2.3 The TSF shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of origin].

Dependencies: FIA_UID.1 Timing of identification



6.1.4 User data protection (FDP)

6.1.4.1 FDP_ACC.1 Subset access control

FDP_ACC.1.1 The TSF shall enforce the [assignment: access control SFP] on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].

Dependencies: FDP_ACF.1 Security attribute based access control

6.1.4.2 FDP_ACC.2 Complete access control

FDP_ACC.2.1 The TSF shall enforce the [assignment: access control SFP] on [assignment: list of subjects and objects] and all operations among subjects and objects covered by the SFP.

FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC are covered by an access control SFP.

Dependencies: FDP_ACF.1 Security attribute based access control

6.1.4.3 FDP_ACF.1 Security attribute based access control

FDP_ACF.1.1 The 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.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects].

FDP_ACF.1.3 The 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.4 The 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].

Dependencies: FDP_ACC.1 Subset access controlFMT_MSA.3 Static attribute initialisation

6.1.4.4 FDP_DAU.1 Basic data authentication

FDP_DAU.1.1 The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of [assignment: list of objects or information types].

FDP_DAU.1.2 The TSF shall provide [assignment: list of subjects] with the ability to verify evidence of the validity of the indicated information.

Dependencies: No dependencies



6.1.4.5 FDP_ETC.1 Export of user data without security attributes

FDP_ETC.1.1 The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] when exporting user data, controlled under the SFP(s), outside of the TSC.

FDP_ETC.1.2 The TSF shall export the user data without the user data’s associated security attributes.

Dependencies: [FDP_ACC.1 Subset access control, orFDP_IFC.1 Subset information flow control]

6.1.4.6 FDP_RIP.1 Subset residual information protection

FDP_RIP.1.1 The 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].


6.1.4.7 FDP_RIP.2 Full residual information protection

FDP_RIP.2.1 The 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] all objects.




6.1.5 Identification and authentication (FIA)

6.1.5.1 FIA_AFL.1 Authentication failure handling

FIA_AFL.1.1 The 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.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall [assignment: list of actions].

Dependencies: FIA_UAU.1 Timing of authentication

6.1.5.2 FIA_ATD.1 User attributes definition

FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: list of security attributes].


6.1.5.3 FIA_UAU.1 Timing of authentication

FIA_UAU.1.1 The 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.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.


6.1.5.4 FIA_UAU.2 User authentication before any action

FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.


6.1.5.5 FIA_UAU.7 Protected authentication feedback

FIA_UAU.7.1 The TSF shall provide only [assignment: list of feedback] to the user while the authentication is in progress.

Dependencies: FIA_UAU.1 Timing of authentication

6.1.5.6 FIA_UID.1 Timing of identification

FIA_UID.1.1 The 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.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.


6.1.5.7 FIA_UID.2 User identification before any action

FIA_UID.2.1 The TSF shall require each user to identify itself before allowing any other TSF-mediated actions on behalf of that user.




6.1.6 Security management (FMT)

6.1.6.1 FMT_MSA.1 Management of security attributes

FMT_MSA.1.1 The 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 authorized identified roles].

Dependencies: [FDP_ACC.1 Subset access control orFDP_IFC.1 Subset information flow control]FMT_SMF.1 Specification of management functionsFMT_SMR.1 Security roles

6.1.6.2 FMT_MSA.2 Secure security attributes

FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security attributes.

Dependencies: ADV_SPM.1 Informal TOE security policy model[FDP_ACC.1 Subset access control orFDP_IFC.1 Subset information flow control]FMT_MSA.1 Management of security attributesFMT_SMR.1 Security roles

6.1.6.3 FMT_MSA.3 Static attribute initialisation

FMT_MSA.3.1 The 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.2 The 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.

Dependencies: FMT_MSA.1 Management of security attributesFMT_SMR.1 Security roles

6.1.6.4 FMT_MTD.1 Management of TSF data

FMT_MTD.1.1 The 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 authorized identified roles].

Dependencies: FMT_SMF.1 Specification of management functionsFMT_SMR.1 Security roles

6.1.6.5 FMT_MTD.2 Management of limits on TSF data

FMT_MTD.2.1 The TSF shall restrict the specification of the limits for [assignment: list of TSF data] to [assignment: the authorised identified roles].



FMT_MTD.2.2 The TSF shall take the following actions, if the TSF data are at, or exceed, the indicated limits: [assignment: actions to be taken].

Dependencies: FMT_MTD.1 Management of TSF dataFMT_SMR.1 Security roles

6.1.6.6 FMT_MTD.3 Secure TSF data

FMT_MTD.3.1 The TSF shall ensure that only secure values are accepted for TSF data.

Dependencies: ADV_SPM.1 Informal TOE security policy modelFMT_MTD.1 Management of TSF data

6.1.6.7 FMT_SAE.1 Time-limited authorization

FMT_SAE.1.1 The TSF shall restrict the capability to specify an expiration time for [assignment: list of security attributes for which expiration is to be supported] to [assignment: the authorised identified roles].

FMT_SAE.1.2 For each of these security attributes, the TSF shall be able to [assignment: list of actions to be taken for each security attribute] after the expiration time for the indicated security attribute has passed.

Dependencies: FMT_SMR.1 Security rolesFPT_STM.1 Reliable time stamps

6.1.6.8 FMT_SMF.1 Specification of Management Functions

FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: [assignment: list of security management functions to be provided by the TSF].

Dependencies: No Dependencies

6.1.6.9 FMT_SMR.1 Security roles

FMT_SMR.1.1 The TSF shall maintain the roles [assignment: the authorised identified roles].

FMT_SMR.1.2 The TSF shall be able to associate users with roles.


6.1.6.10 FMT_SMR.2 Restrictions on security roles

FMT_SMR.2.1 The TSF shall maintain the roles: [assignment: the authorised identified roles].

FMT_SMR.2.2 The TSF shall be able to associate users with roles.

FMT_SMR.2.3 The TSF shall ensure that the conditions [assignment: conditions for the different roles] are satisfied.




6.1.7 Protection of the TOE Security Functions (FPT)

6.1.7.1 FPT_RCV.2 Automated recovery

FPT_RCV.2.1 When automated recovery from [assignment: list of failures/service discontinuities] is not possible, the TSF shall enter a maintenance mode where the ability to return to a secure state is provided.

FPT_RCV.2.2 For [assignment: list of failures/service discontinuities], the TSF shall ensure the return of the TOE to a secure state using automated procedures.

Dependencies: AGD_ADM.1 Administrator guidanceADV_SPM.1 Informal TOE security policy model

6.1.7.2 FPT_STM.1 Reliable time stamps

FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use.


6.1.7.3 FPT_TST.1 TSF testing

FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of the TSF], the TSF].

FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of [selection: [assignment: parts of the TSF data], TSF data].

FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code.

Dependencies: FPT_AMT.1 Abstract machine testing

6.1.7.4 FPT_AMT.1 Abstract machine testing

FPT_AMT.1.1 The TSF shall run a suite of tests [selection: during initial start-up, periodically during normal operation, at the request of an authorised user, [assignment: other conditions]] to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF.


6.1.7.5 FPT_ITC.1 Inter-TSF confidentiality during transmission

FPT_ITC.1.1 The TSF shall protect all TSF data transmitted from the TSF to a remote trusted IT product from unauthorised disclosure during transmission.




6.1.8 Trusted path/channels (FTP)

6.1.8.1 FTP_ITC.1 Inter-TSF trusted channel

FTP_ITC.1.1 The TSF shall provide a communication channel between itself and a remote trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure.

FTP_ITC.1.2 The TSF shall permit [selection: the TSF, the remote trusted IT product] to initiate communication via the trusted channel.

FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment: list of functions for which a trusted channel is required].


6.1.8.2 FTP_TRP.1 Trusted path

FTP_TRP.1.1 The TSF shall provide a communication path between itself and [selection: remote, local] users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from modification or disclosure.

FTP_TRP.1.2 The TSF shall permit [selection: the TSF, local users, remote users] to initiate communication via the trusted path.

FTP_TRP.1.3 The TSF shall require the use of the trusted path for [selection: initial user authentication, [assignment: other services for which trusted path is required]].




TOE Security Assurance Requirements

The assurance components for the TOE are shown in Error: Reference source not found. It is the set of components defined by the evaluation assurance level EAL2 and no other requirements have been augmented.

Table 9, Assurance Requirements: EAL (2)

Assurance Class Assurance Components

ACM – Configuration Management ACM_CAP.23 ACM_SCP.1

ADO – Delivery and operation ADO_DEL.1 ADO_IGS.1

ADV – Development ADV_FSP.1 ADV_HLD.1 ADV_RCR.1

AGD –Guidance documents AGD_ADM.1 AGD_USR.1

ALC –Life cycle report ALC_DVS.1

ATE –Tests ATE_COV.12 ATE_DPT.1 ATE_FUN.1 ATE_IND.2

AVA –Vulnerability assessment AVA_MSU.1 AVA_SOF.1 AVA_VLA.1

ASE –Security Target

ASE_DES.1 ASE_ENV.1 ASE_INT.1

ASE_OBJ.1 ASE_PPC.1 ASE_REQ.1

ASE_SRE.1 ASE_TSS.1



6.1.9 Configuration management (ACM)

6.1.9.1 ACM_CAP.2 Configuration items

Developer action elements

ACM_CAP.2.1D The developer shall provide a reference for the TOE.

ACM_CAP.2.2D The developer shall use a CM system.

ACM_CAP.2.3D The developer shall provide CM documentation.

Content and presentation of evidence elements

ACM_CAP.2.1C The reference for the TOE shall be unique to each version of the TOE.

ACM_CAP.2.2C The TOE shall be labelled with its reference.

ACM_CAP.2.3C The CM documentation shall include a configuration list.

ACM_CAP.2.4C The configuration list shall uniquely identify all configuration items that comprise the TOE.

ACM_CAP.2.5C The configuration list shall describe the configuration items that comprise the TOE.

ACM_CAP.2.6C The CM documentation shall describe the method used to uniquely identify the configuration items.

ACM_CAP.2.7C The CM system shall uniquely identify all configuration items.

Evaluator action elements

ACM_CAP.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.


6.1.9.2 - Authorization controls (ACM_CAP.3) The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation.ACM_SCP.1.1C

The developer shall provide CM documentation.ACM_SCP.1.1D The CM documentation shall describe how configuration items are tracked by the CM system.ACM_SCP.1.2C

6.1.9.3 - TOE CM coverage (ACM_SCP.1)The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation.ACM_SCP.1.1C

The developer shall provide CM documentation.ACM_SCP.1.1D The CM documentation shall describe how configuration items are tracked by the CM system.ACM_SCP.1.2C



6.1.10 Delivery and operation (ADO)

6.1.10.1 ADO_DEL.1 Delivery procedures


ADO_DEL.1.1D The developer shall document procedures for delivery of the TOE or parts of it to the user.

ADO_DEL.1.2D The developer shall use the delivery procedures.


ADO_DEL.1.1C The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user's site.


ADO_DEL.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.


6.1.10.2 ADO_IGS.1 Installation, generation, and start-up procedures


ADO_IGS.1.1D The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.


ADO_IGS.1.1C The installation, generation and start-up documentation shall describe all the steps necessary for secure installation, generation and start-up of the TOE.


ADO_IGS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ADO_IGS.1.2E The evaluator shall determine that the installation, generation, and start-up procedures result in a secure configuration.

Dependencies: AGD_ADM.1 Administrator guidance

6.1.10.3 - Delivery procedures (ADO_DEL.1) The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user's site.ADO_DEL.1.1C .

The developer shall document procedures for delivery of the TOE or parts of it to the user.ADO_DEL.1.1D The developer shall use the delivery procedures.ADO_DEL.1.2D

6.1.10.4 - Installation, generation, and start-up procedures (ADO_IGS.1) The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE.ADO_IGS.1.1C The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.ADO_IGS.1.1D



6.1.11 Development (ADV)

6.1.11.1 ADV_FSP.1 Informal functional specification


ADV_FSP.1.1D The developer shall provide a functional specification.


ADV_FSP.1.1C The functional specification shall describe the TSF and its external interfaces using an informal style.

ADV_FSP.1.2C The functional specification shall be internally consistent.

ADV_FSP.1.3C The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing details of effects, exceptions and error messages, as appropriate.

ADV_FSP.1.4C The functional specification shall completely represent the TSF.


ADV_FSP.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ADV_FSP.1.2E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements.

Dependencies: ADV_RCR.1 Informal correspondence demonstration

6.1.11.2 ADV_HLD.1 Descriptive high-level design


ADV_HLD.1.1D The developer shall provide the high-level design of the TSF.


ADV_HLD.1.1C The presentation of the high-level design shall be informal.

ADV_HLD.1.2C The high-level design shall be internally consistent.

ADV_HLD.1.3C The high-level design shall describe the structure of the TSF in terms of subsystems.

ADV_HLD.1.4C The high-level design shall describe the security functionality provided by each subsystem of the TSF.

ADV_HLD.1.5C The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software.

ADV_HLD.1.6C The high-level design shall identify all interfaces to the subsystems of the TSF.

ADV_HLD.1.7C The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible.




ADV_HLD.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ADV_HLD.1.2E The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.

Dependencies: ADV_FSP.1 Informal functional specificationADV_RCR.1 Informal correspondence demonstration

6.1.11.3 ADV_RCR.1 Informal correspondence demonstration


ADV_RCR.1.1D The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided.


ADV_RCR.1.1C For each adjacent pair of provided TSF representations, the analysis shall demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and completely refined in the less abstract TSF representation.


ADV_RCR.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.




6.1.12 Guidance documents (AGD)

6.1.12.1 AGD_ADM.1 Administrator guidance


AGD_ADM.1.1D The developer shall provide administrator guidance addressed to system administrative personnel.


AGD_ADM.1.1C The administrator guidance shall describe the administrative functions and interfaces available to the administrator of the TOE.

AGD_ADM.1.2C The administrator guidance shall describe how to administer the TOE in a secure manner.

AGD_ADM.1.3C The administrator guidance shall contain warnings about functions and privileges that should be controlled in a secure processing environment.

AGD_ADM.1.4C The administrator guidance shall describe all assumptions regarding user behaviour that are relevant to secure operation of the TOE.

AGD_ADM.1.5C The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate.

AGD_ADM.1.6C The administrator guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.

AGD_ADM.1.7C The administrator guidance shall be consistent with all other documentation supplied for evaluation.

AGD_ADM.1.8C The administrator guidance shall describe all security requirements for the IT environment that are relevant to the administrator.


AGD_ADM.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

Dependencies: ADV_FSP.1 Informal functional specification

6.1.12.2 AGD_USR.1 User guidance


AGD_USR.1.1D The developer shall provide user guidance.


AGD_USR.1.1C The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE.

AGD_USR.1.2C The user guidance shall describe the use of user-accessible security functions provided by the TOE.



AGD_USR.1.3C The user guidance shall contain warnings about user-accessible functions and privileges that should be controlled in a secure processing environment.

AGD_USR.1.4C The user guidance shall clearly present all user responsibilities necessary for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the statement of TOE security environment.

AGD_USR.1.5C The user guidance shall be consistent with all other documentation supplied for evaluation.

AGD_USR.1.6C The user guidance shall describe all security requirements for the IT environment that are relevant to the user.


AGD_USR.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

Dependencies: ADV_FSP.1 Informal functional specification

6.1.12.3 - Administrator guidance (AGD_ADM.1)The administrator guidance shall describe the administrative functions and interfaces available to the administrator of the TOE.AGD_ADM.1.1C

The developer shall provide administrator guidance addressed to system administrative personnel.AGD_ADM.1.1D

The administrator guidance shall describe how to administer the TOE in a secure manner.AGD_ADM.1.2C

The administrator guidance shall contain warnings about functions and privileges that should be controlled in a secure processing environment.AGD_ADM.1.3C

The administrator guidance shall describe all assumptions regarding user behavior that are relevant to secure operation of the TOE.AGD_ADM.1.4C

The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate.AGD_ADM.1.5C

The administrator guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.AGD_ADM.1.6C

The administrator guidance shall be consistent with all other documentation supplied for evaluation.AGD_ADM.1.7C

The administrator guidance shall describe all security requirements for the IT environment that are relevant to the administrator.AGD_ADM.1.8C

6.1.12.4 – User guidance (AGD_USR.1)The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE. AGD_USR.1.1C

The developer shall provide user guidance.AGD_USR.1.1D

The user guidance shall describe the use of user-accessible security functions provided by the TOE.AGD_USR.1.2C

The user guidance shall contain warnings about user-accessible functions and privileges that should be controlled in a secure processing environment.AGD_USR.1.3C



The user guidance shall clearly present all user responsibilities necessary for secure operation of the TOE, including those related to assumptions regarding user behavior found in the statement of TOE security environment.AGD_USR.1.4C

The user guidance shall be consistent with all other documentation supplied for evaluation.AGD_USR.1.5C

The user guidance shall describe all security requirements for the IT environment that are relevant to the user.AGD_USR.1.6C

6.1.13 Life cycle support (ALC)

6.1.13.1 - Identification of security measures (ALC_DVS.1) The development security documentation shall describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment.ALC_DVS.1.1C The developer shall produce development security documentation.ALC_DVS.1.1D The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE.ALC_DVS.1.2C



6.1.14 Tests (ATE)

6.1.14.1 ATE_COV.1 Evidence of coverage


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 identified in the test documentation and the TSF as described 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.

Dependencies: ADV_FSP.1 Informal functional specificationATE_FUN.1 Functional testing

6.1.14.2 ATE_FUN.1 Functional testing


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

ATE_FUN.1.2D The developer shall provide test documentation.


ATE_FUN.1.1C The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test results.

ATE_FUN.1.2C The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed.

ATE_FUN.1.3C The test procedure descriptions shall identify the tests to be performed and describe the scenarios for testing each security function. These scenarios shall include any ordering dependencies on the results of other tests.

ATE_FUN.1.4C The expected test results shall show the anticipated outputs from a successful execution of the tests.

ATE_FUN.1.5C The test results from the developer execution of the tests shall demonstrate that each tested security function behaved as specified.


ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.




6.1.14.3 ATE_IND.2 Independent testing – sample


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 test a subset of the TSF as appropriate to confirm that the TOE operates as specified.

ATE_IND.2.3E The evaluator shall execute a sample of tests in the test documentation to verify the developer test results.

Dependencies: ADV_FSP.1 Informal functional specificationAGD_ADM.1 Administrator guidanceAGD_USR.1 User guidanceATE_FUN.1 Functional testing



6.1.15 Vulnerability assessment (AVA)

6.1.15.1 AVA_SOF.1 Strength of TOE security function evaluation


AVA_SOF.1.1D The developer shall perform a strength of TOE security function analysis for each mechanism identified in the ST as having a strength of TOE security function claim.


AVA_SOF.1.1C For each mechanism with a strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level defined in the PP/ST.

AVA_SOF.1.2C For each mechanism with a specific strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ST.


AVA_SOF.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AVA_SOF.1.2E The evaluator shall confirm that the strength claims are correct.

Dependencies: ADV_FSP.1 Informal functional specificationADV_HLD.1 Descriptive high-level design

6.1.15.2 AVA_VLA.1 Developer vulnerability analysis


AVA_VLA.1.1D The developer shall perform a vulnerability analysis.

AVA_VLA.1.2D The developer shall provide vulnerability analysis documentation.


AVA_VLA.1.1C The vulnerability analysis documentation shall describe the analysis of the TOE deliverables performed to search for obvious ways in which a user can violate the TSP.

AVA_VLA.1.2C The vulnerability analysis documentation shall describe the disposition of obvious vulnerabilities.

AVA_VLA.1.3C The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.


AVA_VLA.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AVA_VLA.1.2E The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure obvious vulnerabilities have been addressed.



Dependencies: ADV_FSP.1 Informal functional specificationADV_HLD.1 Descriptive high-level designAGD_ADM.1 Administrator guidanceAGD_USR.1 User guidance



Security Target (ASE)

6.1.15.3 TOE description (ASE_DES.1)

6.1.15.4 Security Environment (ASE_ENV.1)

6.1.15.5 ST introduction (ASE_INT.1)

6.1.15.6 Security objectives (ASE_OBJ.1)

6.1.15.7 PP claims (ASE_PPC.1)

6.1.15.8 IT security requirements (ASE_REQ.1)

6.1.15.9 Explicitly stated IT security requirements (ASE_SRE.1)

6.1.15.10 TOE summary specification (ASE_TSS.1)



6.2 Security Requirements for the IT EnvironmentClearly state and trace security objectives for the environment back to aspects of identified threats not completely countered by the TOE and/or organizational security policies or assumptions not completely met by the TOE.



7 Rationale

7.1 Security Objectives Rationale

7.2 Security Requirements Rationale

7.2.1 Functional Security Requirements Rationale

7.2.2 Rationale for minimum strength of function level

7.2.3 Rationale for assurance requirements

7.2.4 Mutual support of security requirements

7.2.5 Dependency Rationale



8 Acronyms

CC - Common Criteria

EAL - Evaluation Assurance Level

IT - Information Technology

PP - Protection Profile

SF - Security Function

SFP - Security Function Policy

SOF - Strength of Function

ST - Security Target

TOE - Target of Evaluation

TSC - TSF Scope of Control

TSF - TOE Security Functions

TSFI - TSF Interface

TSP - TOE Security Policy

TSF - TOE Security Function

MFD MFP - Multi-functional deviceMultifunction product

HDD - Hard-disc drive

HCD – Hardcopy Device

CPU - Central processing unit

RAM - Random access memory

PC - Personal computer

LCD - Liquid crystal display

ACL - Access control list


spastyle.docgrouper.ieee.org/groups/2600/email/doc00022.doc · Web viewIEEE P2600™/PP 1.73....

Documents

Transcript of spastyle.docgrouper.ieee.org/groups/2600/email/doc00022.doc · Web viewIEEE P2600™/PP 1.73....