Sizing and scalability for Claroty has been validated for CTD and SRA. Each component within the respective product has been validated for the appropriate sizing (small, medium, and large). Sizing and scalability have been tested based on the following considerations:

CTD:

• Amount of traffic received in Megabits per second (Mbps).
• Content of the network traffic, like number of assets or information contained about each asset.
• Number of connected CTD Servers to EMC with each actively ingesting network traffic at specified network throughput rates.

SRA:

• Number of connected Sites or target servers.
• Number of concurrent sessions (opened remote sessions per SRA component).

Use the parameters specified below to help size each type of deployment. Sizing specifications are based off the Claroty resource specification guidance at the time of this writing. Success criteria for all the tests below is based on the CPU and memory utilization along with read/write latencies falling within an acceptable threshold. Metrics were collected for average network throughput and read/writes per second to verify tests (for example, network throughput increased in higher sizing tests). Storage recommendations are based on Claroty’s recommended specifications in their official documentation.

CTD sizing guidance is broken up into the three different CTD components: CTD Server, EMC, and CTD Sensor. See the Claroty CTD Architecture Guide for official hardware requirements and other deployment considerations.

Testing was executed by replaying packet captures at the specified network throughput rate, as seen in the following table. The PCAP contained data on a mix of approximately 60 IT and OT assets total (as classified by CTD). CTD was confirmed to generate useful data from the packet captures, such as assets, risks, vulnerabilities, and attack vector. In summary, each size could handle the specified level of network throughput at an acceptable resource utilization rate.

The CTD Sensor sizing specifications were validated by connecting the CTD Sensor to a CTD Server instance and replaying a packet capture at the specified network throughput rate as seen in the following table. This was the same packet capture file used in the CTD Server test. It was confirmed that the CTD Sensor was successfully forwarding the data to the connected CTD server by validating that the CTD server was populated with the same risks, assets, vulnerabilities, and so on. In summary, each size could handle the specified level of network throughput at an acceptable resource utilization rate.

The EMC sizing specifications were validated by connecting the specified number of CTD Servers as shown in the following table. Each CTD Server was receiving 50 Mbps of traffic through the same method as described in the CTD Server test. EMC was validated by observing data coming in from the CTD Servers and ensuring the CTD Servers remained connected throughout the duration of the test. In summary, each size could handle the specified number of assets at an acceptable resource utilization rate.

SRA sizing guidance is broken up into the two different SRA components, SRA SAC and SRA Site. Each was configured for testing purposes only, to help simulate specific workloads per component. Sizing can also depend on the type of remote session (example: RDP as opposed to SSH), where a graphical remote session takes more resources. The testing described in the following section was done by initiating RDP sessions. See the Claroty SRA Architecture Guide for official hardware requirements and other deployment considerations.

SRA SAC performance results were validated based on the number of connected SRA Sites and the number of concurrent remote sessions. More specifically, concurrent sessions define a user having a separate web session open to the SRA SAC and starting a remote session using an SRA Site. In the small sizing test, multiple remote sessions were open for one or more sites. For the medium and large test, there was a one-to-one relationship between SRA Site and remote session. In other words, each remote session used a unique SRA Site.

SRA Site testing was done based on the number of connected target servers (remote session endpoints) and number of concurrent sessions initiated from that Site under test. This can be thought of as the same test setup as the SRA SAC, but instead, remote sessions are initiated directly from the SRA Site instead of the SRA SAC. This helps measure how the SRA Site handles load based on the number of sessions its handling.

The recommended scaling approach is to start small and expand as required by network changes. Network changes, for example, like adding new assets to the network or creating new connections between assets. As new assets or new communications are created on the network, network load may increase and more information about the network can be learned and processed by CTD. For SRA scalability, new assets/devices or network segments may require more target servers (remote session endpoints).

More network data can mean more network throughput and more information for CTD to process. It is important to understand the network where CTD is being deployed, including what are the assets/devices and what is the switching and routing architecture of the network. This is important because CTD Sensors and CTD Servers can handle loads based on a defined network throughput rate. Other considerations are whether a CTD Server will be doing processing on its own or if it has connected CTD Sensors which help offload some of that processing.

Another consideration for scalability is EMC. This is useful in scenarios where end users have multiple CTD Servers deployed across their networks. Gather the number of total CTD Servers (and corresponding CTD Sensors) and compare to the sizing guidance to make sure EMC has enough resources to handle the current load and consider some room for any new CTD deployments.

Like CTD, the SRA scalability depends on the network, especially when it comes to the number of remote session endpoints the SRA solution is intended to support. It can be helpful to start from the bottom and build up when thinking about scaling. Count how many target servers in total need to be supported per network segment that an SRA Site supports. Consider how many sessions the Site may need to support simultaneously. These numbers help to choose the appropriate SRA Site, and they can show how much room there is to grow per sizing category if case new remote sessions are required.

As the sizing for Sites is defined, work up to the SRA SAC which connects to the Sites. Count the number of connected Sites and potential concurrent number of sessions (for example: the number of individual users connecting all at once to different target servers). In both scenarios, Site and SAC sizing, leave room for growth. If the network scales, users can deploy new SRA SAC and SRA Site groupings.