Ricoh Mp 3351 User Guide

							  Page 61 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved. TOE security functional requirements Dependencies claimed by CC Dependencies satisfied in ST Dependencies not satisfied in ST FDP_IFC.1 FDP_IFF.1 FDP_IFF.1 None FDP_IFF.1 FDP_IFC.1 
FMT_MSA.3 FDP_IFC.1 
FMT_MSA.3 None FIA_AFL.1 FIA_UAU.1 FIA_UAU.2 FIA_UAU.1 FIA_ATD.1 None None None FIA_SOS.1 None None None FIA_UAU.2 FIA_UID.1 FIA_UID.2 FIA_UID.1 FIA_UAU.7 FIA_UAU.1 FIA_UAU.2 FIA_UAU.1 FIA_UID.2 None None None FIA_USB.1 FIA_ATD.1 FIA_ATD.1 None FMT_MSA.1 [FDP_ACC.1 or 
FDP_IFC.1] 
FMT_SMF.1 
FMT_SMR.1 FDP_ACC.1 
FMT_SMF.1 
FMT_SMR.1 None FMT_MSA.3 FMT_MSA.1 
FMT_SMR.1 FMT_MSA.1 
FMT_SMR.1 None FMT_MTD.1 FMT_SMF.1 
FMT_SMR.1 FMT_SMF.1 
FMT_SMR.1 None FMT_SMF.1 None None None FMT_SMR.1 FIA_UID.1 FIA_UID.2 FIA_UID.1 FPT_STM.1 None None None FPT_TST.1 None None None FTP_ITC.1 None None None FTP_TRP.1 None None None The following explains the rationale of acceptability in all cases where a dependency is not satisfied:  
 
Rationale for Removing Dependencies on FCS_CKM.4 
In this TOE, the HDD encryption keys are stored in an area that cannot be accessed from outside the Ic Hdd. 
In addition, after the administrator generates the encryption keys at the start of TOE operation, deletion of 
the older encryption keys is not performed: they are overwritten with the new encryption keys. For these 
reasons, encryption key destruction by the standard method is unnecessary. 
 
Rationale for Removing Dependencies on FIA_UAU.1 
Since this TOE employs FIA_UAU.2, which is hierarchical to FIA_UAU.1, the dependency on FIA_UAU.1 
is satisfied by FIA_AFL.1 and FIA_UAU.7. 
  
						

							  Page 62 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  Rationale for Removing Dependencies on FIA_UID.1 
Since this TOE employs FIA_UID.2, which is hierarchical to FIA_UID.1, the dependency on FIA_UID.1 is 
satisfied by FIA_UAU.2 and FMR_SMR.1. 
6.3.4 Security Assurance Requirements Rationale 
This TOE is a commercially available product. It is assumed that it will be used in general offices, and that 
the possibility of basic security attacks on this TOE exists. Architectural design (ADV_TDS.2) is adequate to 
show the validity of commercially available products. A high attack potential is required for attacks that 
circumvent or tamper with the TSF, which is not covered in this evaluation. The vulnerability analysis 
(AVA_VAN.2) is therefore adequate for general needs. 
However, protection of the secrecy of relevant information is required to make security attacks more difficult, 
and it is important to ensure a secure development environment. Development security (ACL_DVS.1) is 
therefore important also. 
Based on the terms and costs of the evaluation, the evaluation assurance level of EAL3 is appropriate for this 
TOE.  
						

							  Page 63 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  7 TOE Summary Specification 
This section provides a specification summary of the Security Functions of this TOE. 
7.1 TOE Security Function 
The TOE provides the following TOE Security Functions to satisfy the security functional requirements 
described in Section 6.1. 
SF.AUDIT  Audit Function 
SF.I&A  User Identification and Authentication Function 
SF.DOC_ACC  Document Data Access Control Function 
SF.SEC_MNG  Security Management Function 
SF.CE_OPE_LOCK Service Mode Lock Function 
SF.CIPHER  Encryption Function 
SF.NET_PROT Network Communication Data Protection Function 
SF.FAX_LINE  Protection Function for Intrusion via Telephone Line 
SF.GENUINE  MFP Control Software Verification Function 
 
As Table 24 shows, at least one TOE Security Function satisfies each security functional requirements 
described in section 6.1. 
Table 24: Relationship between TOE security functional requirements and TOE security functions  SF.AUDIT
 
SF.I&A
 
SF.DOC_ACC
 
SF.SEC_MNG
 
SF.CE_OPE_LOCK
 
SF.CIPHER
 
SF.NET_PROT
 
SF.FAX_LINE
 
SF.GENUINE
 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        
						

							  Page 64 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  SF.AUDIT
 
SF.I&A
 
SF.DOC_ACC
 
SF.SEC_MNG
 
SF.CE_OPE_LOCK
 
SF.CIPHER
 
SF.NET_PROT
 
SF.FAX_LINE
 
SF.GENUINE
 FDP_IFC.1        v  FDP_IFF.1        v  FIA_AFL.1  v  v      FIA_ATD.1  v        FIA_SOS.1  v        FIA_UAU.2  v        FIA_UAU.7  v        FIA_UID.2  v        FIA_USB.1  v  v      FMT_MSA.1    v      FMT_MSA.3    v      FMT_MTD.1 v   v v v    FMT_SMF.1  v  v      FMT_SMR.1  v  v      FPT_STM.1 v         FPT_TST.1      v   v FTP_ITC.1       v   FTP_TRP.1       v    
Following are the security functional requirements that correspond to these TOE Security Functions. 
7.1.1 SF.AUDIT  Audit Function 
The TOE starts the Audit Function when power is supplied and the TOE starts up, and keeps running the 
Audit Function until power down. While the Audit Function is running, the TOE creates audit logs whenever 
an auditable event occurs. These audit logs must be protected from loss before audit. Only the machine 
administrator is permitted to read audit logs and delete entire audit logs. 
Following are explanations of each functional item in SF.AUDIT  Audit Function and their 
corresponding security functional requirements. 
7.1.1.1 Generation of Audit Logs 
The TOE generates audit log entries whenever an auditable event occurs, and appends these to audit log files. 
Audit logs consist of basic audit information and expanded audit information. Basic audit information is data  
						

							  Page 65 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  recorded when any kind of auditable event occurs. Expanded audit information is data recorded for the 
generation of auditable events that require additional information for audit. Table 25 shows the audit 
information for each auditable event. 
If there is insufficient space in the audit log files to append new audit log files, older audit logs (identifiable 
by their time and date details) are overwritten with newer audit logs. 
Table 25: Auditable events and auditable information Audit logs Auditable events Basic audit information Expanded audit information Starting Audit Function (*1) - Ending Audit Function (*1) - Login - Starting Lockout Locked out user Releasing Lockout (*2) Locked out user who is to be 
released 
Release methods (auto Lockout 
release/manual Lockout release) Lockout release at TOE startup - HDD encryption key generation - Successful storage of document 
data ID of object document data Successful reading of document 
data (*3) ID of object document data Successful deletion of 
document data ID of object document data Receiving fax - Changing user password 
(including new creation and 
deletion) The ID of the user in the event 
of new 
creation/changing/deletion of 
another users authentication 
details Deletion of administrator role - Addition of administrator role - Changing document data ACL ID of object document data Changing date and time of 
system clock - Communication with trusted IT 
product Communication IP address Communication with remote 
user - Date/time of event 
- Types of event (auditable events 
in this table) 
- Subject identity (*4) 
- Outcome 
- Deletion of entire audit log  - -: No applicable expanded audit information  
						

							  Page 66 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  *1: The starting of Audit Function is substituted with the event of the TOE startup. This TOE does not record 
the ending of Audit Function. The starting and ending of Audit Function audit the state of inactivity of Audit 
Function. Since Audit Function works as long as the TOE works and it is not necessary to audit the state of 
inactivity of Audit Function, it is appropriate not to record the ending of Audit Function. 
*2: Lockout release for administrators and supervisor by the TOEs restart, which is the special Lockout 
release operation, is substituted with the event of the TOE startup. 
*3: For the successful reading of the document data, the objects to be recorded in IDs for the operational 
object document data are printing, Sending by E-mail, Delivering to Folders and downloading from Web 
Service Function the document data stored in D-BOX 
*4 When the recording events occur due to the operations by users, User IDs are set as subject identities of 
basic audit information, and when the recording events occur due to the TOE, IDs that do not duplicate the 
user IDs but can identify systems are set. 
Since there are no interfaces on the TOE for modifying audit logs, unauthorised modification for the audit 
logs are not performed and the machine administrator who can delete the audit logs will not carry out any 
malicious acts using administrator privileges. 
By the above, FAU_GEN.1 (Audit data generation), FAU_STG.1 (Protected audit trail storage), and 
FAU_STG.4 (Prevention of audit data loss) are satisfied. 
7.1.1.2 Reading Audit Logs 
The TOE allows only the machine administrator to read the audit logs in a text format using the Web Service 
Function. 
By the above, FAU_SAR.1 (Audit review), FAU_SAR.2 (Restricted audit review), and FMT_MTD.1 
(Management of TSF data) are satisfied. 
7.1.1.3 Protection of Audit Logs 
The TOE allows only the machine administrator to delete entire audit logs using the Operation Panel or the 
Web Service Function. 
By the above, FAU_SAR.1 (Audit review), FAU_SAR.2 (Restricted audit review), and FMT_MTD.1 
(Management of TSF data) are satisfied. 
7.1.1.4 Time Stamps 
The TOE logs the date and time of events by referencing the date and time of the internal system clock. 
By the above, FPT_STM.1 (Reliable time stamps) is satisfied. 
7.1.2 SF.I&A  User Identification and Authentication Function 
To allow authorised users to operate the TOE according to their roles and authorisation, the TOE identifies 
and authenticates users prior to their use of the TOE Security Functions. 
Following are the explanations of each functional item in SF.I&A  User Identification and 
Authentication Function and their corresponding security functional requirements.  
						

							  Page 67 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  7.1.2.1 User Identification and Authentication 
The TOE displays a login window when users attempt to use the TOE Security Functions from the Operation 
Panel or the Web Service Function. This window requires the user to enter their ID and password, and then 
identifies and authenticates the user based on the entered user IDs and passwords. 
The TOE also identifies and authenticates the user based on the user ID and password sent from the client 
computer when the TOE receives a request from the client computer for printing or transmitting faxes. 
The TOE binds successfully authenticated users to the processes available to them (general user processes, 
administrator processes, or supervisor processes) according to their user roles (general users, administrators, 
or supervisors), associates each process with the security attributes of that role, and maintains those bindings 
and associations. If the user is a general user, the TOE binds the general user to general user processes, 
associates general user processes with a general user ID and the document data default ACL, and maintains 
those bindings and associations. If the user is an administrator, the TOE binds the administrator to 
administrator processes, associates administrator processes with the administrator ID and the administrator 
roles, and maintains those bindings and associations. If the user is a supervisor, the TOE binds the supervisor 
to supervisor processes, associates supervisor processes with the supervisor ID, and maintains those bindings 
and associations. 
Authentication methods vary according to the users role. Table 26 shows the authentication methods for 
each user role. 
Table 26: User roles and authentication methods User roles Authentication methods General users Check if the general user ID and password entered by the user match a general 
user ID and corresponding password registered in the Address Book. Administrators Check if the administrator ID and password entered by the user match an 
administrator ID and corresponding password registered to the TOE. Supervisor Check if the supervisor ID and password entered by the user match a supervisor 
ID and corresponding password registered to the TOE.  
By the above, FIA_ATD.1 (User attribute definition), FIA_UAU.2 (User authentication before any action), 
FIA_UID.2 (User identification before any action), FIA_USB.1 (User-subject binding), FMT_SMF.1 
(Specification of Management Functions), and FMT_SMR.1 (Security Roles) are satisfied. 
7.1.2.2 Actions in Event of Identification and Authentication Failure 
The TOE counts the number of failed identification and authentication attempts made under each ID, as 
described in 7.1.2.1 User Identification and Authentication. When the number of failed consecutive 
attempts reaches the machine administrator-specified Number of Attempts before Lockout, the TOE locks 
out the user, and sets the Lockout Flag for that user to Active. The machine administrator can specify 1 to 
5 as the Number of Attempts before Lockout. 
When a user authenticates successfully, as described in 7.1.2.1 User Identification and Authentication, the 
TOE resets the number of available authentication attempts for that user to 0 and starts counting from 0. 
When either of the following two Lockout release actions, (1) or (2), is performed by a user whose Lockout 
Flag is set to Active, the TOE resets the Lockout Flag for that user to Inactive and releases the Lockout.  
						

							  Page 68 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  (1) Auto Lockout Release 
If the user fails to authenticate after making the number of attempts specified to initiate lockout, and the 
lockout time has elapsed, then lockout will be released upon the first successful identification and 
authentication by the locked-out user. The machine administrator specifies the lockout time between 1 
and 9999 minutes. If the machine administrator sets the lockout time to indefinite, lockout release will 
be performed only by manual lockout release. In this case, lockout release must be performed by 
manual lockout release. 
(2) Manual Lockout Release 
The unlocking administrators (specified for each user role, as shown in Table 27), have permission to 
release Lockout using the Web Service Function. If an administrator (any role) or a supervisor is locked 
out, as a special Lockout release operation, restarting the TOE releases Lockout. 
Table 27: Unlocking administrators for each user role User roles (locked out users) Unlocking administrators General users User administrator Administrators (all administrator roles) Supervisor Supervisor Machine administrator  
By the above, FIA_AFL.1 (Authentication failure handling) and FMT_SMF.1 (Specification of Management 
Functions) are satisfied. 
7.1.2.3 Password Feedback Area Protection 
The TOE displays a string of masking characters (*: asterisks or ?: bullets) in place of each letter of a 
password entered from the Operation Panel or the Web browser of a client computer by a general user, 
administrator, or supervisor. 
From the above, FIA_UAU.7 (Protected authentication feedback) is satisfied. 
7.1.2.4 Password Registration 
The TOE provides a function for registering and changing the passwords of general users, administrators, 
and supervisors from the Operation Panel or the Web Service Function. This function uses a string of 
masking characters described in (1). 
This function checks if the password to be registered or changed meets conditions (2) and (3). If it does, the 
password is registered. If it does not, the password is not registered and an error message appears. 
(1) Usable characters and its types: 
Upper-case letters: [A-Z] (26 letters) 
Lower-case letters: [a-z] (26 letters) 
Numbers: [0-9] (10 digits) 
Symbols: SP (space) !  # $ % &  ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ (33 symbols) 
(2) Registerable password length: 
General users  
						

							  Page 69 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  No fewer than the Minimum Password Length specified by the user administrator (8-32 
characters) and no more than 128 characters. 
Administrators and supervisors 
No fewer than the Minimum Password Length specified by the user administrator (8-32 
characters) and no more than 32 characters. 
(3) Rule: 
Passwords that are composed of a combination of characters based on the Password Complexity 
Setting specified by the user administrator can be registered. The user administrator specifies either 
Level 1 or Level 2 for Password Complexity Setting. 
By the above, FIA_SOS.1 (Verification of secrets) and FMT_SMF.1 (Specification of Management 
Functions) are satisfied. 
7.1.3 SF.DOC_ACC  Document Data Access Control Function 
The TOE restricts user access to operations that store, read, and delete document data. The access control 
function displays only accessible document data on the Operation Panel or client computer where the user 
authenticated. Availability of document data is based on the roles assigned to the user who has been 
successfully authenticated by the Identification and Authentication Function, or the authorisation assigned to 
the individual user. This section describes the access control function that allows users to access document 
data based on their user role. 
Following are the explanations of each functional item in SF.DOC_ACC  Document Data 
Access Control Function and their corresponding security functional requirements. 
7.1.3.1 General User Operations on Document Data 
The TOE allows general users to store document data and to read and delete stored document data based on 
the document data ACL, which contains the IDs of general users who have permission to perform operations 
on the document data, and the operations permissions of the ID. If a general user ID that is associated with 
the general user process is registered for a document data ACL, the TOE allows that general user ID to 
perform operations on the document data according to the permissions assigned to the general user ID in the 
document data ACL. 
Table 2 shows the relationship between the operation permissions for document data and operations on 
document data. 
Table 28 shows the value of the document data ACL when storing document data. 
Table 28: Default value for document data ACL Type of document data Default value for document data ACL Document data stored by a general user Document data default ACL  
By the above, FDP_ACC.1 (Subset access control) and FDP_ACF.1 (Security attribute based access control) 
are satisfied.  
						

							  Page 70 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  7.1.3.2 File Administrator Operations on Document Data 
If the logged-in user from the Operation Panel or Web Service Function is a file administrator, the TOE 
allows that user to display a list of document data and to delete the document data in the list individually or 
all at once. 
By the above, FDP_ACC.1 (Subset access control) and FDP_ACF.1 (Security attribute based access control) 
are satisfied. 
7.1.4 SF.SEC_MNG  Security Management Function 
The TOE provides Security Management Functions according to the roles assigned to users who have been 
successfully identified and authenticated using the SF.I&A  User Identification and 
Authentication Function. Following are explanations of each functional item in SF.SEC_MNG 
 Security Management Function and their corresponding security functional requirements. 
7.1.4.1 Management of Document Data ACL 
Management of the document data ACL allows operations on the document data ACL from the Operation 
Panel or Web Service Function to be restricted to specified users only. Operations on the document data 
ACL include changing the document file owner and the document file owners operation permissions for the 
document data, newly registering and deleting document file users, and changing document file users 
operation permissions for the document data. These operations can be performed only by specified users who 
have been authorised for each operation. Table 29 shows the relationship between operations on the 
document data ACL and the users authorised for the operations. 
Table 29: Operations on document data ACL and Authorised users Operations on document data ACL Authorised users Changing of document file owners - File administrators Changing of Document file owners operation 
permissions for document data - File administrators 
- Document file owners 
- General users with full control authorisation Registration of new document file users - File administrators 
- Document file owners 
- General users with full control authorisation Deletion of document file users - File administrators 
- Document file owners 
- General users with full control authorisation Changing of document file users operation 
permissions for document data - File administrators 
- Document file owners 
- General users with full control authorisation  
If the logged-in user is a file administrator, the TOE allows that user to perform operations on all document 
data ACLs, including changing document file owners and their access rights, and newly registering and 
deleting document file users and changing their access rights.