Forescout eyeInspect’s primary purpose is to help reduce risk, automate compliance, and optimize threat analysis for industrial operations management technology within a network. The Command Center provides the main interface for management of eyeInspect, including the ability to manage eyeInspect configuration, manage Sensors, and perform analytics on collected device and threat data. Meanwhile, eyeInspect Sensor(s) receive device information gathered from within the network and send it to the Command Center for analysis. A Forescout eyeInspect deployment consists of one Command Center and at least one Sensor. The Command Center and the Sensor(s) work together to provide visibility and an understanding of security posture for Industrial Control System and Supervisory Control and Data Acquisition (ICS/SCADA) networks.
","evaluation_configuration":"The TOE is Forescout eyeInspect v5.2 which consists of a Command Center and one or more Sensors. The TOE contains the following models for each TOE component:
\r\nThe minimum configuration for a deployment of Forescout eyeInspect is one Command Center and one Sensor. Only one Command Center can be deployed as part of the operational configuration. Including additional Sensors within a deployment of Forescout eyeInspect as part of the operational configuration will not affect the validity of the functional claims made within the Common Criteria certification.
\r\nThe following lists components and applications in the environment that the TOE relies upon in order to function properly:
\r\nThe evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. Forescout eyeInspect v5.2 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 product, when installed and configured per the instructions provided in the preparative guidance, satisfies all of the security functional requirements stated in the Forescout eyeInspect v5.2 Security Target Version 1.0 as scoped by the NDcPP2.2E. The evaluation underwent CCEVS Validator review. The evaluation was completed in December 2024. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report, CCEVS-VR-VID11499-2024 prepared by CCEVS.
","environmental_strengths":"Security Audit
\r\nThe TOE contains mechanisms to generate audit data to record predefined events for all components of the TOE. Both the Command Center and the Sensor store audit logs locally. The TOE supports forwarding audit records to an external audit server at a predefined frequency. There is no direct connection between the Sensors and the remote audit server. Therefore, audit events from the Sensors are first forwarded to the Command Center, and then forwarded to the remote audit server by the Command Center. The Command Center also forwards its audit records directly to the external audit server. In the evaluated configuration, the audit data is securely transmitted to the audit server using a SSHv2 communication channel.
\r\nCryptographic Support
\r\nThe TOE provides cryptography in support of TLS (v1.2), HTTPS, and SSH trusted communications. The Command Center utilizes Bouncy Castle for TLS and HTTPS communications, and OpenSSL for SSH communications. The Sensor utilizes OpenSSL for TLS and SSH communication. The TOE destroys keys when no longer needed.
\r\nCommunication
\r\nInitial TLS communications between TOE components does not occur until the Sensor is configured and enabled by the Security Administrator. Once enabled the Sensor application will send a request for enrollment, via TLS, to the configured Command Center, where the Security Administer must approve before full communications are established.
\r\nIdentification and Authentication
\r\nThe TSF provides a configurable number of maximum consecutive authentication failures that are permitted by a user. Once this number has been met, the account is locked for a configurable time interval or until a Security Administrator manually unlocks the account. Additionally, a Security Administrator can define the minimum password length. The displaying of a pre-authentication warning banner is the only function available prior to user authenticating.
\r\nThe TOE provides a native password authentication mechanism for Web GUI and CLI users. The inter-TOE TLS client functionality on the Sensor performs the validation, without revocation checking, of the presented X.509v3 certificates from the Command Center server.
\r\nSecurity Management
\r\nThe TOE uses role-based access control to prevent unauthorized management of and access to TSF data. The TOE provides a Security Administrator role that can be assigned to a user which provides the ability to administer the TOE locally and remotely.
\r\nProtection of the TSF
\r\nThe TOE ensures the security and integrity of all data that is stored locally and accessed locally or remotely. User authentication passwords are not stored in plaintext. The Security Administrator is required to manually initiate the update process on the Command Center and the Sensors; as the TOE does not support automatic updates. The TOE automatically verifies the digital signature of the software update prior to installation and if the digital signature is found to be invalid, the update is not installed. The current executing version of the TOE software is displayed upon login. The TOE implements a self-testing mechanism that is automatically executed upon startup. The TOE provides its own time via the underlying OS’s internal clock and a Security Administrator has the ability to manually set the time.
\r\nTOE Access
\r\nThe TOE displays a configurable warning banner prior to user authentication. Remote and local sessions are terminated after an administrator-configurable time period of inactivity. Users are allowed to terminate their own interactive session. Once a session has been terminated, the TOE requires the user to re-authenticate to establish a new session.
\r\nTrusted Path/Channels
\r\nSecurity Administrators can remotely manage the Command Center through an SSH channel to access the CLI or HTTPS to access the Web GUI. The Command Center uses a SSH connection to the audit server for remote audit storage.
\r\nSecurity administrators can remotely manage the Sensor through an SSH channel to access the CLI. The Sensor communicates with the Command Center via secure TLS channels.
","features":[{"id":778,"feature_name":"Asymmetric Key Generation"},{"id":773,"feature_name":"Auditing"},{"id":800,"feature_name":"Certificate Authentication"},{"id":785,"feature_name":"Certificate Validation"},{"id":782,"feature_name":"Cryptographic Hashing"},{"id":779,"feature_name":"Cryptographic Key Establishment"},{"id":781,"feature_name":"Cryptographic Signature Verification"},{"id":775,"feature_name":"DRBG"},{"id":797,"feature_name":"HTTPS Client"},{"id":1557,"feature_name":"HTTPS Server without Mutual Authentication"},{"id":774,"feature_name":"Key Destruction"},{"id":783,"feature_name":"Keyed-hash message authentication"},{"id":794,"feature_name":"SSH Client"},{"id":795,"feature_name":"SSH Server"},{"id":789,"feature_name":"TLS 1.2"},{"id":790,"feature_name":"TLS Client"},{"id":792,"feature_name":"TLS Server without Mutual Authentication"}]}