Ricoh Mp 3351 User Guide

							  Page 51 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved. Functional requirements Management requirements Management items FMT_MTD.1 a) Managing the group of roles that can 
interact with the TSF data. None: No groups of roles can interact with 
TSF data. FMT_SMF.1 None - FMT_SMR.1 a) Managing the group of users that are 
part of a role. Management of administrator  
roles by administrators. FPT_STM.1 a) Management of the time. Security Management Function 
(management of machine control data): 
The machine administrator manages the 
following setting items for machine 
control data. 
- Data of system clock, time (hour, minute 
and second). FPT_TST.1 a) Management of the conditions under 
which TSF self testing occurs, such as 
during initial start-up, regular interval, 
or under specified conditions. 
b) Management of the time interval if 
appropriate. a) None: The condition under which TSF 
self-testing occurs is fixed. 
b) None: No management of time interval. FTP_ITC.1 a) Configuring the actions that require 
trusted channel, if supported. None: Actions that require  
Inter-STF trusted channels are fixed. FTP_TRP.1 a) Configuring the actions that require 
trusted path, if supported. None: Actions that require trusted paths 
are fixed.  
FMT_SMR.1 Security roles 
Hierarchical to: No other components. 
Dependencies: FIA_UID.1 Timing of identification. 
FMT_SMR.1.1 The TSF shall maintain the roles [assignment: general users, administrators (machine 
administrator, file administrator, user administrator, and network administrator) and a 
supervisor]. 
FMT_SMR.1.2 The TSF shall be able to associate users with roles. 
6.1.6 Class FPT: Protection of the TSF 
FPT_STM.1 Reliable time stamps 
Hierarchical to: No other components. 
Dependencies: No dependencies. 
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps. 
 
FPT_TST.1 TSF testing 
Hierarchical to: No other components.  
						

							  Page 52 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  Dependencies: No dependencies. 
FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-up] to demonstrate the 
correct operation of [selection: [assignment: encryption function of the Ic Hdd]]. 
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of the 
[selection: [assignment: HDD cryptographic key]]. 
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of stored 
TSF executable code. 
6.1.7 Class FTP: Trusted path/channels 
FTP_ITC.1 Inter-TSF trusted channel 
Hierarchical to: No other components. 
Dependencies: No dependencies. 
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another 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] to initiate communication via the trusted channel. 
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment: Deliver to 
Folders from TOE to SMB server (IPSec) service and Deliver to Folders from TOE to 
FTP server (IPSec) service]. 
 
FTP_TRP.1 Trusted path 
Hierarchical to: No other components. 
Dependencies: No dependencies. 
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [selection: remote] users 
that is logically distinct from other communication paths and provides assured identification 
of its end points and protection of the communicated data from [selection: modification and 
disclosure]. 
FTP_TRP.1.2 The TSF shall permit [selection: the TSF, 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: TOE web service, printing service from a client computer, fax service from 
a client computer, and e-mail service to a client computer from the TOE]]. 
Table 20 shows the services that require the trusted path defined in FTP_TRP.1.3 and used by each user who 
communicates via trusted path described in FTP_TRP.1.2.  
						

							  Page 53 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  Table 20: Services requiring trusted paths Related persons for communication Services that require a trusted path TSF E-mail service to client computer from  TOE (S/MIME) Remote users Initial user authentication (SSL) 
TOE web service from client PC (SSL) 
Printing service from client PC (SSL) 
Fax service from client PC (SSL)  
						

							  Page 54 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  6.2 Security Assurance Requirements 
The evaluation assurance level of this TOE is EAL3. Table 21 lists the assurance components of the TOE. 
These components meet evaluation assurance level 3 (EAL3). Other requirements are not included. 
Table 21: TOE Security assurance requirements (EAL3) Assurance classes Assurance components ADV_ARC.1 Security architecture description ADV_FSP.3 Functional specification with complete 
summary ADV: Development 
ADV_TDS.2 Architectural design AGD_OPE.1 Operational user guidance AGD: Guidance documents 
AGD_PRE.1 Preparative procedures ALC_CMC.3 Authorisation controls ALC_CMS.3 Implementation representation CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC: Life-cycle support 
ALC_LCD.1 Developer defined life-cycle model ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE: Security Target evaluation 
ASE_TSS.1 TOE summary specification ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: basic design ATE_FUN.1 Functional testing ATE: Tests 
ATE_IND.2 Independent testing – sample AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis   
						

							  Page 55 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  6.3 Security Requirements Rationale 
This section describes the rationale behind the security requirements. If all security functional requirements 
are satisfied as below, the security objectives defined in 4.1Security Objectives for TOE are fulfilled. 
6.3.1 Tracing 
Table 22 shows the relationship between the TOE security functional requirements and TOE security 
objectives. The v in the table indicates that the TOE security functional requirement fulfills the TOE 
security objective. 
Table 22 shows that each TOE security functional requirement fulfills at least one TOE security objective. 
Table 22: Relationship between security objectives and functional requirements  O.AUDIT
 
O.I&A
 
O.DOC_ACC
 
O.MANAGE
 
O.MEM.PROTECT
 
O.NET.PROTECT
 
O.GENUINE
 
O.LINE_PROTECT
 FAU_GEN.1 v        FAU_SAR.1 v        FAU_SAR.2 v        FAU_STG.1 v        FAU_STG.4 v        FCS_CKM.1     v    FCS_COP.1     v    FDP_ACC.1   v      FDP_ACF.1   v      FDP_IFC.1        v FDP_IFF.1        v FIA_AFL.1  v       FIA_ATD.1  v       FIA_SOS.1  v       FIA_UAU.2  v       FIA_UAU.7  v       FIA_UID.2  v        
						

							  Page 56 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  O.AUDIT
 
O.I&A
 
O.DOC_ACC
 
O.MANAGE
 
O.MEM.PROTECT
 
O.NET.PROTECT
 
O.GENUINE
 
O.LINE_PROTECT
 FIA_USB.1  v       FMT_MSA.1    v     FMT_MSA.3    v     FMT_MTD.1    v     FMT_SMF.1    v     FMT_SMR.1    v     FPT_STM.1 v        FPT_TST.1     v  v  FTP_ITC.1      v   FTP_TRP.1      v    
6.3.2 Justification of Traceability 
This section describes how the TOE security objectives are fulfilled by the TOE security functional 
requirements corresponding to the TOE security objectives shown in Table 22. 
O.AUDIT Audit 
Following are the rationale behind the functional requirements corresponding to O.AUDIT in Table 22, and 
these requirements are included to fulfill the O.AUDIT specification. 
a) Record audit logs 
To fulfill O.AUDIT, the performance of Security Functions should be recorded as audit logs. For this, 
FAU_GEN.1 generates audit information whenever an Audit Function starts and ends, whenever an 
identification or authentication function is performed, whenever users operate protected assets, 
whenever protected assets are encrypted, and whenever a major Management Function is performed. 
The log also records the date, time, type, subject identity, and outcome of each event. 
b) Provide Audit Function 
To fulfill O.AUDIT, access to audit logs should be restricted to the machine administrator only, and in a 
format that can be audited. For this, FAU_SAR.1 allows only the machine administrator to read audit 
logs, and FAU_SAR.2 prohibits persons other than the machine administrator reading audit logs. 
c) Protect audit logs 
To fulfill O.AUDIT, audit logs should have adequate protection. For this, FAU_STG.4 protects audit 
logs from unauthorised deletion and prevents unauthorised tampering. If auditable events occur and the 
audit log files are full, FAU_STG.4 prevents loss of recent audit logs by writing the newer audit logs 
over audit logs that have the oldest time stamp.  
						

							  Page 57 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  d) Reliable record of time of event 
To fulfill O.AUDIT, a reliable record of the times when events occurred should be available, as this will 
help identify security breaches. 
For this, FPT_STM.1 provides a trusted time stamp. 
O.I&A User identification and authentication 
Following are the rationale behind the functional requirements corresponding to O.I&A in Table 22, and 
these requirements are included to fulfill the O.I&A specification. 
a) Identify and authenticate users before they use the TOE. 
To fulfill O.I&A, user identification and authentication shall be performed prior to allowing user access 
to the TOE Security Functions. 
For this, FIA_UID.2 identifies users prior to their use of TOE Security Functions, and FIA_UAU.2 
authenticates identified users. 
b) Allow successfully identified and authenticated users to use the TOE. 
To fulfill O.I&A, users who authenticate successfully before they use any TOE Security Functions shall 
be allowed use of the functions they have permission for. 
For this, FIA_ATD.1 and FIA_USB.1 bind successfully identified and authenticated users with relevant 
subjects. Association and maintenance of the subjects with security attributes is also performed by 
FIA_ATD.1 and FIA_USB.1. 
c) Complicate decoding of passwords. 
To fulfill O.I&A, passwords for user authentication shall be protected from others while they are being 
entered, and must not be easily guessable. 
For this, FIA_UAU.7 prevents passwords being viewed by displaying masking characters (*: asterisks 
or ?: bullets) in place of each password character entered in the authentication feedback area. 
FIA_SOS.1 accepts only passwords that satisfy the Minimum Password Length and password character 
combination specified by the user administrator, and it enables only passwords that are not easily 
guessable. FIA_AFL.1 also reduces the possibility of users guessing passwords by locking out users 
when their number of authentication attempts reaches the number specified by the machine 
administrator. The authentication attempts include user authentication attempts from the Operation 
Panel, the Web browser of a client computer, or a client computer when printing or faxing. 
O.DOC_ACC Control of access to protected assets 
Following are the rationale behind the functional requirements corresponding to O.DOC_ACC in Table 22, 
and these requirements are included to fulfill the O.DOC_ACC specification. 
a) Specify access control to document data and perform operations. 
To fulfill O.DOC_ACC, each user shall be allowed to perform operations on document data according 
to the operation permissions for document data set for each type of subject associated with the users and 
each security attribute associated with the subject. 
For this, FDP_ACC.1 and FDP_ACF.1 allow the administrator to delete document data if the 
administrators role associated with the administrator process is the file administrator. For general users, 
FDP_ACC.1 and FDP_ACF.1 allow storage of document data, and when the general user IDs 
associated with general user processes are registered in the document data ACL of a document,  
						

							  Page 58 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  FDP_ACC.1 and FDP_ADF.1 allow the general user to perform operations on document data. The 
operations that are permitted follow the operation permissions specified in the document data for each 
general user ID in the document data ACL. 
O. MANAGE Security management 
Following are the rationale behind the functional requirements corresponding to O.MANAGE in Table 22, 
and these requirements are included to fulfill the O.MANAGE specification. 
a) Management of security attributes. 
To fulfill O.MANAGE, management of security attributes shall be permitted to specified users only, 
and a default value shall be specified for the document data ACL, which is a security attribute. For this, 
FMT_MSA.1 allows: 
- the user administrator to query, newly create, and change general user IDs; 
- general users to query general user IDs; 
- administrators to query and change their own administrator IDs; 
- supervisors to query administrator IDs; 
- administrators to query, add, and delete administrator roles assigned to themselves; 
- supervisors to query and change supervisor IDs; 
- the file administrator, document file owners, and general users with full control operation permission 
for the document data to query and modify its document data ACL; and 
- the user administrator and general users with full control operation permission for the document data 
to query and modify the default ACLs of document data. 
FMT_MSA.3 specifies the default value of the document data ACL for storage of new document data. 
b) Management and protection of TSF data. 
To fulfill O.MANAGE, access to TSF data shall be limited to specified users. For this, FMT_MTD.1 
allows: 
- the machine administrator to query and specify the Number of Attempts before Lockout, specify the 
setting of the Lockout release timer, specify a Lockout time, specify a Lockout Flag for supervisors, 
specify the date and time of the system clock, specify the service mode lock setting, newly create and 
query HDD cryptographic keys, and query and delete audit logs.  
FMT_MTD.1 also allows: 
- authorised TOE users to query the date and time of the system clock and the service mode lock 
setting; 
- the user administrator to query and specify the Minimum Password Length, complexity setting, and a 
Lockout Flag for general users; 
- the user administrator and applicable general users to specify the authentication information of 
general users, and newly create, delete, and change S/MIME user information; 
- the user administrator and general users to query S/MIME user information and destination details 
when sending data to folders; 
- supervisors to query and specify the Lockout Flag for administrators, and specify supervisor 
authentication information; and 
- supervisors and applicable administrators to change administrator authentication information. 
c) Specify Management Functions. 
To fulfill O.MANAGE, the Security Management Functions for the implemented TSF shall be  
						

							  Page 59 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  performed. 
For this, FMT_SMF.1 specifies the required Security Management Functions for the Security Function 
requirements. 
d) Authorised use of Security Management Functions. 
To fulfill O.MANAGE, authorised users shall be associated with the security management roles, and 
operation permissions for the Security Management Functions shall be maintained, since the use of the 
Security Management Functions depends on the authorised user roles. 
FMT_SMR.1 associates authorised users with a general user, one of the four administrator roles (user 
administrator, machine administrator, file administrator, or network administrator), or the supervisor 
role, and maintains this association. 
O.MEM.PROTECT Prevention of disclosure of data stored in memory 
Following are the rationale behind the functional requirements corresponding to O.MEM.PROTECT in 
Table 22, and these requirements are included to fulfill the O.MEM.PROTECT specification. 
a) Generate the encryption keys and perform encryption operations adequately. 
To fulfill O.MEM.PROTECT, the document data stored on the HDD shall be sufficiently encrypted to 
make decoding difficult unless the document data is read with normal methods using the TOE. 
For this, FCS_CKM.1 generates encryption keys at a key size of 256 bits with TRNG for the encryption 
key generation algorithm (based on BSI-AIS31); and FCS_COP.1 encrypts document data when it is 
stored on the HDD and decrypts it when it is read from the HDD using the encryption keys generated 
with the AES encryption algorithm (which corresponds to FIPS197). Additionally, FTP_TST.1 tests at 
the TOE start-up the validity of encryption keys and the performance of the Ic Hdd where encryption is 
performed, and this prevents storage of unencrypted document data on the HDD. 
O.NET.PROTECT Protection of network communication data 
Following are the rationale behind the functional requirements corresponding to O.NET.PROTECT in Table 
22, and these requirements are included to fulfill the O.NET.PROTECT specification. 
a) Protect assets on communication path. 
To fulfill O.NET.PROTECT, document data and print data on the communication path shall be 
protected from leakage, and attempts at tampering with it shall also be detected.  
For this, FTP_ITC.1 uses the IPSec protocol to protect data sent from the TOE to folders on FTP or 
SMB servers, to protect document data on the network from leakage, and also to detect attempts at 
tampering with document data.  
FTP_TRP.1 also protects document data on networks from leakage and detects attempts at tampering 
by use of a trusted path (described later) between the TOE and remote users. The mail service is 
protected by S/MIME, which protects data sent by e-mail from the TOE to a client computer, protects 
document data or print data on the network from leakage, and detects attempts at tampering. 
The SSL protocol protects document data and print data that are is travelling through a web service, 
print service, or fax service from a client computer from leakage and attempts at tampering.  
						

							  Page 60 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  O.GENUINE Protection of integrity of MFP Control Software integrity 
Following are the rationale behind the functional requirements corresponding to O.GENUINE in Table 22, 
and these requirements are included to fulfill the O.GENUINE specification. 
a) Check the integrity of the MFP Control Software. 
To fulfill O.GENUINE, the integrity of the MFP Control Software, which is installed in FlashROM, 
shall be verified. For this, FPT_TST.1 tests the integrity of the executable code of the MFP Control 
Software, which is installed in the FlashROM, and verifies its integrity at TOE start-up. 
O.LINE_PROTECT  Protection from intrusion via telephone line 
Following are the rationale behind the functional requirements corresponding to O.LINE.PROTECT in Table 
22, and these requirements are included to fulfill the O.LINE.PROTECT specification. 
a) Prohibit intrusion via the fax line. 
To fulfill O.LINE_PROTECT, unauthorised access by an attacker to the TOE via telephone line shall 
be prevented. 
For this, FDP_IFC.1 and FDP_IFF.1 allow fax data to pass from the fax process on the Fax Unit to the 
fax reception process on the Controller Board only if the data received from the telephone line is fax 
data. 
6.3.3 Dependency Analysis 
Table 23 shows the correspondence of dependencies in this ST for the TOE security functional requirements. 
Table 23: Correspondence of dependencies of TOE security functional requirements TOE security functional requirements Dependencies claimed by CC Dependencies satisfied in ST Dependencies not satisfied in ST FAU_GEN.1 FPT_STM.1 FPT_STM.1 None FAU_SAR.1 FAU_GEN.1 FAU_GEN.1 None FAU_SAR.2 FAU_SAR.1 FAU_SAR.1 None FAU_STG.1 FAU_GEN.1 FAU_GEN.1 None FAU_STG.4 FAU_STG.1 FAU_STG.1 None FCS_CKM.1 [FCS_CKM.2 or 
FCS_COP.1] 
FCS_CKM.4 FCS_COP.1 FCS_CKM.4 FCS_COP.1 [FDP_ITC.1 or 
FDP_ITC.2 or 
FCS_CKM.1] 
FCS_CKM.4 FCS_CKM.1 FCS_CKM.4 FDP_ACC.1 FDP_ACF.1 FDP_ACF.1 None FDP_ACF.1 FDP_ACC.1 
FMT_MSA.3 FDP_ACC.1 
FMT_MSA.3 None