Ricoh Mp 3351 User Guide

							  Page 31 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  A.NETWORK    (Assumptions for network connections) 
As specified by A.NETWORK, when the network that the TOE is connected to (the internal network) is 
connected to an external network such as the Internet, the internal network shall be protected from 
unauthorised communications originating from the external network. 
As specified by OE.NETWORK, if the internal network, to which the TOE is connected, is connected to an 
external network such as the Internet, the organisation managing operation of the internal network shall close 
any unnecessary ports between the external and internal networks. Therefore, A.NETWORK is upheld. 
T.ILLEGAL_USE  (Malicious usage of the TOE) 
To counter this threat, the TOE performs identification and authentication of users with O.I&A prior to their 
use of the TOE Security Functions, and allows the successfully authenticated user to use the functions for 
which the user has the operation permission. In addition, the TOE records the performance of O.I&A as audit 
logs by O.AUDIT, and provides only the Machine administrator with the function to read the audit logs so 
that the machine administrator detects afterwards whether or not there was security intrusion of O.I&A. 
Therefore, the TOE can counter T.ILLEGAL_USE. 
T.UNAUTH_ACCESS  (Access violation of protected assets stored in the TOE) 
To counter this threat, the TOE allows the authorised users identified by O.I&A to access to document data 
according to the operation permission on document data that are assigned to the authorised users roles and 
the authorised users by O.DOC_ACC. For example, if the authorised user is the general user, the TOE allows 
the general user to perform operations on document data according to the operation permissions. If the 
authorised user is a file administrator, the TOE allows the file administrator to delete the document data 
stored in the D-BOX. 
Therefore, the TOE can counter T.UNAUTH_ACCESS. 
T.ABUSE_SEC_MNG  (Abuse of Security Management Functions) 
To counter this threat, the TOE allows only users who have successfully authenticated with O.I&A to use the 
TOE Security Functions. The TOE also restricts management of the Security Functions to specified users 
only, and control of TSF data, and security attributes by O.MANAGE. In addition, O.I&A and O.MANAGE 
events are recorded in audit logs by O.AUDIT, and the function for reading audit logs is available to the 
machine administrator only, so that the machine administrator can later identify whether or not security 
intrusion events involving O.I&A and O.MANAGE occurred. 
Therefore, the TOE can counter T.ABUSE_SEC_MNG. 
T.SALVAGE    (Salvaging memory) 
To counter this threat, the TOE converts the format of document data by O.MEM.PROTECT, making the 
document data difficult to read and decode if the HDD is installed in a device other than the TOE. In addition, 
the performance of O.MEM.PROTECT is recorded in audit logs by O.AUDIT, and the function for reading 
audit logs is available to the machine administrator only, so that the machine administrator can later identify 
whether or not O.MEM.PROTECT was performed successfully. 
Therefore, the TOE can counter T.SALVAGE.  
						

							  Page 32 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  T.TRANSIT    (Data interception and tampering with communication path) 
To counter this threat, the TOE protects document data and Print Data on communication path from leakage, 
and detects tampering. In addition, the performance of O.NET.PROTECT is recorded as audit logs by 
O.AUDIT, and the function to read audit logs is only provided to the machine administrator so that the 
machine administrator verifies afterwards whether or not O.NET.PROTECT was performed. 
Therefore, the TOE can counter T.TRANSIT. 
T.FAX_LINE   (Intrusion via telephone line) 
To counter this threat, the TOE prevents the intrusion from a telephone line connected to Fax Unit to the 
TOE by O.LINE_PROTECT. In addition, the performance of O.LINE_PROTECT is recorded as audit logs 
by O.AUDIT, and the function to read audit logs is only provided to the machine administrator so that the 
machine administrator detects afterwards whether or not O.LINE_PROTECT was successfully performed. 
Therefore, the TOE can counter T.FAX_LINE. 
P.SOFTWARE    (Checking software integrity) 
To enforce this organisational security policy, the TOE provides the function to verify the integrity of MFP 
Control Software, which is installed in FlashROM, with the TOE users by O.GENUINE. 
Therefore, the TOE can enforce P.SOFTWARE. 
  
						

							  Page 33 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  5 Extended Components Definition 
In this ST and TOE, there are no extended components, i.e., the new security requirements and security 
assurance requirements that are not described in the CC, which is claimed the conformance in 2.1 CC 
conformance Claim.  
						

							  Page 34 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  6 Security Requirements 
This section describes the security functional requirements, security assurance requirements, and security 
requirements rationale. 
6.1 Security Functional Requirements 
This section describes the TOE security functional requirements for fulfilling the security objectives defined 
in 4.1 Security Objectives for TOE. The security functional requirements are quoted from the requirement 
defined in the CC Part2. 
The part with assignment and selection defined in the CC Part2 are identified with [bold face and brackets]. 
6.1.1 Class FAU: Security audit 
FAU_GEN.1 Audit data generation 
Hierarchical to: No other components. 
Dependencies: FPT_STM.1 Reliable time stamps. 
FAU_GEN.1.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) All auditable events for the [selection: not specified] level of audit; and 
c) [assignment: auditable events of the TOE shown in Table 4]. 
 
Table 4 shows the actions (CC rules) recommended by the CC as auditable for each functional requirement 
and the corresponding auditable events of the TOE. 
Table 4: List of auditable events Functional requirements Actions which should be auditable Auditable events of TOE FAU_GEN.1 None - FAU_SAR.1 a) Basic: Reading of information from 
the audit records. Auditable events not recorded. FAU_SAR.2 a) Basic: Unsuccessful attempts to 
read information from the audit 
records. Auditable events not recorded. FAU_STG.1 None - FAU_STG.4 a) Basic: Actions taken due to the 
audit storage failure. Auditable events not recorded. FCS_CKM.1 a) Minimal: Success and failure of the 
activity. 
b) Basic: The object attribute(s), and 
object value(s) excluding any sensitive  
1. HDD cryptographic key 
generation (Outcome:  
						

							  Page 35 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved. Functional requirements Actions which should be auditable Auditable events of TOE information (e.g. secret or private 
keys). Success/Failure) FCS_COP.1 a) Minimal: Success/failure, and type 
of cryptographic operation. 
b) Basic: Any applicable cryptographic 
mode(s) of operation, subject and 
object attributes.  
1. Storage of document data successful 2. Reading of  document data 
successful FDP_ACC.1 None - FDP_ACF.1 a) Minimal: Successful requests to 
perform an operation on an object 
covered by the SFP. 
b) Basic: All requests to perform an 
operation on an object covered by the 
SFP. 
c) Detailed: The specific security 
attributes used in making an access 
check.  
1. Storage of document data successful 2. Reading of document data 
successful 
3. Deletion of document data 
successful FDP_IFC.1 None - FDP_IFF.1 a) Minimal: Decisions to permit 
requested information flows. 
b) Basic: All decisions on requests for 
information flow. 
c) Detailed: The specific security 
attributes used in making an 
information flow enforcement 
decision. 
d) Detailed: Some specific subsets of 
the information that has flowed based 
upon policy goals (e.g. auditing of 
downgraded material). a) Minimal 
1. Fax Function: Reception FIA_AFL.1 a) Minimal: the reaching of the 
threshold for the unsuccessful 
authentication attempts and the actions 
(e.g. disabling of a terminal) taken and 
the subsequent, if appropriate, 
restoration to the normal state (e.g. 
re-enabling of a terminal). a) Minimal 
1. Lockout start 
2. Lockout release FIA_ATD.1 None - FIA_SOS.1 a) Minimal: Rejection by the TSF of 
any tested secret; 
b) Basic: Rejection or acceptance by 
the TSF of any tested secret; 
c) Detailed: Identification of any 
changes to the defined quality metrics. b) Basic 
1. Newly creating authentication 
information of general users 
(Outcome: Success/Failure) 
2. Changing authentication 
information of general users 
(Outcome: Success/Failure)  
						

							  Page 36 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved. Functional requirements Actions which should be auditable Auditable events of TOE 3. Changing administrator 
authentication information (Outcome: 
Success/Failure) 
4. Changing supervisor authentication 
information (Outcome: 
Success/Failure) FIA_UAU.2 Minimal: Unsuccessful use of the 
authentication mechanism; 
Basic: All use of the authentication 
mechanism. Basic 
1. Login (Outcome: Success/Failure) FIA_UAU.7 None - FIA_UID.2 a) Minimal: Unsuccessful use of the 
user identification mechanism, 
including the user identity provided; 
b) Basic: All use of the user 
identification mechanism, including 
the user identity provided. b) Basic 
1. Login (Outcome: Success/Failure) FIA_USB.1 a) Minimal: Unsuccessful binding of 
user security attributes to a subject 
(e.g. creation of a subject). 
b) Basic: Success and failure of 
binding of user security attributes to a 
subject (e.g. success or failure to create 
a subject). b) Basic 
1. Login (Outcome: Success/Failure) FMT_MSA.1 a) Basic: All modifications of the 
values of security attributes.  
1. Adding and deleting administrator 
roles 
2. Changing  document data ACL FMT_MSA.3 a) Basic: Modifications of the default 
setting of permissive or restrictive 
rules. 
b) Basic: All modifications of the 
initial values of security attributes. Auditable events not recorded. FMT_MTD.1 a) Basic: All modifications to the 
values of TSF data.  
1. Newly creating authentication 
information of general users. 
2. Changing authentication 
information of general users. 
3. Deleting authentication 
information of general users. 
4. Changing administrator 
Authentication information. 
5. Changing supervisor 
Authentication information.  
						

							  Page 37 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved. Functional requirements Actions which should be auditable Auditable events of TOE 6. Changing time and date of system 
clock. 
7. Deleting entire audit logs. FMT_SMF.1 a) Minimal: Use of the Management 
Functions.  
1. Adding and deleting administrator 
roles. 
2. Lockout release by the unlocking 
administrator. 
3. Changing time and date of system 
clock. FMT_SMR.1 a) Minimal: modifications to the group 
of users that are part of a role; 
b) Detailed: every use of the rights of a 
role. a) Minimal 
1. Adding and deleting administrator 
roles. FPT_STM.1 a) Minimal: changes to the time; 
b) Detailed: providing a timestamp. a) Minimal 
1. Changing time and date of system 
clock. FPT_TST.1 a) Basic: Execution of the TSF self 
tests and the results of the tests. - FTP_ITC.1 a) Minimal: Failure of the trusted 
channel functions. 
b) Minimal: Identification of the 
initiator and target of failed trusted 
channel functions. 
c) Basic: All attempted uses of the 
trusted channel functions. 
d) Basic: Identification of the initiator 
and target of all trusted channel 
functions.  
1. Communication with trusted IT 
products (Outcome: Success/Failure, 
Communication IP address) FTP_TRP.1 a) Minimal: Failures of the trusted path 
functions. 
b) Minimal: Identification of the user 
associated with all trusted path 
failures, if available. 
c) Basic: All attempted uses of the 
trusted path functions. 
d) Basic: Identification of the user 
associated with all trusted path 
invocations, if available.  
1. Communication with remote users 
(Outcome: Success/Failure)  
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 (if applicable), and the outcome 
(success or failure) of the event; and  
						

							  Page 38 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  b) For each audit event type, based on the auditable event definitions of the functional 
components included in the PP/ST, [assignment: communication IP address, IDs of 
persons whose authentication information is created/changed/deleted, Locking out users, 
release of user Lockout, method of Lockout release, IDs of object document data]. 
 
FAU_SAR.1 Audit review 
Hierarchical to: No other components. 
Dependencies: FAU_GEN.1 Audit data generation. 
FAU_SAR.1.1 The TSF shall provide [assignment: the machine administrator] with the capability to read 
[assignment: all log items] 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. 
 
FAU_SAR.2 Restricted audit review 
Hierarchical to: No other components. 
Dependencies: FAU_SAR.1 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. 
 
FAU_STG.1 Protected audit trail storage 
Hierarchical to: No other components. 
Dependencies: FAU_GEN.1 Audit data generation. 
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. 
FAU_STG.1.2 The TSF shall be able to [selection: prevent] unauthorised modifications to the stored audit 
records in the audit trail. 
 
FAU_STG.4 Prevention of audit data loss 
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss. 
Dependencies: FAU_STG.1 Protected audit trail storage. 
FAU_STG.4.1 The TSF shall [selection: overwrite the oldest stored audit records] and [assignment: no 
other actions to be taken in case of audit storage failure] if the audit trail is full. 
6.1.2 Class FCS: Cryptographic support 
FCS_CKM.1 Cryptographic key generation 
Hierarchical to: No other components. 
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or  
						

							  Page 39 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  FCS_COP.1 Cryptographic operation] 
FCS_CKM.4 Cryptographic key destruction. 
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key 
generation algorithm [assignment: cryptographic key generation algorithm shown in 
Table 5] and specified cryptographic key size [assignment: cryptographic key size shown 
in Table 5] that meet the following: [assignment: standards shown in Table 5]. 
Table 5: List of cryptographic key generation Key type Standard Cryptographic key generation algorithm Cryptographic key size HDD cryptographic 
key BSI-AIS31 TRNG 256 bits  
FCS_COP.1 Cryptographic operation 
Hierarchical to: No other components. 
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or 
FDP_ITC.2 Import of user data with security attributes, or 
FCS_CKM.1 Cryptographic key generation] 
FCS_CKM.4 Cryptographic key destruction. 
FCS_COP.1.1 The TSF shall perform [assignment: cryptographic operations shown in Table 6] in 
accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm 
shown in Table 6] and cryptographic key sizes [assignment: cryptographic key size shown 
in Table 6] that meet the following: [assignment: standards shown in Table 6]. 
Table 6: List of Cryptographic operations Key type Standard Cryptographic algorithm Cryptographic key size Cryptographic operations HDD 
cryptographic 
key FIPS197 AES 256 bits - Encryption when writing the 
document data on HDD 
- Encryption when reading the 
document data from HDD 6.1.3 Class FDP: User data protection 
FDP_ACC.1 Subset access control 
Hierarchical to: No other components. 
Dependencies: FDP_ACF.1 Security attribute based access control. 
FDP_ACC.1.1 The TSF shall enforce the [assignment: MFP access control SFP] on [assignment: List of 
Subjects, Objects, and Operation among Subjects and Objects in Table 7].  
						

							  Page 40 of 81 
Copyright (c) 2010 RICOH COMPANY, LTD. All Rights Reserved.  Table 7: List of subjects, objects, and operations among subjects and objects Subjects Objects Operations among subjects and objects Administrator process Document data Deleting document data General user process Document data Storing document data 
Reading document data 
Deleting document data  
FDP_ACF.1 Security attribute based access control 
Hierarchical to: No other components. 
Dependencies: FDP_ACC.1 Subset access control 
FMT_MSA.3 Static attribute initialisation. 
FDP_ACF.1.1 The TSF shall enforce the [assignment: MFP access control SFP] to objects based on the 
following: [assignment: subjects or objects, and their corresponding security attributes 
shown Table 8]. 
Table 8: Subjects, objects and security attributes Types Subjects or objects Security attributes Subject Administrator process - Administrator IDs 
- Administrator roles Subject General user process - General user ID 
- Document data default ACL Object Document data - Document data ACL  
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 subject 
operations on objects and access to the operations shown in Table 9]. 
Table 9: Rules governing access Subject Operations on objects Rules governing access Storing document data General users can store document data. When the document 
data is stored, the document data default ACL associated with 
the general user process is copied to the document data ACL 
associated with the document data. General user 
process 
Reading document data A general user process has permission to read document data 
if the general user ID associated with the general user process 
matches either the document file owner ID or the document 
file user ID in the document data ACL associated with the 
document data, and if the matched ID has viewing, editing, 
editing/deleting, or full control permission.