Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Dell Validated Design for Manufacturing Edge - Design Guide with Claroty
Introduction Architecture System Design Accelerated Time to Value High Availability and Disaster Recovery Application Consolidation Cybersecurity Gateways Streaming Data Platform ISV Interoperability
Overview
Cross-ISV use cases
Sizing and Scaling Guidance Bill of Materials Additional Tasks Additional Information References

Cross-ISV use cases

Home > Edge > Manufacturing Edge > Guides > Dell Validated Design for Manufacturing Edge - Design Guide with Claroty > Cross-ISV use cases

Cross-ISV use cases


  • Claroty ISV interoperability


    CTD overview

    CTD functions by observing what happens on the network and learning from the data that it ingests. This is done either through passive means, like network traffic mirroring, or through active means like specifying a query to a specific device. Using these methods, CTD learns about the assets on the network and analyzes the data to provide information for what it learns to be normal behavior, potential risks, threats, or vulnerabilities.

    Description

    Interoperability between CTD and any of the ISVs in this solution have a common theme, to capture communications and understand what normal behavior is between the various ISV components. Also, CTD finds and presents any potential threats, risks, or vulnerability that could be presented as part of the ISV deployment or as part of its communication between other components on the network.

    Components

    • CTD Server—The main component of the CTD solution. This is where information is ultimately processed to help generate data about assets, networks, threats, risks, and vulnerabilities. CTD’s main method for collecting information is to ingest mirrored network traffic.
    • CTD Sensor—An optional component to CTD that helps ingest mirrored network traffic and forward that to the CTD Server over TCP/IP. This is especially useful when there are limitations in the network for mirroring traffic directly to CTD.
    • ISV component—Any component of an ISV solution that receives or sends data over the network. CTD’s goal is to ingest the inter- or intra-ISV communications.

    CTD-ISV integration

    The integration steps are outlined in the following sections and can apply to any ISV component and various protocols that are run over the network.


    Capture ISV traffic

    The goal of this procedure is to capture the communication to or from the ISV component. This is highly dependent on how the ISV and Claroty are deployed on the network. An example of this is whether the ISV and CTD are deployed on a vSphere cluster or whether one or the other is hosted on a bare metal server. In either case, the goal is to mirror traffic to and from each ISV component so that CTD can learn about each ISV component and establish a baseline of network communications for those ISV components.
    Note: For information about how to mirror data on a vSphere cluster, see CTD network deployment considerations.

    Confirm CTD is populated with ISV data.

    Once CTD successfully ingests the mirrored network traffic between the ISV components, users are able to see information on the ISV within CTD. There are two primary examples for this, assets and baselines. The first step is to confirm that CTD can identify the assets in the network communication flows and create entries for each of the assets. This can be confirmed in CTD by navigating to Visibility > Assets.

    Baselines can be described as the normal, expected behavior of network communications between assets. This involves the source and destination asset, as well as the network protocol that they are communicating over. In an example with XMPro, CTD ingested TLS 1.2 (HTTPS) communications between Stream Host and Data Stream. A baseline entry for this communication thread is seen in CTD when navigating to Investigation > Baseline. The following figure shows an example of CTD automatically creating baseline entries based on the traffic it ingested between XMPro components.
    Figure 83. Baseline communications detected by CTD between XMPro components
    Baseline communications detected by CTD between XMPro components
    Another example of detecting baseline communications can be specific per protocol. In an example where CTD captures OPC UA communications, the user can find the baseline within CTD and filter specifically for OPC UA. This can be done by navigating to Investigation > Baselines. Under Protocol, select the desired protocol, such as OPC UA, and the filter is added. The user is now displayed with baseline communications for only OPC UA traffic. Users can further filter by parameters such as source and destination addresses. This is useful when creating baseline rules, as seen in the next section.
    Figure 84. CTD detecting OPC UA communications between assets
    CTD detecting OPC UA communications between assets

    Create a baseline rule for normal ISV network communications

    • CTD is actively ingesting mirrored traffic between ISV components.
    • CTD is populated with ISV components or endpoints as assets and has identified baseline communications (see the previous section for details).
    Once CTD has identified ISV components as assets and has detected network communications between ISV components and endpoints, baseline rules can be created. These baseline rules alert users if there is a deviation from the rule. The following example configures CTD to generate an alert if there is a lack of communication between the defined assets for over five minutes.
    1. Navigate to Investigation > Baselines.
    2. Using the previous section as an example, filter for the desired communication thread (for example, by using protocol or source/destination addresses).
    3. Select the baseline entry by checking the box, then click the cogwheel icon to create a rule.
    4. Fill out the information in the CREATE BASELINE RULE pop-up.
      1. Name: Provide a descriptive name for the rule
      2. Active Until: Select the date
      3. Filter Type: Inactive for
      4. Inactive for: <Hours/Minutes/Seconds>
      Figure 85. Settings to create baseline rule in CTD
      Settings to create baseline rule in CTD
    5. Click Save.
    6. To confirm the rule is created, navigate to Threat Detection > Rules > Baseline Rules. There is an entry for the new rule.
      Figure 86. Baseline rule created within CTD
      Baseline rule created within CTD
    The procedure above creates a rule within CTD that triggers an alert if CTD does not detect OPC-UA read tag communications between the source and destination address for five minutes. This example can be used for any protocol or ISV combination to help define baselines, as recommended by CTD, to help create rules to alert users if there are deviations from normal operations within the OT network. The following figure shows an example of when the ISV rule is violated and an alert is generated on CTD.
    Figure 87. Example of baseline rule violation alert on CTD
    Example of baseline rule violation alert on CTD

    Set up Zone Rules

    Similar to baseline rules, CTD can automatically generate and recommend zone rules to the user. Navigate to Threat Detection > Rules > Zone Rules to see a list of the automatically generated zone rules. The following figure shows an example of automatically generated zone rules between OPC server and OPC client.
    Figure 88. Example of CTD zone rules for OPC UA traffic
    Example of CTD zone rules for OPC UA traffic
    1. Navigate to Threat Detection > Rules > Zone Rules.
    2. Select a zone rule to implement by clicking the Validate button.
    These two steps effectively tell Claroty that the communication between these two zones is allowed over the specified parameters. Alternatively, users can create new rules or edit existing zone rules. For example, the ACTION of a rule can be changed from Allow to Alert. If a zone rule is set to Alert, then if there is a hit on the zone rule, the user is alerted on CTD. This is another method for alerting users of any suspicious networking communications.

    Firewall integration

    CTD can be thought of as an Intrusion Detection System (IDS), where it passively listens to network traffic and produces alerts based on any potential threats seen on the network. CTD allows for integration with firewalls on the network to push its data to the firewall, and this data can be used to create firewall rules on the network. Users can then accept the CTD rules on the firewall, which helps actively prevent violations of the rules created within CTD. More information about this function can be found in Integrate Palo Alto firewall.


    SRA overview

    SRA provides a more secure solution for remote management in industrial networks. SRA provides various features, such as granular access controls, that allow for strict control of who can access what remote endpoint, at what time, and for how long. SRA provides additional capabilities like session recordings and session monitoring to help make sure current and past remote session activities are not being misused.

    Description

    Interoperability between SRA and any of the ISVs in this solution have a common theme, to provide secure remote access management to the ISV hosts. SRA provides support for multiple protocols for remote management such as SSH, RDP, and web interface access. The combination of these protocols allows for remote management of the different ISV solutions and components.

    Components

    • SRA SAC—The management component of the SRA solution. This is where administrators create rules and remote sessions, and where end users can initiate remote sessions.
    • SRA Site—This is the component that sits in the IDMZ or OT network and initiates the actual connection to the target server.
    • ISV component—The target for remote sessions from SRA. ISVs can be accessed or managed through their host operating system or through a web interface. SRA allows support for both.

    SRA-ISV integration

    The following examples outline the different types of remote sessions that can be created, which can then be used with an ISV in this solution.

    Managing SRA

    Steps for creating remote sessions and other functionality can be referenced in SRA remote session control. Use these steps as guidance to create the appropriate sessions and to use other important features of SRA.

    XMPro

    XMPro can be managed either through the host Windows operating system or through its web interface. SRA can support remote connectivity to both. For the XMPro Windows host, users can create an RDP session. If a user needs to manage XMPro from its web interface, for example if a remote user needs to add a new Data Stream, then an SRA session can be created specifically for the XMPro web interface.

    Cognex

    Cognex tools are run and managed on a Windows operating system. Creating an RDP session from SRA to the Cognex host or hosts supports the management of the tools and host operating system for Cognex. Avoid using shared accounts in both SRA and when the user RDPs to the Windows operating system.

    Telit Cinterion

    Telit deviceWISE components can be hosted on various operating systems. The primary examples are Windows or Linux-based systems, for which SRA can support connectivity to both. For Windows deployments, users can leverage RDP connections to manage deviceWISE components. Linux supports RDP packages which allow RDP connections, or users can leverage VNC, as SRA supports this a well. Finally, SRA can also support SSH connections if required.

    Litmus

    Litmus runs its own operating system, so access is likely to be kept to the Litmus web interface. Users on SRA can create a remote session to specified websites. This allows users to remote into the OT environment and only be allowed to access the Litmus web UI as needed. Litmus Edge Manager provides access to the OS using SSH, or it can be managed using a web interface such as Litmus Edge.

    SDP

    SDP hosted on Linux environments can be managed through SSH access (this gives users the ability to, for example, run Kubernetes administration commands). For SDP UI or Keycloak management, users can create a web access session which limits them to only access a web browser to manage SDP.