FortiSandbox 4.4 is a high-performance security solution that utilizes AI/machine learning technology to identify and isolate advanced threats in real-time.
\r\nFortiSandbox inspects files, websites, URLs and network traffic for malicious activity, including zero-day threats, and uses sandboxing technology to analyze suspicious files in a secure virtual environment.
","evaluation_configuration":"The TOE Evaluated Configuration includes only the functions necessary to enforce the requirements of this protection profile, described below. All other functionality, Fortinet product interactions, or other unique features of the device are outside the scope of the evaluation and were not tested.
\r\nEvaluated Configuration #1:
\r\nThe FortiSandbox is put in CC mode by issuing the CLI command “cc-mode-conf –e”.
\r\nHTTP GUI, Telnet, TFTP are disabled in CC mode by default.
\r\nA signed certificate from a trusted CA is loaded to replace the default Fortinet CA signed certificate.
\r\nSSH administrative access is enabled via the web based manager. Under system, interfaces, port1, double click on port1 and in the “Access Rights” box check the “SSH” box to enable.
\r\nA pre-login banner is enabled via the administrative GUI. Select “Login Disclaimer” and click on the “Show disclaimer on login”.
\r\nThe FortiAnalyzer (FAZ) remote logging server is set up:
\r\nThe FortiAnalyzer local log setting is configured via CLI with “config sys locallog fortianalyzer setting”, “set status disable”, “end”.
\r\nThe FAZ root CA certificate is downloaded via the administrative GUI under System Settings > Certificates > CA Certificates.
\r\nThe CA certificate for the FAZ is imported to the FortiSandbox via the administrative GUI under Certificates > Create New/Import > CA Certificate
\r\nThe FAZ is enabled via the FortiSandbox administrative GUI under Log & Report > Log Servers > Create New.
\r\nOn the FAZ, the FortiSandbox is added to the ADOM via the administrative GUI under Device Manager > Add Device.
\r\n\r\n
Certificate Revocation Lists (CRL) are configured as:
\r\n\r\n
Evaluated Configuration #2:
\r\n*** - All other configuration items identical to “Evaluated Configuration #1” shown above.
\r\n\r\n
Evaluated Configuration #3:
\r\n\r\n
*** - All other configuration items identical to “Evaluated Configuration #1” shown above.
\r\n\r\n
Evaluated Configuration #4:
\r\nThe evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. The TOE was evaluated against the criteria contained in the Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 5. The evaluation methodology used by the Evaluation Team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 Revision 5. The evaluation, completed in October 2025 was successful and provides a level of assurance that the TOE meets the Security Functional Requirements identified in the Security Target. This assurance comes from the performance of the work units associated with the Security Assurance Requirements. A detailed description of those Assurance Requirements as well as the details of how the product meets each of them can be found in the Security Target. A more detailed account of the evaluation assurance activities and the results obtained can be found in the Assurance Activity Report.
","environmental_strengths":"The TSF performs cryptographic operations as defined in the TSS section 7.2. This includes:
\r\nFor details on the cryptographic operations performed by the TOE and the certificates which govern those operations, please see [ST] section 7.2
\r\nThe TSF zeroizes all plaintext secret and private cryptographic keys and CSPs once they are no longer required.
\r\nThe TSF supports passwords consisting of alphanumeric and special characters. The TSF also allows administrators to set a minimum password length and support passwords with 15 characters or more.
\r\nThe TSF requires all administrative-users to authenticate before allowing the user to perform any actions other than viewing the warning banner. The TOE may take certain automatic actions prior to authenticating any user:
\r\nThese TSF operations occur before identification and authentication.
\r\nThe TOE provides management functionality over both local and remote interfaces.
\r\nThe local interface to a standalone hardware TOE is a dedicated physical port, which proxies direct console interface to the TOE’s CLI.
\r\nLocal access to a virtual TOE is through the ESXi console via URL.
\r\nFor both standalone hardware TOEs and virtual TOEs, the remote interfaces are an SSH connection to the CLI and a web GUI accessed over TLS/HTTPS.
\r\nThe TOE supports one default fully privileged user account, Admin, which corresponds to the PP defined Security Administrator. The Admin account has full privileges to all administrative functions.
\r\nThe TOE supports an additional role: “TOE Users”, who may be configured with none, some, or all of the permissions of a “Security Administrator”. This enables administrators to delegate some or all of the tasks necessary to manage the TOE to roles with lesser permissions. Collectively, all user accounts with administrative permissions are “administrators”.
\r\n\r\n
The TSF prevents the reading of all pre-shared keys, symmetric keys, private keys, and plaintext-passwords.
\r\nThe TOE provides reliable time stamps for itself.
\r\nThe TOE runs a suite of self-tests during initial start-up (on power on), and when cryptographic operations are performed to demonstrate the correct operation of the TSF.
\r\nThe TOE provides a means to verify firmware/software updates to the TOE using a digital signature mechanism prior to installing those updates.
\r\nThe TOE, for local interactive sessions, terminates the session after an Authorized Administrator-specified period of session inactivity.
\r\nThe TOE terminates a remote interactive session after an Authorized Administrator-configurable period of session inactivity.
\r\nThe TOE allows Administrator-initiated termination of the Administrator’s own interactive session.
\r\nBefore establishing an administrative user session, the TOE displays a Security Administrator-specified advisory notice and consent warning message regarding use of the TOE.
\r\nThe TOE is capable of using TLS to provide a trusted communication channel between itself and all authorized IT entities.
\r\nThe TOE permits the TSF, or the authorized IT entities to initiate communication via the trusted channel.
\r\nThe TOE is capable of using SSH or TLS/HTTPS to provide a communication path between itself and authorized remote Administrators.
\r\nThe TOE permits remote administrators to initiate communication via the trusted path.
\r\nThe TOE requires the use of the trusted path for initial administrator authentication and all remote administration actions.
","features":[{"id":1035,"feature_name":"Asymmetric Key Generation"},{"id":1029,"feature_name":"Auditing"},{"id":1040,"feature_name":"Certificate Validation"},{"id":1038,"feature_name":"Cryptograhic Hashing"},{"id":1036,"feature_name":"Cryptographic Key Establishment"},{"id":1037,"feature_name":"Cryptographic Signature Verification"},{"id":1034,"feature_name":"DRBG"},{"id":1028,"feature_name":"Flaw Remediation"},{"id":1031,"feature_name":"Key Destruction"},{"id":1039,"feature_name":"Keyed-hash message authentication"},{"id":1044,"feature_name":"SSH Client"},{"id":1032,"feature_name":"SSH Server"},{"id":1045,"feature_name":"TLS 1.2"},{"id":1046,"feature_name":"TLS 1.3"},{"id":1042,"feature_name":"TLS Client"},{"id":1043,"feature_name":"TLS Server without Mutual Authentication"}]}