It can be difficult to keep up with cybersecurity threats that continuously grow in number and evolve in complexity. Additionally, most security tools are not purpose-built to understand OT networks and protocols, making it easier to miss potential risks, vulnerabilities, or threats. With Claroty’s solutions, end users realize an accelerated time to value (ATV) for securing their industrial environments. Claroty’s wide array of options to obtain network information, respond to network events, and their intuitive user interface make it easier and faster for users to understand their OT networks and to realize and act on what they should prioritize.

Continuous Threat Detection (CTD) makes it easy for users to see what is going on their network by giving users an overall picture of their network and to identify what is most urgent to address and how. Each of the following sections goes over some of the features within CTD and how they are used to accelerate time to value for a more robust security posture.

CTD makes it easy for users to understand the overall risk of their network at a high level, helping end users realize where they are at with their cybersecurity posture. One component of this is the Hygiene Score. This is a widget that displays the cumulative risk level as seen by the system through insights. Furthermore, this score is a combination of indicators seen by CTD such as CVEs, anomalies, and number of critical assets. The lower the score, the more susceptible the network is to potential compromising cybersecurity events. Insights are important to ATV, as they are a cumulation of events to help end users address what is most critical to address first, instead of combing through a potentially large number of events. Finally, CTD offers a feature to point out potential attack vectors. The system automatically detects potential flaws in the network that can lead to possible compromises and displays it for the user to easily understand and address.

CTD offers multiple ways to deploy the solution on the network to make it quick and easy to start to send data to the platform. CTD and its components (CTD Sensor and Enterprise Management Console, or EMC) can be deployed on bare metal servers or as virtual machines (VMs). Furthermore, CTD can be installed using its own ClarotyOS Operating System or through an installer for systems running (as of this writing) RHEL or CentOS 7.9. All three CTD components are configured after the CTD installer or ClarotyOS installation are run. When deploying as a VM, users can create a Virtual Machine Template on vSphere. This is beneficial if new CTD instances need to be quickly spun up. An example would be if a new segment to the factory is added, users can create a new VM from the template and quickly deploy CTD dedicated to the new segment to handle the new scale.

The CTD EMC component is critical in large-scale deployments with many CTD servers. Instead of individually managing each CTD server, an EMC can be deployed to orchestrate the management of all CTD servers on the organization’s network or networks. This provides a scalable way to manage the lifecycle of the CTD servers (for example, upgrades and updates). Additionally, the EMC contains all data from all connected CTD servers, giving the user a holistic view of their entire organizational cybersecurity posture from one place.

An important aspect of CTD is to ingest data from the network to gain as much visibility as possible into the network. Wider visibility leads to a better understanding of the whole picture, as well as helping to ensure that events are not missed by the platform. CTD provides a wide array of options to ingest data:

• Passive network monitoring—End users must configure the network devices (for example, switches or virtual switches in vSphere) to mirror network traffic to the CTD instance. CTD gives the user the option to mirror traffic directly to the CTD Server to a CTD Sensor. CTD Sensors connect to the CTD Server over TCP/IP. Sensors provide the flexibility needed in environments that may be limited on how to mirror network traffic across the network.
• Active querying—Aside from providing regular network scanning capabilities, CTD includes special queries for various device types. For instance, CTD has built-in queries for PLCs to gain more information, and to not cause an adverse event on the PLC device that might not be able to handle regular IT traffic. Active queries also include Windows and vSphere targets, showing the wide array of options to gain more information.
• Project file parsing—Also known as AppDB on CTD, this allow users to either directly upload a PLC project file (configuration file) or to specify a directory where these project files are maintained. CTD can parse these files and glean further information about the assets used on the network, like detecting which rack slot is used for what on the PLC. Additionally, this enhances OT event detection in scenarios where a project file might have an unplanned change.
• PCAPS—Packet Captures (PCAPS) are files containing network packet data. CTD allows users to replay PCAP files so that CTD can ingest the network data from that file and add it to its existing dataset. This provides further flexibility for how to ingest data into CTD.
• Claroty Edge—This can be configured to directly send traffic to CTD. Claroty Edge is run on Windows-based hosts. Claroty Edge can either connect over TCP/IP to the target CTD server, or it can export its findings that can then be imported into CTD offline.

The Secure Remote Access (SRA) solution provides a quick way for users to set up a secure remote access solution for their industrial networks. Not only is it quick and intuitive to configure target servers for remote sessions, but it is also clearly defines the granular access controls to limit who can access what and when.

Deployment of SRA is done using an installer on RHEL or CentOS 7.9 hosts (as of this writing). SRA can be deployed on bare metal or as a VM. Once the host OS is preconfigured to support the SRA software, and the installer is run, the user must fill out a few simple prompts to finish the configuration. After preparation of the CentOS host, but prior to running the installation scripts, users may create a VM template on vSphere of the host OS. This allows users to create new SRA SAC or SRA Site instances if the environment scales.

In typical deployments, end users interface with the easy-to-use SRA SAC user interface, where they have a logon and are presented with the remote sessions that they are allowed to initiate. To provide even more flexibility to end users, SRA provides an App Tunnel Client. The tunneling client works as a VPN so that users can initiate remote sessions from their own host, and in a secure way (app tunnel client is limited to a defined access list in its configuration file).

To accelerate time to value for end users, SRA provides several protocols, listed below, for different types of remote sessions. These options allow flexibility and less required network configurations or changes. Additionally, these options also allow for more granular access control where users might want to allow only SSH access, as opposed to having to use VNC to run CLI commands.

The following is a list of remote protocols or session types supported by SRA:

• RDP
• VNC
• Telnet
• SSH
• Web (HTTP/HTTPS)

xDome provides ATV through minimal configuration requirements along with deployment flexibility. xDome is a SaaS solution, meaning that the analysis of the data is processed in the cloud. Users do not have to worry about deployment of the analysis server, and only need to plan for the deployment of collectors on their networks. Collectors are responsible for the data collection in the xDome architecture. Once the collectors are deployed and configured, users start to see value from their data.

xDome provides collectors, which are responsible for collecting network data and sending the ingested data to the analysis server over a tunneled connection. Collectors can be deployed on server hardware or as a VM. Like CTD servers and CTD Sensors, collectors need the network configured to mirror traffic to the collector (for example, by configuring SPAN). Once this configuration is completed, and assuming the collector can reach the analysis server (dependent on geographic location), users can gain value from their xDome instance. In addition to passive monitoring, the collectors allow integrations with onsite software and tools, as described in the section below.

xDome provides end users with multiple options to ingest data to provide the analysis server with effective visibility into the OT network. The combination of these options gives users the flexibility to quickly deploy and configure the system to get the most out of the network data:

• Passive network monitoring—This mirrors network data to a xDome collector. xDome has DPI capabilities that can gain a deeper understanding of the data. This is the main method for getting data into xDome. A large portion of visibility is handled by simply integrating with the core switch of the network.
• Integration—xDome provides the option to integrate with existing network devices and protocols. Users configure the integrations from the analysis server, which initiates the actual integration from the on-site collector. Integration can be done with infrastructure services or devices. Examples include DHCP, Active Directory, NetFlow, SNMP, and vCenter.
• Claroty Edge—This can be configured to send traffic directly to xDome. Claroty Edge is run on a Windows-based host and then connects over TCP/IP to the target xDome instance. Claroty Edge provides further insight into the network by gaining in-depth information from the Windows host and information about the host’s local subnet.
• NetFlow—This is a protocol for monitoring and collecting IP traffic information that xDome can ingest. An example is when NetFlow runs on a switch on the network, and can be configured to send the data to an xDome component.