Claroty CTD v4.8.0 Reference Guide 20230329

Continuous Threat
Detection (CTD) Reference

Guide
CTD Version 4.8.0
Confidential & Proprietary | Copyright © 2023 Claroty Ltd. All rights reserved
29-Mar-2023
CTD Reference Guide
TABLE OF CONTENTS
1. Introduction ...................................................................................................................... 7
2. Threat Detection ............................................................................................................... 8
2.1. Detection Engines .................................................................................................. 8
2.1.1. Behavior Anomalies Detector ..................................................................... 8
2.1.2. Signature Based Detector ........................................................................... 9
2.1.3. Security Behavioural Pattern Detector ......................................................... 9
2.1.4. Operational Behavioural Pattern Detector ................................................... 9
2.1.5. Rule-Based Threat Detector ........................................................................ 9
2.2. Events, Alerts, and Stories ...................................................................................... 9
2.3. Alerts Table .......................................................................................................... 10
2.3.1. .................................................................................................................. 10
2.4. Alert Resolution Options ...................................................................................... 12
2.4.1. Approve .................................................................................................... 13
2.4.2. Archive ...................................................................................................... 13
2.4.3. Ignore ....................................................................................................... 13
2.4.4. Approve Selected ...................................................................................... 13
2.4.5. Approve All ................................................................................................ 13
2.4.6. Acknowledge ............................................................................................. 13
2.4.7. Approve & Update Policy ........................................................................... 13
2.5. Managing Integrity Alerts ..................................................................................... 14
2.5.1. Asset Information Change ......................................................................... 14
2.5.2. Baseline Rule ............................................................................................. 15
2.5.3. Configuration Download ............................................................................ 16
2.5.4. Configuration Upload ................................................................................ 17
2.5.5. Firmware Download .................................................................................. 18
2.5.6. Mode Change ............................................................................................ 19
2.5.7. Monitor / Debug Mode .............................................................................. 21
2.5.8. New Asset ................................................................................................. 22
2.5.9. New Conflict Asset ..................................................................................... 23
2.5.10. Online Edit .............................................................................................. 24
2.5.11. Policy Rule Match .................................................................................... 25
2.5.12. Policy Violation ........................................................................................ 25
2.5.13. Settings Change ....................................................................................... 27
2.6. Managing Security Alerts ...................................................................................... 27
2.6.1. DCS Configuration Change Alert ................................................................ 28
2.6.2. Denial of Service ........................................................................................ 29
2.6.3. Failed Login ............................................................................................... 30
2.6.4. File System Change ................................................................................... 31
2.6.5. Host Scan .................................................................................................. 32
2.6.6. Known Threat Alerts .................................................................................. 33
2.6.7. Man-in-the-Middle Attack .......................................................................... 33
2.6.8. Memory Reset ........................................................................................... 34
2.6.9. Port Scan ................................................................................................... 35
2.6.10. Suspicious Activity ................................................................................... 36
2.6.11. Suspicious File Transfer ........................................................................... 37
29-Mar-2023 CTD Version 4.8.0 Page 2 of 227

CTD Reference Guide
3. Insights ........................................................................................................................... 38
3.1. Risk Management ................................................................................................ 38
3.1.1. Assets Accessed SMB Shares ..................................................................... 38
3.1.2. Assets Accessing SMB Pipes ....................................................................... 38
3.1.3. Assets with partial connection to the internet ............................................ 38
3.1.4. Clients Remotely Managed ........................................................................ 38
3.1.5. DHCP Clients ............................................................................................. 38
3.1.6. Data Acquisition Write (Operated PLCs) ..................................................... 39
3.1.7. End of Life (EoL) Assets .............................................................................. 39
3.1.8. Files Downloaded (clients) ......................................................................... 40
3.1.9. Highly Connected Assets ........................................................................... 41
3.1.10. Managed PLCs (by Rockwell users) .......................................................... 41
3.1.11. Multiple Interfaces ................................................................................... 41
3.1.12. Open Ports .............................................................................................. 41
3.1.13. PLCs exposed to program changes .......................................................... 41
3.1.14. PLCs exposed to Triton ............................................................................ 41
3.1.15. PLCs Talking IT Protocol ........................................................................... 42
3.1.16. Privileged Operations (Operated PLCs) .................................................... 42
3.1.17. Remote Desktop Application ................................................................... 42
3.1.18. SMBv1 Negotiate ..................................................................................... 42
3.1.19. SNMP Querying Assets ............................................................................ 42
3.1.20. Talking with External IPs .......................................................................... 42
3.1.21. Talking with Ghost Assets ........................................................................ 42
3.1.22. Top Risky Assets ...................................................................................... 42
3.1.23. Unsecured Protocols ............................................................................... 42
3.1.24. Unsupported OS ...................................................................................... 43
3.1.25. USB Devices Connected to Assets ............................................................ 43
3.1.26. Using Unencrypted & Weak Passwords .................................................... 43
3.1.27. Web Servers ............................................................................................ 43
3.2. Vulnerability Management ................................................................................... 43
3.2.1. Full Match CVEs ......................................................................................... 44
3.2.2. Model Match CVEs ..................................................................................... 44
3.2.3. Program Match CVEs ................................................................................. 44
3.2.4. Vendor Match CVEs ................................................................................... 45
3.2.5. Windows CVEs ........................................................................................... 45
3.2.6. Windows CVEs Full Match .......................................................................... 46
3.3. Updating Insight Statuses ..................................................................................... 46
3.4. Supported Vendor List for CVE Matching .............................................................. 47
4. Discovery Methods ......................................................................................................... 48
4.1. Active Detection ................................................................................................... 48
4.1.1. Changes in Alerting from Passive Behavior ................................................ 48
4.1.2. Baselines Generated from Active Detection ............................................... 48
4.1.3. Profiles ...................................................................................................... 48
4.1.4. Queries ..................................................................................................... 58
4.1.5. Discovery Tasks ....................................................................................... 114
4.2. IoT Asset Management and Monitoring .............................................................. 133

CTD Reference Guide
4.2.1. IoT Matchers Configuration ..................................................................... 133

4.2.2. IoT Assets Information ............................................................................. 140
4.3. Configuring Application Database (App DB) Sources ........................................... 140
4.3.1. App DB: One Time Parsing ....................................................................... 141
4.3.2. App DB: Recurring Parsing ....................................................................... 143
4.3.3. Supported App DB Tools ......................................................................... 145
4.4. Importing Assets via CSV .................................................................................... 147
4.4.1. Prerequisites ........................................................................................... 147
4.4.2. Importing Assets ..................................................................................... 148
4.4.3. Table & Guidelines for Structuring the CSV Import File ............................. 151
4.4.4. CSV Import Guidelines ............................................................................. 153
4.4.5. Summary Results .................................................................................... 156
4.5. Exporting Assets to CSV ...................................................................................... 156
5. Upgrade Permission Mapping ....................................................................................... 159
6. CTD Required Open Ports ............................................................................................. 160
6.1. Required Firewall Rules for EMC Connectivity ..................................................... 160
6.2. Required Firewall Rules for CTD Site Connectivity ............................................... 160
6.3. Required Firewall Rules for Sensor Connectivity ................................................. 160
6.4. Required Firewall Rules for Edge Connectivity .................................................... 161
6.5. Required Firewall Rules for CTD Site Connectivity ............................................... 160
6.6. Required Firewall Rules for Sensor Connectivity ................................................. 160
6.7. Required Firewall Rules for Edge Connectivity .................................................... 161
7. System Boundaries ....................................................................................................... 162
7.1. Data Collection Boundaries Status (only Admin) ................................................. 162
7.1.1. Steps to take when Assets reach boundary .............................................. 163
7.1.2. Steps to take when Baselines reach boundary ......................................... 163
7.2. Supported Browsers .......................................................................................... 163
7.3. Baseline, Asset, and Alert Retention ................................................................... 163
7.4. Number of Sensors ............................................................................................ 164
7.5. DNS Record and Cleanup Thresholds ................................................................. 164
8. Supported Operating Systems - Passive ........................................................................ 165
9. Supported Passive Protocols ......................................................................................... 166
10. Data Encryption and Password Management in CTD ................................................... 172
11. Services and Dependencies ......................................................................................... 173
11.1. CTD Running Services ....................................................................................... 173
11.2. Dependent Services ......................................................................................... 173
12. Supported Activity Types ............................................................................................. 174
13. Claroty Syslog Specification ......................................................................................... 175
13.1. Introduction ..................................................................................................... 175
13.2. CEF Format ....................................................................................................... 175
13.2.1. CEF Header ............................................................................................ 176
13.2.2. CEF Extensions ...................................................................................... 177
13.2.3. Frequency and Timing of Syslog Logging ................................................ 177
13.2.4. Alert Specific Keys - CEF Format ............................................................. 177
13.2.5. Events Specific Keys - CEF Format .......................................................... 180
13.2.6. Insights - CEF Format ............................................................................. 183

CTD Reference Guide
13.3. CEF (Legacy) Format ......................................................................................... 186

13.3.1. Syslog Alert Examples ............................................................................ 186
13.3.2. Syslog Event Examples ........................................................................... 204
13.3.3. Syslog New Baseline Example ................................................................ 208
13.3.4. Syslog Sniffer Status Check Example ...................................................... 210
13.3.5. Health Check Monitoring Example ......................................................... 212
13.3.6. Health Check Worker List ....................................................................... 215
14. Supported Reports ...................................................................................................... 217
15. Supported Asset Types ................................................................................................ 218
15.1. Purdue Level Classifications of Asset Types ...................................................... 218
15.2. Asset Classes .................................................................................................... 220
16. Terminology ................................................................................................................ 223

CTD Reference Guide
To view the most updated version of this document, visit docs.claroty.com

CTD Reference Guide Introduction
1. Introduction
This document provides reference material for Claroty’s Continuous Threat Detection (CTD) V4.8.0
and supplements the CTD User Guide.

CTD Reference Guide Threat Detection
2. Threat Detection
Threat detection in CTD provides alerts that indicate a potential threat in the environment and
tools for managing those threats. There are the two categories of alerts:
• Integrity Alerts – a process integrity alert is not necessarily malicious but has an impact on the
control of the process and should be investigated. These are events that regularly happen as a
part of approved engineering and maintenance tasks, but if they happen outside of this, require
attention. The Process Integrity Alerts generally appear while in Operational Mode.
• Security Alerts – security alerts represent malicious behavior and are not generally supposed to
occur within the OT environment and should always be evaluated at the highest priority.
2.1. Detection Engines

CTD detects threats with the following flow:
1. Sniffs packets from the network

2. Performs common IT protocols dissection (e.g. UDP, TCP, and HTTP)
3. Performs OT protocols dissection (e.g. CIP, S7, and Modbus)
4. Processes information which passes through various detection engines, including information
collected using AppDB and Active Queries
5. Generates events from detection engines
6. Quantifies and qualifies events, which determines whether that event will be considered a
security alert
Claroty CTD has five detection engines that detect various threats or anomalies based on their
role:
Figure 1. Claroty CTD has five detection engines
2.1.1. BEHAVIOR ANOMALIES DETECTOR

This detection engine alerts on policy violations. Policies are generated from the protocols and
communications the system identified. Policy violations are behaviors that do not match the
collection of traffic patterns that CTD has machine learned.

CTD Reference Guide Events, Alerts, and Stories
Generated alerts focus the operator’s attention on: network changes, vulnerabilities, threats, zero-
day exploits, malware, attacks in the ciphered traffic, resource misuse or misconfigurations.
2.1.2. SIGNATURE BASED DETECTOR

This detection engine works on Yara and network traffic rules. CTD’s database also includes sig-
natures provided by Claroty’s research team for zero-day vulnerabilities that are under formal
disclosure. Network traffic rules allow users to create their own rules based on Snort rules and
manually disable or enable existing signatures.
2.1.3. SECURITY BEHAVIOURAL PATTERN DETECTOR

This detection engine detects common attack techniques, such as man-in-the-middle (MITM) at-
tacks, brute force attacks, port and network scans, and more. Moreover, it also alerts on IT security
patterns such as TAG/Address scans.
2.1.4. OPERATIONAL BEHAVIOURAL PATTERN DETECTOR

This detection engine focuses on sensitive OT-related activity such as configuration downloads /
uploads, mode changes on controllers, key state changes, and firmware updates in addition to
privileged commands to the controllers.
This detector is designed to identify OT-targeted attacks and sophisticated payloads, by flagging
OT operations that occur within the network over any proprietary OT protocol. By identifying and
reporting such activities, operators can make an informed decision and determine the next steps
based on their Management of Change process.
2.1.5. RULE-BASED THREAT DETECTOR

This detection engine alerts on the customized rules that operators have configured to target
specific events. For example, operators can employ rules to flag values out of range or specific
communication that is considered suspicious.
2.2. Events, Alerts, and Stories

Events
• Events are the foundation of the CTD’s threat detection module. They are conversations or
activities logged by various engines in CTD, which are then categorized as either risky (Alert or
OT Alert) or non-risky (Non-Risky Change or an OT Operation) events.
• Events quantified and qualified as risky result in an Alert, which can be viewed in the Alert
screen.
Alerts
• Qualified and quantified event or chain of events which are based on various risk factors.
• Further categorized as either Security Alerts or Integrity Alerts depending on the nature of the
alert.
• Alerts are scored from a scale of 0 through 100. Actual alert score can be higher than 100
depending on the sum of various indicator scores, however it is capped at max 100.
Stories

CTD Reference Guide Alerts Table
• CTD Correlates alerts and combines them into stories.

• Stories are a set of interrelated alerts.
• Stories establish context and understanding of associated activities.
Figure 2. Events, Alerts, and Stories
2.3. Alerts Table
This table summarizes all the alerts currently available in CTD, including their meaning, type, and
resolution options in Training Mode and Operational Mode.
It also lists the following:
• Mitre Info - Whether the alert is mapped to MITRE ATT&CK® for ICS Tactics and Techniques
• Capsaver - Whether a PCAP file is saved for the alert
• Retention Period - How long the alert is saved in the system
Alert Name Description Alert Resolution Resolution MI- Cap- Reten-

Type Options in Options in TRE sav- tion Pe-
Training Operation- Info er riod
Mode al Mode
Asset Infor- This alert detects Integri- Automati- • Approve Yes No Forever
mation changes to asset- ty cally ap- All
Change related informa- proved by • Approve
(page 14) tion (such as Firm- CTD Selected
ware, OS, Host- • Archive
name, and Slot
Cards)
Baseline Rule This alert detects Integri- Not gener- • Approve No No 12

(page 15) baseline-related ty ated • Archive months
activity based on
custom configura-
tion
Configuration This alert de- Integri- • Approve • Approve Yes No 12

Download tects Configuration ty • Archive • Archive months
(page 16) Download events

CTD Reference Guide Alerts Table

Mode al Mode
Configuration This alert detects Integri- • Approve • Approve Yes No 12

Upload Configuration Up- ty • Archive • Archive months
(page 17) load events
DCS Configu- This alert detects Integri- • Approve • Approve Yes No 12

ration Change events related to ty • Archive • Archive months
(page 28) changes to the
DCS Configuration
Denial of Serv- This alert detects Securi- • Approve • Approve Yes Yes 12
ice (page 29) DoS attacks ty • Archive • Archive months
File System This alert detects Integri- • Approve • Approve Yes Yes 12
Change events related to ty • Archive • Archive months
(page 31) changes to the File
System
Firmware This alert detects Integri- • Approve • Approve Yes Yes 12

Download Firmware Down- ty • Archive • Archive months
(page 18) load events
Host Scan This alert detects Securi- • Approve • Approve Yes Yes 3
(page 32) Host Scan events ty • Archive • Archive months
by sending TCP
SYN or UDP re-
quests to multiple
hosts on the same
port
Known Threat This alert detects Securi- • Approve • Approve No Yes 12

Alerts suspicious events ty • Archive • Archive months
(page 33) based on Network
Signature match-
ing
Login This alert detects Securi- • Approve • Approve Yes Yes 3

(page 30) Failed Login events ty • Archive • Archive months
Man-in-the- This alert detects Securi- • Approve • Approve Yes Yes 3

Middle Attack Man-in-the-Middle ty • Archive • Archive months
(page 33) (MiTM) attacks
Memory Reset This alert detects Securi- • Approve • Approve Yes Yes 12
(page 34) Memory Reset ty • Archive • Archive months
events
Mode Change This alert detects Integri- • Approve • Approve Yes Yes 12
(page 19) events related to ty • Archive • Archive months
changes to the de-
vice Mode (Run,
Stop, Program)
Monitor or This alert detects Integri- • Approve • Approve Yes No 12

Debug Mode when a device ty • Archive • Archive months
(page 21) mode is set on
Monitor or Debug
New Asset This alert detects Integri- Automati- • Approve Yes No Forever
(page 22) new assets in the ty cally ap- and Up-
environment proved by date Poli-
CTD cy
• Ignore
• Acknowl-
edge

CTD Reference Guide Alert Resolution Options

Mode al Mode
New Conflict This alert detects Integri- Automati- • Approve Yes No Forever
Asset conflicts between ty cally ap- and Up-
(page 23) assets having iden- proved by date Poli-
tical information CTD cy
(IP, MAC) • Ignore
• Acknowl-
edge
Online Edit This alert detects Integri- • Approve • Approve Yes No 12

(page 24) Online Edit at- ty • Archive • Archive months
tempts to a device
program
Policy Rule This alert detects Integri- • Ignore • Ignore Yes No 12

Match policy related ac- ty • Acknowl- • Acknowl- months
(page 25) tivity based on edge edge
custom configura-
tion
Policy Viola- This alert detects Integri- Automati- • Approve Yes No 12

tion Alert anomalies in the ty cally ap- and Up- months
(page 25) network communi- proved by date Poli-
cations based on CTD cy
Zone policies • Ignore
• Acknowl-
edge
Port Scan This alert detects Securi- • Approve • Approve Yes Yes 12
(page 35) Port Scan events ty • Archive • Archive months
by sending TCP
SYN or UDP re-
quests to different
server ports on a
host to see which
ports it answers
on
Settings This alert detects Integri- • Approve • Approve Yes Yes 12

Change events related to ty • Archive • Archive months
(page 27) changes to the De-
vice Settings
Suspicious Ac- This alert detects Securi- • Approve • Approve Yes Yes 3
tivity suspicious events ty • Archive • Archive months
(page 36) based on OT pro-
tocol anomalies
Suspicious File This alert detects Securi- • Approve • Approve Yes Yes 12
Transfer suspicious events ty • Archive • Archive months
(page 37) based on Yara
Rule matching
2.4. Alert Resolution Options

The Alert Resolution Options give the user the ability to take actions on the alerts in order to
resolve them.

CTD Reference Guide Alert Resolution Options
NOTE
When the system is in training mode repetitive alerts are auto approved unless
there is a rejection from the user.
The following alert indicator is added when this action takes place: “this alert has
been repeated several times in the last 14 days with no rejection from the user while
the system is in training mode.”
2.4.1. APPROVE
Use “Approve” when the cause is acceptable and/or communication/activity is a legitimate network
communication. This action will result in all of the new policies associated with the alert to be
added as valid, this will ensure that the alert with the same policies is not triggered in the future.
2.4.2. ARCHIVE
Use "Archive" when the changed information is not acceptable or is not a legitimate network
communication/activity. This action will result in archival of all the information; and changed
information will not be added to the Asset. The alert will be marked as resolved with the status
of "Alert Archived."
2.4.3. IGNORE
Use “Ignore” when the event reported by the alert was expected or accepted as a one-time event,
and you would like to be notified of similar activity in the future. This action will result in new asset
information and associated baselines being rejected. The alert will be marked as resolved with the
status "Ignored."
2.4.4. APPROVE SELECTED

Use “Approve Selected” when only some of the detected changes are valid and acceptable. Se-
lect the specific changes which you want to approve before using the closure/resolution option
“Approve Selected.” This action will result in only the selected information accepted and alert
information updated to reflect the same. Any information which is not selected will be discarded.
2.4.5. APPROVE ALL

Use “Approve All” when detected changes are valid and acceptable. This action will result in all the
changed information accepted and alert information updated.
2.4.6. ACKNOWLEDGE
Use “Acknowledge” in case an alert is identified as a valid or true positive security event. This
ensures future alerts are triggered for the same events. This action doesn't impact or change the
policies. It is the same as "Ignore" and the only difference is how it is logged to help with auditing.
This will result in an alert being resolved with the status of "Acknowledged."
2.4.7. APPROVE & UPDATE POLICY

Use “Approve & Update Policy” when the cause is acceptable or communication/activity detected is
legitimate.

CTD Reference Guide Managing Integrity Alerts
This action will result in all of the new policies and asset information added as valid, this will
ensure that the alert with the same policies is not triggered in the future. The user has the option
to modify certain attributes of the asset such as Zone, and Criticality before approving the alert.
This system also provides the option to choose which zone rules (policies) to approve. The system
provides the list of suggested policy rule(s) for approval, once approved these rule(s) get added to
the policy.
NOTE
Ensure that policy rules are reviewed and validated before approving them, in case
of doubt only approve the asset by unchecking the policy rules.
2.5. Managing Integrity Alerts

In this section, we cover all the integrity alerts for CTD. For each alert we provide detailed informa-
tion including: an overview of the alert, its significance from a security perspective, guidelines for
analyzing the alert, and its resolution options.
2.5.1. ASSET INFORMATION CHANGE

An Information Change alert occurs when information of an asset is changed. Every asset infor-
mation change must be verified and approved. When a software version changes, the system also
reports that change.
Examples of information changes are:
1. Firmware
2. OS
3. Hostname
4. Slot Cards
2.5.1.1. Alert Significance

Unauthorized changes to an asset usually indicate either malicious activity or human error. Both
can have an impact on operations and safety of OT / ICS Systems. Of note, in case of malicious
activity, it can also have serious security implications.
2.5.1.2. Analyzing the Alert

You can use the alert page to find the necessary information when analyzing the alert. While on
the Alert page, use the following list of checks for analysis:
• Inspect the Asset Information Changes section to find the information that has changed for the
asset.
• Understand whether this information change was expected or planned.

• Understand the purpose of the change (such as Firmware, OS, Hostname, and Slot Cards), and
determine if anyone has been notified about an upcoming modification.
• Look into changes and whether they can affect the operation or safety of the process.
• Check the Event Details section for the events that led to change in the information.
NOTE
Events will not be present if the change is detected by Active Query or AppDB.
• If changes seem suspicious, look into the asset that initiated the changes. Check if it is an
internal or external asset.
• Check if these changes appear as human error or malicious activity.
• In case of any doubt check with the respective asset owner, plant engineer, or IT for validation.
2.5.1.3. Resolution Options

The following resolution options are available for this alert:
• Approve All
• Approve Selected
• Archive
2.5.2. BASELINE RULE

This alert is triggered when a baseline is inactive for the specified period or upon its appear-
ance. This alert needs to be manually configured by the admin in the Baselines page (under the
Investigation module), based on the baselines automatically created by the system.
Alert Example:
Baseline “E/IP: Get Network Request” has been inactive for more than xxx seconds/hours

Admins can configure baseline rules to alert on specific baselines (i.e. activity). If this alert is
triggered, then it could be an indication of either an operational issue or, in certain cases, it can
also be an indicator of an adversary performing malicious activity in the environment, such as
trying to block reporting messages or block command messages.

You can use the Alert page to find the necessary information when analyzing the alert. While on
• Understand the baseline rule that triggered the alert (inactive for / upon appearance). Of note,
after an alert is generated, all future events or triggers will be added to the same alert, until it’s
approved or archived.
• Review the original baseline and understand the activity that is being monitored.
• Contact the asset owner and notify him of the event.
• Ask the asset owner if this is due to a planned activity, maintenance, or an emergency activity.

• If not part of the planned activity, maintenance or an emergency activity, ask the asset owner to
verify the operations based on priority.

• Approve
• Archive
2.5.3. CONFIGURATION DOWNLOAD

A configuration download alert occurs when a configuration is downloaded from an asset, such as
an engineering workstation or other software package, to a controller (such as, a PLC, or RTU).
NOTE
The Configuration Change section, on the Alert page, includes the new configuration
files only for the 5 most recent alerts.
Alert Example:
A configuration has been downloaded to controller 10.243.54.92 by XCLKL4489

This alert may indicate that an adversary is trying to interfere with infrastructure activity by
changing the program or logic on the controller. For example, if the controller is running and as a
result stops functioning, it might cause a significant production loss.
In another scenario, the configuration or program could be altered in such a way that it can result
in incorrect process execution or alarm suppressions. All of these effects can result in unexpected
production outcomes, safety incidents, and loss of production.

• Check the Title and Indicators showing, for instance:

• Whether this activity has been seen for the first time in last 30 days
• Whether the source asset was previously involved in OT operations
• Whether the event is related to previous alerts in system
• Whether a new code section was added
• Review the Configuration Change section to view, code segments being uploaded, code differen-
ces, users performing code changes, and project name / identifier.
• Confirm if the Configuration Change could be related to any ongoing, planned or emergency
maintenance, deployment project or activity.

• If it was a scheduled/planned activity, verify that the actual change that was done is the change
that was planned.
• Identify the system from which this activity is performed and if possible, the user who per-
formed this activity, validate if they are authorized to perform such an activity.
• In the Root Cause Analysis section, check past instances of similar activity being performed
between the same devices or on other controllers from the same system and/or zone.
• In case of doubt or suspicion, work with process and/or OT engineers, provide them with code
changes and understand what is the impact that the change can have on the process or OT
operations.

• Approve
• Archive
2.5.4. CONFIGURATION UPLOAD

A configuration upload alert occurs when a configuration file is uploaded from a controller to
another asset, typically an engineering workstation or other software package. This activity is
typically detected via the Passive discovery method. However, another case where this alert will
trigger is when Active Query or AppDB discovery methods detect a change in the configuration.
NOTE
The Configuration Change section, on the Alert page, includes the new configuration
files only for the 5 most recent alerts.
Alert Example:
A configuration has been uploaded from controller 10.39.68.55 by XKYLL1135

This alert may indicate that an adversary might want to steal the operational information on
a production environment as a direct mission outcome for personal gain or to inform future
operations.


• Whether the source was previously involved in OT operations
• Whether event is related to previous alerts in system

• Whether connected assets were previously accessed via Remote Connection

• Understand the details of the activity that has taken place, such as what has been uploaded and
to where. Is the asset, where configuration is uploaded, authorized for the upload?
• Confirm if this could be related to any ongoing, planned or emergency maintenance, deploy-
ment project or activity. If it was a scheduled/planned activity, verify that the actual change that
was done is the change that was planned.
changes and understand what is the impact that the change can have on the process or OT
operations.

• Approve
• Archive
2.5.5. FIRMWARE DOWNLOAD

A firmware download alert occurs when the firmware is changed for an asset. An engineering
workstation, or other software present on a PLC, typically performs this download. When this
alert occurs, the system captures both the new and old version of firmware. When you resolve a
firmware download alert, the system records this change.
Alert Example:
A Controller firmware download performed to 10.243.55.35 by XDFKCL4489

A firmware change may introduce new vulnerabilities. Examine this action carefully before it is
done. If adversaries are aware of these vulnerabilities, they might make a firmware change to
perform more destructive actions. It is also possible that an attacker might change the firmware to
a vulnerable version which can be used later for malicious activities. Example of attacks include:
• Delayed Attack - The adversary might stage an attack in advance and choose when to launch it,
such as at a particularly damaging time.
• Brick the Ethernet Card - Malicious firmware might be programmed to result in an Ethernet
card failure, requiring a factory return.
• "Random" Attack or Failure - The adversary might load malicious firmware onto multiple field
devices. Execution of an attack and the time it occurs is generated by a pseudo-random number
generator.
• A Field Device Worm - The adversary may choose to identify all field devices of the same model,
with the end goal of performing a device-wide compromise.
• Attack Other Cards on the Field Device - Although it is not the most important module in a
field device, the Ethernet card is most accessible to the adversary and malware. Compromise of

the Ethernet card may provide a more direct route to compromising other modules, such as the
CPU module.


• Whether the source was previously involved in OT operations
• Whether the event is related to previous alerts in the system
• Whether this OT Operation was previously approved and associated information where appli-
cable
• Review when this alert occurred. The system captures both the new and old version of firmware.
Check whether the firmware version was known in the past.
• Research the new firmware version for known vulnerabilities or risks.
ment project or activity.
• Confirm that firmware download was planned, also the activity was done properly with all the
required security steps and as planned.
• Identify the system and if possible, the user who performs this activity, validate if they are
authorized to perform such activity.
• If the firmware download was not planned:
• Look into the asset that initiated the download, and whether it is possible that this asset
would be initiating a malicious activity. Also ascertain the criticality of the target asset, and
what would a malicious entity with the asset's firmware be able to do.
changes and understand the impact that the change can have on process or OT operations.

• Approve
• Archive
2.5.6. MODE CHANGE

A mode change alert occurs when a user changes the mode of a controller from a system such as
an engineering workstation, or other software application. This alert is triggered when CTD detects
a mode change activity.
Common modes of the controllers are:

• Program - This mode must be enabled before changes can be made to a device’s program. This
allows program uploads and downloads between the device and an engineering workstation.
Often the PLC’s logic is halted, and all outputs may be forced off.
• Run - Execution of the device’s program occurs in this mode. Input and output (values, points,
tags, and elements) are monitored and used according to the program’s logic. Program Upload
and Program Download are disabled while in this mode.
• Remote - Allows for remote changes to a PLC’s operation mode.
• Stop - The PLC and program is stopped, while in this mode, outputs are forced off.
• Reset - Conditions on the PLC are reset to their original states. Warm resets may retain some
memory while cold resets will reset all I/O and data registers.
• Test / Monitor mode - Similar to run mode, I/O is processed, although this mode allows for
monitoring, force set, resets, and more general tuning or debugging of the system. Often moni-
tor mode may be used as a trial for initialization.
Alert Example:
Mode Change operation was performed for the first time by 192.168.152.153 on 192.168.45.129

An adversary may want to interfere with normal critical infrastructure activity by changing a
controller mode. If the controller is running, and the attacker stops it, this may cause a significant
production loss. For example, a command such as a 'stop' to a PLC can cause a DoS (Denial-of-
Service) attack.

• Review the Event Details section, which contains the details of the PLC’s mode that was changed,
and other associated events before or after the mode change if applicable.
• Confirm if this could be related to any ongoing, planned, or emergency maintenance, deploy-
• Identify the system and if possible, the user who usually performs this activity, validate if they
are authorized to perform such activity.
• Look into the asset that was changed, the assets criticality, and whether a mode change can
cause immediate damage to the process.
• If the activity was not planned, look at what kind of asset it is and whether it's external or
internal.

• Approve
• Archive

2.5.7. MONITOR / DEBUG MODE

This alert alert occurs if a user uses an engineering workstation or other software package to put a
controller into monitor or debug mode. This is typically a troubleshooting function built into some
controllers. This alert is triggered when such activity is detected.
NOTE
This alert does not occur for every controller model, and should rarely occur during
normal operation.
Alert Example:
Controller STHNJENA83 is monitored/debugged by XLCUL0010

An attacker may want to interfere with normal critical infrastructure activity by changing a control-
ler mode to debug mode. If the controller is running and the attacker stops it, or slows it down,
this might cause a significant production loss. Moreover, this alert also provides visibility into
changes which can help with compliance and change tracking.


• Whether this operation has been seen in the last 30 days.
• Whether this OT operation was previously seen for this source asset or not.
• Whether this alert was previously approved and associated info.
• Identify changes performed as part of this activity.
• Confirm if this could be related to any ongoing, planned, or emergency maintenance, deploy-
• If it was a scheduled/planned activity, verify that the actual change that was done is the planned
change.
formed this activity, validate if they are authorized to perform such activity.

• Approve

• Archive
2.5.8. NEW ASSET

A new asset alert occurs when a new asset is added. A new asset is learned by detecting its
communications. Examples of new assets are Vendor laptops, Virtual Machines, Physical servers,
and PLCs.
Although the asset is new, its communication could be familiar because it was seen within the
same Virtual Zone. Therefore, it is possible the policy already contains rules that address this
communication. Virtual Zone criticality and asset type significantly contribute to the triggering of
the alert. For instance:
• If a new asset with type endpoint (low criticality type) is detected in a Virtual Zone with low
criticality and that asset is not communicating with any critical assets or critical virtual zones,
then no alert will be generated.
• If a new asset with type endpoint (low criticality type) is detected in a Virtual Zone with low
criticality and that asset is communicating with any critical assets or critical virtual zones, then
an alert will be generated.
• If a new asset with type endpoint (low criticality type) is detected in an External Virtual Zone and
that asset is communicating with an internal asset, then an alert will be generated.
• If a new PLC asset (high criticality type) is detected in a Virtual Zone with low criticality, then an
alert will be generated.
Alert Example:
New asset detected: A new RTU was detected in OT operations permitted zone: "RTU: IEC104",
performing data acquisition operation communication: 172.20.65.25

Since changes to OT environments are controlled and usually pre-approved, any new asset detec-
ted which is not part of the planned activity, could be an indicator of a rogue device. This rogue
device could be part of shadow-network (an unauthorized asset used by site personnel to perform
certain activities), or an asset deployed by an adversary for malicious purposes.
Some of these changes can result in increased threat exposure and unknown risk, while some are
a direct indication of an attack in progress.

• Review, on the Alert page, the Indicators section to establish context.

• View the Asset Details section to get more information about the new asset, such as the vendor,
the nature of the communication (who is talking to who), and the baselines.
• Check the Root Cause Analysis section, which provides assets involved in the communication
and any other associated alerts.
• In the Event Details section, analyze events that led to this alert.

• View the Asset Communication section, which shows if the communication is addressed by
existing policy rules.
• View the Baselines section, which shows baselines associated with the alert.
• Understand the zone where the asset is identified and whether it aligns with the zone.
• Confirm if the new asset detected is part of any ongoing, planned, or or emergency mainte-
nance, deployment project, or activity.
• In case of any doubt, check with the respective asset owner, plant engineer or IT for validation.
• If permitted, try to connect to the asset to obtain more details.

• Approve & Update Policy

• Ignore
• Acknowledge
2.5.9. NEW CONFLICT ASSET

A new conflict asset alert occurs when information about a new asset conflicts with an existing as-
set information. This could occur because an asset has an identical IP address, MAC address, or
other information, with another asset.
Alert Example:
A new asset has been detected AssetID1 and is conflicting with AssetID2.

Usually, an asset conflict arises due to a misconfiguration of an asset, human error, or when an
adversary is trying to impersonate a valid asset for malicious activities. In both cases, an asset
conflict can have a significant impact on the operations and safety of ICS systems. Malicious
activity can also have security implications.
For example, a change in your asset details may be done by attackers to perform authentication
based on an IP address. A common attack is to impersonate a highly privileged IP address, such as
an engineering station, and use it to run changes on critical equipment.

• Check the Assets to Merge section, which shows the asset information, the conflicting informa-
tion highlighted in RED, and allows selections of which assets to keep or merge.
• Check the Asset Information Changes section to view changes in asset information.
• Review attributes of the assets that have conflicting values. Verify whether this information
change was expected and understand what has led to the conflict.
• Review notifications of an upcoming change and information about the change.
• Check for MAC modifications. They are uncommon and might be suspicious.

• Review the Asset Communication section which shows if the communication is addressed by
existing policy rules.
• In case of any doubt, validate with the respective asset owner, plant engineer or IT.


• Ignore
• Acknowledge
2.5.10. ONLINE EDIT

An online edit alert raises when an online activity attempt is detected. This takes place when
someone connects to the controller from an engineering station or a similar system and performs
changes directly in the program by putting the controller in online edit mode.
Alert Example:
Online Edit critical change operation was performed by 10.41.133.95 on 10.41.131.209:Card 2 \

10.41.131.85

An unauthorized change of settings can result in an unexpected behavior which can have signifi-
cant impact on operations ranging from interruption of the process or complete malfunctioning or
can even lead to a safety incident.
• Adversaries can use the online edit to modify or add a program on a controller to affect how it
interacts with the physical process, peripheral devices, and other hosts on the network.
• Adversaries may perform a program download to transfer a user program to a controller or
might modify the task of a controller to allow for the execution of their own programs using the
online edit mode.

• Check the Events Details section, to see the actions performed in online edit mode.
• Review the Configuration change to see code changes, where applicable.
• Confirm that detected communication was actually an Online Edit Operation.
• Identify the system where this activity is performed and if possible, the user who performed this
activity, validate if they are authorized to perform such activity


• Approve
• Archive
2.5.11. POLICY RULE MATCH

This policy alert occurs when communication matches an existing Zone Rule where the ‘alert’
action is configured. This alert needs to be manually configured by the admin in the Zone Rules
page, based on the Zone Rules automatically created by the system.
Alert Example:
Communication matching policy rule ID 182 was detected from 10.234.125.254 to 10.121.70.151

This alert is triggered when an activity matches a policy rule configured by the system administra-
tors. Depending on the purpose of the policy rule, it could be for information that is detecting
operational or security issues.

• Review the policy rule that triggered this alert

• Understand the activity / communication which resulted in the policy rule match.
• If the rules are created on specific requests, then notify the users or teams that have requested
this policy rule.
• Establish validity of the activity / communication which resulted in the match and whether it
requires an exception.

• Ignore
• Acknowledge
2.5.12. POLICY VIOLATION

The Policy Violation mechanism automatically generates rules that control alert strategies. These
rules differentiate between allowed versus suspicious communication. A Policy Violation alert is
triggered when the communication detected between assets did not match any explicit ‘Allow’ or
‘Alert’ rules. The implicit ‘Alert on Anything’ rule is matched by default.

Alert Example:
Policy Violation: New authentication operation communication parameters were detected from
10.234.125.254 to 10.121.70.151

Every non-standard behavior activity or unauthorized communication in the network is a cause for
concern.
• Non-standard behavior or unauthorized approval can be an indicator of something malicious

taking place, human error, or occasionally it can be due to a malfunctioning system.
• If detected at an early stage and responded to, then it can be the difference between a success-
ful attack/safety/operational incident versus a failed one.

• Review the Policy Violations section which might include:

• Some of the asset’s observed communication addressed by existing rules (either ‘Allow’ or
‘Alert’)
• No matching existing rules of communication.
• The closest existing policy rules and seeing how the detected communication differs from
them.
• View the Alert Graph section for a graphical view of assets involved and helps in understanding
the detected communication.
• Understand which assets are involved and their role, use this information to understand wheth-
er the communication that resulted in policy violation is expected between these systems.
• Understand the detected communication and policy which has been violated, including if it’s a
communication that was not seen previously.
• Find the closest existing policy rules and see how the detected communication differs from
them.
• Check the Baselines Summary sections for a summary of baselines for alerts.
• Understand which rules should be created/updated if any and added to the policy in order to
approve the detected communication so it does not trigger an alert if seen again
• Try to understand the consequences of the change. If the alert is identified as an unauthorized
communication, alert the relevant stakeholders on its priority.


• Ignore
• Acknowledge

CTD Reference Guide Managing Security Alerts
2.5.13. SETTINGS CHANGE

Settings change alert occurs when a change is detected in the OT asset settings (e.g. TCP/IP setting
changes), and not in the logic, program, or mode of the asset.
Alert Example:
TCP/IP settings were changed on device 10.71.66.120 by 10.71.68.11

Unauthorized changes to an asset are usually an indication of either malicious activity or human
error, both can have an impact on operations and safety of ICS Systems. Malicious activity can also
have security implications.


• Whether this activity is seen in the last 30 days
• Whether a code section was changed, added or removed.
• Check the Configuration Change section, which provides details of code added, removed or
modified.
• Understand which settings have changed and verify whether this information change was expec-
ted or planned.
• Understand the purpose of the change (such as, hostname change), and its implications.
• Look into the changes that were made and whether they can affect the operation or safety of
the process
• If change seems unusual, look into the asset that initiated the change. Is it an internal or
external asset? Does it look like a human error or malicious activity?
• In case of doubt check with respective Asset owner, plant engineer or IT for validation.

• Approve
• Archive
2.6. Managing Security Alerts

In this section, we cover all the security alerts for CTD. For each alert we provide detailed informa-
tion including: an overview of the alert, its potential impact, guidelines for analyzing the alert, and
its resolution options.

NOTE
After an alert is approved, future alerts with similar characteristics (source, destina-
tion, protocol, ports, and signature as applicable to the type of alert) will be auto-ap-
proved. This auto-approval of the alert takes place if the alert has been approved in
the last 30 days.
In certain cases, the alert might still be generated if the alert score is still above the
configured threshold.
2.6.1. DCS CONFIGURATION CHANGE ALERT

A DCS Configuration Change alert occurs when the system detects any actions between the Dis-
tributed Control System (DCS) and the assets it manages. These include both those performed by
the DCS on the managed assets and those performed by the assets on the DCS.
For example:
• Start a server on a remote node

• The DCS is stopped/started
Alert Example:
A DCS Configuration Change was made to controller 10.243.54.92 by XCLKL4489.

This alert indicates that an adversary might want to interfere with a normal critical infrastructure
activity by stopping the DCS or tampering with managed controllers. This could cause a significant
production loss.
For example, a command such as a 'stop' to a DCS could cause significant damage.
2.6.1.2. Analysis
You can use the Alerts page to find the necessary information when analyzing the alert.
Use the following list of checks for analysis:

• Confirm if the DCS Configuration Change could be related to any ongoing, planned, or emergen-
cy maintenance, deployment project or activity.
• If it was a scheduled/planned activity, verify that the actual change made is the change that was
planned.
• Identify the system from which this activity is performed and, if possible, the user who per-
formed this activity. Then validate if they are authorized to perform such an activity.

• In case of doubt or suspicion, work with process and/or OT engineers. Providing them with the
changes will help to understand the impact that the change could have on the process or on OT
operations.

• Approve
• Archive
2.6.2. DENIAL OF SERVICE

TCP SYN flood (a.k.a. SYN flood) is a type of Denial of Service (DoS) attack that exploits part of
the normal TCP three-way handshake to consume resources on the targeted server and render it
unresponsive.
In a SYN flood attack, the attacker sends repeated SYN packets to every port on the targeted
server, often using a fake IP address. The server, unaware of the attack, receives multiple, appa-
rently legitimate requests to establish communication. It responds to each attempt with a SYN-ACK
packet from each open port.
The malicious client either does not send the expected ACK, or—if the IP address is spoofed—
never receives the SYN-ACK in the first place. Either way, the server under attack will wait for
acknowledgement of its SYN-ACK packet for some time.
During this time, the server cannot close down the connection by sending an RST packet, and the
connection stays open. Before the connection can time out, another SYN packet will arrive. This
leaves an increasingly large number of connections half-open – and SYN flood attacks are also
referred to as “half-open” attacks. Eventually, as the server’s connection overflow tables fill, service
to legitimate clients will be denied, and the server may even malfunction or crash.
Alert Example:
SYN Flood: Asset 192.168.1.14 performed a SYN Flood on asset 192.168.2.56

This alert should not be seen in a normally operating environment. In most cases this is an
indicator of an attack in progress, and it could be due to some stress testing being done against
a system or some misconfiguration. A successful SYN Flood either intentional (by an adversary) or
unintentional can result in service outage or service degradation for the services provided by the
targeted asset.


• Review the device from where the SYN Flood is originating. Note, this information may or may
not be trustful. In fact, in such attacks usually fake IP addresses are used since attackers don't
want to respond to the SYN request.
• Use other tools or solutions such as NetFlow logs to identify where the communication is
actually originating from, which switch the traffic is coming from, which asset is connected to the
switch port from which this traffic is originating.
• Understand the asset that is being attacked, and the services that are provided by that asset.

• Approve
• Archive
2.6.3. FAILED LOGIN

A failed login is when a user attempts to login multiple times in a row and fails each time. This alert
is generated when CTD detects a failed login.
Alert Example:
Failed Login: SMB Failed Login attempts were made to asset 141.122.111.218 from 10.77.106.12

Failed logins can occur due to the user entering the incorrect credentials, systems using the
cached or logged-in user’s credentials while accessing remote services, and/or an adversary trying
to login to a system by guessing the credentials or brute-forcing.
For the most part these are common occurrences, however in some cases where it relates to an
adversary, these alerts could be an indicator of something malicious taking place. In fact, this alert
could represent an attacker attempting to gain access to an asset through a brute force attack or
use of valid accounts.

• Review the username that appears in the alert Description (where available).
• Review the multiple indicators to help understand the context and help with decision making
• Evaluate the details of the failed login attempts to determine if it is a user inputting incorrect
credentials, or if it is a malicious attempt. This can normally be determined by the source and
frequency of the authentication attempts:
• If the source of the authentication attempts is not a normal access point for a PLC (for
example, an engineering workstation or HMI), this may indicate malicious traffic.
• If the frequency of failed login attempts is significantly faster than a normal user would
attempt, this would also indicate malicious behavior.
• Check the Root Cause Analysis section, which shows other similar events and if multiple assets
are involved.


• Approve
• Archive
2.6.4. FILE SYSTEM CHANGE

A File System Change alert is triggered when the system detects the editing/deletion of files from
the PLC file system.
Alert Example:
A file change was made to controller 10.243.54.92 by XCLKL4489.

This alert could indicate that an adversary is trying to interfere with infrastructure activity by
changing the program or logic on the controller. For instance, critical files could be altered in a
way that results in incorrect process execution or alarm suppression. Ultimately, this could result
in unexpected production outcomes, safety incidents, and loss of production.

You can use the Alerts page to find the necessary information when analyzing the alert. While on

• Whether the event is related to previous alerts in system
• Whether a file was was added/edited /deleted
• In case of doubt or suspicion, work with process and/or OT engineers. Providing them with file
changes will help to understand the impact that the change could have on the process or OT
operations.

• Approve
• Archive

2.6.5. HOST SCAN

Network scanning is a procedure for identifying active devices on a network by employing a fea-
ture or features in the network protocol to signal devices and await a response. Host Scan is one
of the techniques of Network Scanning in which a single asset tries to reach or scan multiple hosts
over the same port. This alert is generated when CTD detects such an activity in the environment.
For triggering this alert, CTD checks the following parameter:
• Scan Time Frame – The time frame that the threshold should pass in order to create a network
scan alert.
• Min Requests – Minimum requests required to trigger a scan alert.
Alert Example:
TCP Host scan: Asset 192.168.1.26 sent packets to different IP destinations on the same port: 80

Network scanning performed from unauthorized systems is usually an indicator of an adversary
trying to do reconnaissance to understand or map the network. An adversary can use this infor-
mation in later stages of his attack to identify targets, methods of compromising assets, and/or to
find the paths for lateral movement.

• Review the source of the host scan, and the affected assets including the port which was
scanned on those assets.
• Check indicators that show:
• Whether similar scans were previously approved
• Whether the scan was performed on common or uncommon port
• Whether the scan was within or across subnets
• Whether the source asset was previously involved in network scans
• When a host scan occurs within the network, evaluate the asset that performed this scan,
notably:
• The pathway the attacker used, and the affected machine to ensure they are not vulnerable to
remote network attacks.
• Inspect the asset's last activities in the network, and whether this asset seems malicious.
• Inspect the assets that were scanned, notably:
• What services do they provide?
• Are the assets critical to any process or do other services depend on them?
• Inspect the port that was scanned on those hosts. Are there any vulnerabilities known in these
ports?


• Approve
• Archive
2.6.6. KNOWN THREAT ALERTS

Claroty CTD Threat engine uses Network Rules to identify known threats. This alert is triggered
when a communication matches the patterns or values related to a known threat, such as mal-
ware (ransomware, infostealers, cryptominers, etc.) or an exploit for a certain vulnerability.
Alert Example:
Known Threat: Threat ET TROJAN Approx. Form Submission to C&C was detected from 10.0.0.130
to 216.150.79.226

This alert is triggered when a known threat is detected in the environment and the impact varies
depending on the threat being identified. This known threat could be ransomware trying to restrict
access to data on the data to extort ransomed, it could be a stealer trying to steal confidential
information or some other form of malware that is just trying to disrupt the availability of services.
The impact of these threats could be anything from data theft to complete system outage or
complete data loss.

• Review the Indicators section which shows whether this signature was triggered in the environ-
ment in the last 30 days and whether this alert is related to another alert.
• Check the Event Details section to view what is matched. Look at the individual events and
understand the signature that has resulted in this alert.
• Understand the nature of the threat that is linked to the Network Rule, such as whether the
malware referenced in the rule is ransomware or something else, and which vulnerabilities it
uses.
• Review both the source and destination asset involved in this communication, and whether they
are actually exposed to the vulnerability that is exploited by this threat vector. Check whether
this threat has been seen on other devices with which these assets are communicating.
• Consider scanning the assets involved in communication via AV software, to ensure that they are
not compromised.

• Approve
• Archive
2.6.7. MAN-IN-THE-MIDDLE ATTACK

This alert is triggered when the system detects that a potential attacker inserted a new machine
into the communication pathway between two assets.


When a Man-in-the-Middle (MiTM) Attack alert is generated, it captures both the new machine
inserted into the communication pathway, and both assets affected by the attack. This rogue ma-
chine may use this advantageous position to either monitor or alter the communications between
these assets.

You can use the Alerts page to find the necessary information when analyzing the alert. While on

• Whether this asset was previously involved in IT/OT operations
• The new asset added should be identified and removed or remediated to prevent it from being
used in an attack again.
• The pathway the attacker used should be evaluated as well.
• All the actions taken during the Man-in-the-Middle Attack will be captured. This information
should be used to reverse any changes made to the affected assets.
• In case of doubt or suspicion, work with process and/or OT engineers to understand the impact
on IT/OT operations.

• Approve
• Archive
2.6.8. MEMORY RESET

A memory reset consists of the overwrite of the controller memory (RAM memory). This alert is
triggered when detecting a Memory Reset Operation.
Alert Example:
Memory reset performed on controller 10.161.66.169 by 10.161.66.27

Most of the time, this alert will trigger during a configuration download performed by OT engi-
neers. Different controller platforms provide different options for this action, some actions will
completely erase the RAM, some will only reset Program, some might just erase I/O values.
Depending on the action being performed, the effect could be from minor process disruption
to total loss of control. For example, if a program is erased, then no program remains in the
controller memory and the controller doesn’t control the production line and its equipment any
more.


• Review whether this alert is related to previous alerts in the system.

• Check whether the source alert was seen performing this operation earlier.
formed this activity, validate if they are authorized to perform such activity.

• Approve
• Archive
2.6.9. PORT SCAN

Port Scan is a network scanning technique, where a single asset tries to reach or scan multiple
ports on another host. This alert is generated when CTD detects a Port Scan in the environment.
Network scanning is a procedure for identifying active devices on a network by employing a
functionality in the network protocol to initiate a conversation with different devices and await a
response.
For triggering this alert, CTD checks the following parameters:
• Scan Time Frame – The time frame that the threshold should pass in order to create a network
scan alert.
• Min Requests – Minimum requests required to trigger a scan alert.
• Relevant Ports– Ports above this are not considered as part of the port count
Alert Example:
TCP Port Scan: Asset 193.26.166.166 sent probe packets to 10.9.158.196 IP address on different
ports.

Network scanning performed from unauthorized assets is usually an indicator of an adversary
trying to do reconnaissance to understand or map the network. An adversary can use this infor-
mation at later stages of the attack to identify targets, methods of compromising assets, and/or to
find pathways for lateral movement.


• When a port scan occurs within the network, evaluate the machine that performed this scan,
the pathway the attacker used, and the affected machine to ensure they are not vulnerable to
remote network attacks.
• Look into the asset that was scanning and its last activities in the network - whether this asset or
its activities seems malicious
• Look into the ports that were scanned - are there any vulnerabilities known in these ports?
• Look into the assets that were scanned - is there anything common to these assets? Are they all
in the same subnet? Are they all of the same kind? Are they critical to the process?
• Check Indicators showing, for instance:
• Whether a similar scan was approved previously.
• Whether the scan was performed on a common or uncommon port.
• Whether the scan was within or across subnets.
• Whether the source asset was previously involved in network scans.

• Approve
• Archive
2.6.10. SUSPICIOUS ACTIVITY

A Suspicious Activity alert represents an umbrella alert type which comprises suspicious or possi-
bly malicious OT-protocol activities, detected by the system. Some examples of these activities are:
• Malformed Packets
• Operational Error
• Invalid Sessions
• Unknown Object
• Protocol DDoS

Typically, this alert could indicate that misconfigurations are affecting the involved assets, and as
such, could potentially impact the standard operations and safety of ICS systems. Moreover, it
could also indicate a potentially malicious attempt to meddle with those assets.
• Review the Event Details section of the alert, which contains the details of the suspicious/mali-
cious activity that was detected.
• Identify the assets that exhibit the suspicious activity and determine whether this activity is the
result of a misconfiguration, or if it is potentially malicious.

• In case of doubt or suspicion, work with process and/or OT engineers to get access to the
affected assets and further investigate.
• Understand the impact on process or OT operations and develop a suitable response plan.

• Approve
• Archive
2.6.11. SUSPICIOUS FILE TRANSFER

CTD is able to identify the transfer of malicious files, by matching them against signatures of
known malicious files via out-of-the-box Yara rules.
Alert Example:
Suspicious file transfer found! File 'unknown_file_name' was transferred via 'http' and matched
the following Yara rules: ['RANSOM_Kraken.yar/kraken_cryptor_ransomware'], Transferred from
10.243.188.213

This alert is triggered when a known malicious file is detected. This file could be anything from
ransomware, infostealer, worm or more. The potential impact depends on the nature of the
malware being detected, and its capabilities. For example, a ransomware that encrypts the data or
entire file system can render the system unusable, which can bring down the operations.

• Review the alert Title, which provides the malicious file name. The title also includes the detail of
the Yara rule that led to this detection.
• Inspect the Event Details section, to review the signature that was matched in this alert.
• Understand the nature of the threat that is linked to the Yara rule, such as whether the malware
referenced in the rule is ransomware or something else, and which vulnerabilities it uses.
• Review both the source and destination asset involved in this communication, whether they
have the vulnerability that is exploited by this threat. Is this threat seen on other devices with
which these assets are communicating?
• Consider scanning the assets involved in communication with AV software, to ensure that they
are not compromised.

• Approve
• Archive

CTD Reference Guide Insights
3. Insights
The CTD system identifies assets affected by potential security risks, based on a variety of out-of-
the-box use cases, and groups them together into insights. The purpose of the insights is to
provide knowledge regarding these security risks and indicate mitigation measures, which will
improve the overall security posture of the organization.
This chapter divides the available insights into two major categories: based on risk management
use cases (for example, network segmentation, remote access, password hygiene), and vulnerabili-
ty management ones. See the following sections for more information on a particular insight.
3.1. Risk Management

CTD provides multiple risk management insights that will help in improving the security posture of
the organization.
3.1.1. ASSETS ACCESSED SMB SHARES

This insight includes assets that have open SMB file shares, as well as the assets that accessed
them. Based on this insight, one can find critical shares that hold operational information or
unauthorized access.
3.1.2. ASSETS ACCESSING SMB PIPES

This insight includes assets that have open SMB named pipes, as well as the assets that accessed
them. Accessing a named pipe can indicate remote management and can be used for malicious
purposes, such as remote monitoring, reading event-log records, modifying registry keys, and
executing code (such as PsExec).
3.1.3. ASSETS WITH PARTIAL CONNECTION TO THE INTERNET

This insight includes assets with a partial connection to the internet. These assets are supposed to
be isolated, yet they are potentially exploitable because they can still access external resources via
DNS requests.
3.1.4. CLIENTS REMOTELY MANAGED

This insight includes assets that manage other assets remotely using different remote connection
protocols (such as, RDP, SSH, WinRM, VNC). This might indicate that users (third parties or employ-
ees) might have established a remote connection for various maintenance purposes. Additionally,
a potential threat actor might have succeeded in compromising the target assets.
3.1.5. DHCP CLIENTS

This insight includes assets providing DHCP services to clients. The insight displays the list of
client assets that received the DHCP service from that server. DHCP enables clients to request IP
addresses and networking parameters automatically. It is important to monitor the DHCP servers
in the network because an attacker can pretend to be the server and use it to perform attacks.

CTD Reference Guide Risk Management
Figure 3. An asset acting as a DHCP server
3.1.6. DATA ACQUISITION WRITE (OPERATED PLCS)

This insight includes assets that perform data acquisition write actions, despite the fact that
privileged commands (write) are not part of the standard data acquisition operations. These kinds
of commands are typically used as part of routine operations of engineering workstations, such as
configuration download/upload or changing settings and modes.
3.1.7. END OF LIFE (EOL) ASSETS

All products reach the end of their life cycle for several reasons, including market demands,
technology innovation and development-driven changes or product maturity.
To identify assets that have reached End of Life (EOL) status, use the EOL Insight, which lists assets
belonging to a model series that is no longer supported by the vendor. These assets might pose a
security risk, since the vendor is no longer issuing security updates for them.

Figure 4. EOL Insight
The following table describes in detail the Vendors and types of devices supported by CTD and
links to further information on the vendor's website.
Table 1. EOL Supported Vendors and Models
Vendor No. of EOL Devices Device Types
Cisco 822 Routers, Switches, IP Phones, UCS
Mitsubishi 193 PLCs
Omron 280 Relays, Switches, Connectors, Sensors
Rockwell Automation 8774 AFDs, PLCs, I/Os, HMIs, Monitors
Schneider Electric 5 PLCs, Switches, I/Os
Siemens 42 Medical Imaging
Yokogawa 1270 PLCs, Meters, Monitors, Distributors, Sensors
NOTE
New EoL vendors and models are added to CTD on a regular basis and made
available via Threat Bundle Updates.
For further information on Insights, see User Guide: Insights.
3.1.8. FILES DOWNLOADED (CLIENTS)

This insight includes assets where clients download files from file servers using different protocols.
A prominent OT attack method is to maliciously modify a configuration file and download it to the
controller. Any asset involved with downloading files should be closely monitored.

3.1.9. HIGHLY CONNECTED ASSETS

This insight includes assets that are highly connected, in terms of the amount of network connec-
tions they initiate. In some cases, this indicates key devices in the network such as, data collection
services, monitor servers, but might also possibly hint at an adversary performing network recon-
naissance.
3.1.10. MANAGED PLCS (BY ROCKWELL USERS)

This insight includes assets where users perform a connection to PLCs using a Rockwell engineer-
ing station. The users listed are those that logged into the Windows machine running the engineer-
ing software.
3.1.11. MULTIPLE INTERFACES

This insight includes assets with multiple interfaces. Every network interface enables independent
communication. This might compromise the efficiency of firewall segmentation, which might not
take into consideration all the interfaces when defining the asset's policy.
3.1.12. OPEN PORTS

This insight includes assets where clients have open ports. Open ports are the doorways to your
secure perimeter. Behind open ports there are applications and services listening for inbound
packets, waiting for connections from the outside in order to perform their jobs. Security best
practices imply the use of a firewall system that controls which ports are opened or closed on
Internet-facing servers.
Additionally, security best practices advise that ports should be opened only on an “as-needed”
basis, dictated by the Internet communication needs of applications and services that run on the
servers.
NOTE
Shows open ports for the top 50 ports of the asset. If the port is above 30,000 it
will not be displayed. Open ports can be viewed in the Asset Page, under the Risk &
Vulnerabilities tab.
3.1.13. PLCS EXPOSED TO PROGRAM CHANGES

This insight includes PLC assets that are exposed to remote program changes or have been stop-
ped, therefore extending the attack surface. Setting the device in run mode (disabling the remote
program capability) will reduce the risk of unauthorized logic/program modifications. Devices that
have been stopped might indicate a malfunction of the device.
3.1.14. PLCS EXPOSED TO TRITON

This insight includes PLC assets that run Triconex safety systems in remote programmable mode.
Setting the device in a remote program mode enables a malicious user to alter the configuration
on the remote device. The same methodology was leveraged by the Triton malware to exploit a

remote device. It is considered best practice to avoid setting the device in remote programmable
mode.
3.1.15. PLCS TALKING IT PROTOCOL

This insight includes PLC assets communicating using an IT protocol. This could be the result of
misconfiguration or malicious activity, and requires monitoring.
3.1.16. PRIVILEGED OPERATIONS (OPERATED PLCS)

This insight includes OT assets that performed privileged operations on PLCs/Controllers/RTUs/
IEDs. Privileged commands are often used as part of sensitive engineering operations such as con-
figuration download/upload or changing settings and modes, therefore it is important to monitor
them.
3.1.17. REMOTE DESKTOP APPLICATION

This insight includes assets that run remote desktop applications. These applications might be
leveraged by attackers for various malicious activities on the exposed assets.
3.1.18. SMBV1 NEGOTIATE

This insight includes assets where SMBv1 negotiation is detected. SMBv1 has published vulnerabil-
ities most commonly used by WannaCry malware. It is recommended to disable the use of the
SMBv1 protocol extension on all Windows machines.
3.1.19. SNMP QUERYING ASSETS

This insight includes assets that were issuing SNMP queries. SNMP is a legitimate tool to gather in-
formation from a variety of machines. However, it is also in common use with attackers attempting
to expand their knowledge of the network following an initial compromise. A high volume of SNMP
queries relative to other machines may indicate malicious presence.
3.1.20. TALKING WITH EXTERNAL IPS

This insight includes assets that communicate with IPs classified as external, namely devices out-
side of the company's perimeter. This may enable potential attackers to penetrate the OT network.
3.1.21. TALKING WITH GHOST ASSETS

This insight includes Ghost assets identified in the network, as well as the assets communicating
with them. Ghost assets are entities that never replied to a request. These entities could be the
result of a misconfiguration and can be used as an attack surface into the network. Attackers can
hijack such communication by impersonating a ghost asset, compromising the talking asset.
3.1.22. TOP RISKY ASSETS

This insight includes the top 10 assets with the highest risk score. The Risk Score indicates the risk
level of an asset. The higher the score, the riskier the asset.
3.1.23. UNSECURED PROTOCOLS

This insight includes assets with protocols containing known security weaknesses that attackers
can leverage to compromise the network’s security. For example, protocols transferring data in
plain text with no authentication. The protocols the system considers unsecured include: FTP, SMB
(v1), SMTP, SNMP (v1/v2), SSH (v1), SSL (all versions), TELNET, TFTP, TLS (1.0 – 1.1), and VNC.

CTD Reference Guide Vulnerability Management
Figure 5. An example of the reason the protocol is unsecured
3.1.24. UNSUPPORTED OS
Unsupported operating systems no longer receive technical support or security updates from their
developers, which places assets with such operating systems at risk.
3.1.25. USB DEVICES CONNECTED TO ASSETS

This insight includes USB device assets and the assets they are connected to.
3.1.26. USING UNENCRYPTED & WEAK PASSWORDS

This insight includes assets that either use default or no passwords or implement a protocol that
transfers data in plain-text, making those assets potentially exploitable. To reduce the risk of those
assets, use passwords with encrypted protocols and change the default password.
3.1.27. WEB SERVERS

This insight includes assets that are classified as web servers. The insight displays the list of
servers, their IP, the number of assets that accessed them, the server type (such as, file server)
and vendor.
3.2. Vulnerability Management

CTD provides vulnerability management, which matches known CVEs (vulnerabilities) to discov-
ered assets. This allows the user to prioritize and manage the patching operation for those assets.
Claroty customers can receive regular Threat Definition Updates with the latest threats discovered
by Claroty’s Research team. The Threat Definition Updates include new CVEs, as well as network
traffic signatures and Yara signatures, and allow the users to stay up-to-date without a full up-
grade of the entire CTD software. For more information see Threat Definition Updates in the CTD
User Guide.
Asset vulnerabilities are categorized based on different types of CVE matches:
• Full match – This category represents the most accurate level of CVE matching. Insights belong-
ing to this category match CVE details against the following asset information:
• Vendor, Model, and Firmware version (Full Match CVEs)
• Windows OS version, Build and installed Security Patches (Windows CVEs Full Match).
• Installed Program versions (Program Match CVEs).

NOTE
It is possible that specific asset configurations actually solve some of the detected
vulnerabilities.
• Model match – This category matches CVE details against assets’ vendor name and model
only, since the system was unable to determine the firmware version. Therefore, it is possible
that non-vulnerable assets will still appear as vulnerable within this insight, due to the inherent
limitations of this type of matching. If this is the case, we recommend applying the “Mark as
Completed” action for those assets.
• Vendor match – This category matches CVE details against assets’ vendor name only. Therefore,
it is possible that non-vulnerable assets will still appear as vulnerable within this insight, due to
the inherent limitations of this type of matching. If this is the case, we recommend applying the
“Mark as Completed” action for those assets.
• Windows match – This category matches Windows CVE details against assets’ Windows OS
version. Since installed Service Pack versions or Security Updates are not typically factored, it
is possible that non-vulnerable assets will still appear as vulnerable within this insight, due to
the inherent limitations of this type of matching. If this is the case, we recommend applying the
“Mark as Completed” action for those assets.
3.2.1. FULL MATCH CVES

This insight includes assets running vulnerable firmware/software versions and can be leveraged
by attackers for malicious purposes such as remote code execution or DDoS attacks. Vulnerabil-
ities are matched against these assets’ vendor name, model family and number, and software
version.
3.2.2. MODEL MATCH CVES

This insight includes assets that have unpatched vulnerabilities, based on their model family
and number. These vulnerabilities can be leveraged by attackers for malicious purposes such as
remote code execution and DDoS attacks. Vulnerabilities are matched against these assets’ vendor
name and model family and number.
Of note, due to inherent limitations in the Passive discovery method, this insight might not factor
in potential patches installed on the listed assets. Therefore, it is possible that assets will still
appear vulnerable, despite having already implemented security patches that resolve the vulnera-
bility.
3.2.3. PROGRAM MATCH CVES

This insight includes assets running programs that have known vulnerabilities. Therefore, they can
be leveraged by attackers for malicious purposes such as remote code execution or DDoS attacks.
Vulnerabilities are matched against these assets’ installed program versions.

Figure 6. Installed Program Match CVE table
3.2.4. VENDOR MATCH CVES

This insight is the most “imprecise” type of CVE matching, since it includes assets that might have
unpatched vulnerabilities by matching only the asset’s Vendor name against known vulnerabilities
for that Vendor. For this reason, this insight is liable to generate a significant volume of false
positives, where assets that are not actually vulnerable (for example, already patched) will appear
in the UI. If this is the case, we recommend applying the “Mark (All) as Completed” action to those
assets.
Figure 7. Vendor Match CVE table
3.2.5. WINDOWS CVES

This insight includes assets that might have unpatched Windows vulnerabilities. This insight only
considers the asset’s running Windows OS version and matches it against known vulnerabilities
published by Microsoft.
Of note, due to inherent limitations in the Passive discovery method, this insight might not factor
in potential Service Pack version or Security Updates (patches) installed on the listed assets. There-
fore, it is possible that assets will still appear vulnerable, despite having already implemented
security patches that resolve the vulnerability.

CTD Reference Guide Updating Insight Statuses
3.2.6. WINDOWS CVES FULL MATCH

This insight includes assets running a vulnerable Windows OS version, by matching it against
known vulnerabilities published by Microsoft. Vulnerabilities are matched against these Windows
assets’ version, build number and list of installed security patches.
3.3. Updating Insight Statuses

Test Users can update insights with the following statuses: COMPLETED, HIDDEN or OPEN, where
OPEN is the default status. This also ensures the Hygiene Score metrics are based only on relevant
data, based on the organization's specific policy and requirements. A HIDDEN or COMPLETED
insight would not appear by default when showing the list of insights, on the Insights page.
Comments can be applied to Insights, so the handling of the Insight could be managed per need.
For instance, this allows the user to keep track of the open vulnerabilities and their remediation
process.
To mark Insights with statuses:
1. Open the Insights section of the asset.

2. Mark the status as COMPLETED, HIDDEN, or OPEN.
Figure 8. Resolution Options for the Insights
OPEN
• OPEN is the default status and insights with this status will appear on the Insights page.
• OPEN means the insight still needs to be addressed, and as long as it is opened it negatively
affects the Hygiene Score.
HIDDEN
• After the user changes the insight status to HIDDEN, the insight will no longer be visible on the
Insights page. All hidden insights can be seen by applying the Insights Status > Hidden filter.
• Changing the insight status to HIDDEN, will not improve the overall Hygiene Score or the Risk
Score of the involved assets.

CTD Reference Guide Supported Vendor List for CVE
Matching
COMPLETED
• After the user changes the insight status to COMPLETED, the insight will no longer be visible on
the Insights page. All completed insights can be seen by applying the Insight Status > Completed
filter.
• Changing the insight status to COMPLETED, will improve the overall Hygiene Score or the Risk
Score of the involved assets.
3.4. Supported Vendor List for CVE Matching

• Siemens
• Rockwell Automation (including Rockwell Software)
• Yokogawa
• Omron
• Mitsubishi
• Hirschmann
• Beckhoff
• Cisco
• Schneider Electric
• ABB
• Emerson
• Google (partial support for Chromecast)
• GE
• Hikvision
• Microsoft (for Windows CVEs)
• VNC

CTD Reference Guide Discovery Methods
4. Discovery Methods
4.1. Active Detection

Active detection is when CTD actively tries to find assets and enrich data of existing ones by
querying devices using specific protocols.
4.1.1. CHANGES IN ALERTING FROM PASSIVE BEHAVIOR
• The following information changes generate an alert even in Training mode.

• Firmware
• Mode
• Last Program Installed Date
• Configuration Upload will only be triggered in case of changes (and not for same sections or first
time).
• Information change alerts will be generated in Operational mode for changes in non-custom
information.
All other information changes will not trigger any alerts in either Training or Operational Mode.
4.1.2. BASELINES GENERATED FROM ACTIVE DETECTION

Typically, in active detection, you don’t see baselines because it is not listening to the communica-
tion like in passive communication. In active detection, CTD communicates directly to the device.
However, if the cases fit one of the following scenarios, then active detection logs baselines:
1. SNMP Queries
a. TCP connections (current)
b. ARP connections (historical)
c. CDP connections (historical)
2. TCP Queries
a. UDP/TCP
4.1.3. PROFILES
Table 2. Summary Profiles Table
Task Name Description
B&R Profile (page 53) Uses proprietary B&R SNMP OIDs to collect information on B&R PLCs
Cisco Profile (page 53) Uses SNMP (page 98)
Hirschmann Profile (page 54) Basic: Telnet (page 114)
• Advanced: Telnet (page 114) + SNMP (page 98)
Mitsubishi Profile (page 54) • Simple: See Mitsubishi Melsoft Query

• Advanced: See Mitsubishi Melsoft Query

CTD Reference Guide Active Detection
Rockwell Profile (page 55) • Basic: EtherNet/IP (page 71)

• Advanced: CIP Configuration read
Siemens Profile (page 56) • Basic: S7 Basic (page 95)

• Advanced: S7 Configuration read
Siprotec 5 Profile (page 56) Basic HTTPS: Uses the Digsi5 HTTPS Protocol
Advanced HTTPS: Uses the Digsi5 HTTPS protocol to collect advanced information
Windows Profile • Basic: Net Bios (page 87)

• Medium: WMI Basic query (page 109)
• Advanced: WMI Advanced query (page 109)
4.1.3.1. B&R Profile
Table 3. B&R Profile
Task Name B&R Profile
Task Name 31
CTD Task Name B&R Profile
Description • Uses proprietary B&R SNMP OIDs to collect information on B&R PLCs
Port -
Target Devices B&R PLCs
Intrusive Level Low
Custom Info Fields • CF Serial Number

• Family
Sub Query V3
Sub Query Description Uses SNMP v3 with proprietary B&R properties
Parameters
Port
Meaning Port to access
Format number
Default 161
Example 1234
4.1.3.2. Cisco Profile
Table 4. Cisco Profile
Task Name Cisco Profile
Task ID 25
CTD Task Name Cisco Profile
Description • Uses SNMP
Port See SNMP (page 98)
Target Devices Cisco Devices
Intrusive Level Low
Custom Info Fields See SNMP (page 98)
Sub Query SNMP versions
Sub Query Description Use the SNMP protocol to query Cisco devices
Parameters

See SNMP (page 98)
4.1.3.3. Hirschmann Profile
Table 5. Hirschmann Profile
Task Name Hirschmann Profile
Task ID 21
CTD Task Name Hirschmann Profile
Description • Basic: Telnet

• Advanced: Telnet + SNMP
Port See Telnet (page 114), SNMP (page 98)
Target Devices Hirschmann
Intrusive Level Low
Custom Info Fields • See SNMP (page 98), Telnet (page 114)
Sub Queries
Sub Query Basic
Sub Query Description Uses the Telnet query to collect information
Parameters
See SNMP,Telnet
Sub Query Advanced
Sub Query Description Uses Telnet and SNMP to collect information
Parameters
See SNMP Query (page 98), Telnet (page 114)
See SNMP,Telnet
4.1.3.4. Mitsubishi Profile
Table 6. Mitsubishi Profile
Task Name Mitsubishi Profile
Task ID 45
CTD Task Name Mitsubishi Profile
Description See Mitsubishi Melsoft Query
Port 5002, 5007
Target Devices Mitsubishi PLCs
Intrusive Level Low
Sub Query Simple
Sub Query Description See Mitsubishi Melsoft Query
Sub Query Advanced
Sub Query Description See Mitsubish Melsoft Query
Parameters
IP
Meaning IP
Format ips
Default -

Example 10.1.39.1
Ports
Meaning ports
Format list of numbers
Default 5002, 5007
Example 5005
plc_side
Meaning type of connection in the side of the PLC (ethernet module/cpu)
Format dropdown
Default Ethernet Module
Example PLC Module
network number
Meaning network number we connect to - this is internal Mitsubishi parameter
Format number
Default 1
Example 4
pc station number
Meaning station number representing the engineering station - this is an internal Mitsubishi parameter
Format number
Default 1
Example 3
plc station number
Meaning station number representing the PLC - this is an internal Mitsubishi parameter
Format number
Default 0
Example 1
target system
Meaning target CPU number, in case of multi-CPU PLC
Format number
Default 0
Example 1
4.1.3.5. Rockwell Profile
Table 7. Rockwell Profile
Task Name Rockwell Profile
Task ID 24
CTD Task Name Rockwell Profile
Description • Basic: EtherNet/IP (page 71)

• Advanced: CIP Configuration (page 65) read
Port See ENIP (page 71), CIP (page 65)
Target Devices Rockwell Devices
Intrusive Level Potentially High
Custom Info Fields • See EtherNet/IP (page 71), CIP (page 65)
Sub Queries

Sub Query Basic
Sub Query Description Uses the IP Query
Sub Query Advanced
Sub Query Description Uses the TCP CIP HYBRID Query
Parameters
See EtherNet/IP (page 71), CIP (page 65)
4.1.3.6. Siemens Profile
Table 8. Siemens Profile
Task Name Siemens Profile
Task ID 23
CTD Task Name Siemens Profile
Description • Basic: S7 Basic

Port See S7
Target Devices Siemens Devices
Intrusive Level Low
Custom Info Fields • See S7Comm Query (page 95)
Sub Queries
Sub Query Basic
Sub Query Description Uses the S7Comm Basic Query (page 95)
Sub Query Advanced
Sub Query Description Uses the S7Comm Advanced Query (page 95)
Sub Query Advanced + SNMP
Sub Query Description Uses the S7Comm Advanced Query (page 95) as well as SNMP (page 98) (to also collect
communication information)
Parameters
See S7Comm Query (page 95)
4.1.3.7. IoT Query
Table 9. IoT Query
Task Name IoT Query
Task ID 36
CTD Task Name IoT Query
Description Uses the IoT matchers configured in the system to discover IoT devices
Port Depending on matchers
Target Devices IoT
Intrusive Level Medium
Custom Info Fields • Device dependent
Sub Query Generic
Sub Query Description Uses all IoT directed queries - banner, WSD, HTTP, HTTPS, SNMP

4.1.3.8. Profile Tables
B&R Profile
Table 10. B&R Profile
Task Name B&R Profile
Task Name 31
CTD Task Name B&R Profile
Description • Uses proprietary B&R SNMP OIDs to collect information on B&R PLCs
Port -
Intrusive Level Low

• Family
Sub Query V3
Parameters
Port
Format number
Default 161
Example 1234
Cisco Profile
Table 11. Cisco Profile
Task ID 25
CTD Task Name Cisco Profile
Description • Uses SNMP
Port See SNMP (page 98)
Target Devices Cisco Devices
Intrusive Level Low
Custom Info Fields See SNMP (page 98)
Sub Query SNMP versions
Sub Query Description Use the SNMP protocol to query Cisco devices
Parameters
See SNMP (page 98)
IoT Query
Table 12. IoT Query
Task Name IoT Query
Task ID 36
CTD Task Name IoT Query
Description Uses the IoT matchers configured in the system to discover IoT devices

Task Name IoT Query
Port Depending on matchers
Target Devices IoT
Sub Query Generic
Sub Query Description Uses all IoT directed queries - banner, WSD, HTTP, HTTPS, SNMP
Hirschmann Profile
Table 13. Hirschmann Profile
Task Name Hirschmann Profile
Task ID 21
CTD Task Name Hirschmann Profile
Description • Basic: Telnet

• Advanced: Telnet + SNMP
Port See Telnet (page 114), SNMP (page 98)
Target Devices Hirschmann
Intrusive Level Low
Custom Info Fields • See SNMP (page 98), Telnet (page 114)
Sub Queries
Sub Query Basic
Sub Query Description Uses the Telnet query to collect information
Parameters
See SNMP,Telnet
Sub Query Advanced
Sub Query Description Uses Telnet and SNMP to collect information
Parameters
See SNMP Query (page 98), Telnet (page 114)
See SNMP,Telnet
Mitsubishi Profile
Table 14. Mitsubishi Profile
Task ID 45
CTD Task Name Mitsubishi Profile
Description See Mitsubishi Melsoft Query
Port 5002, 5007
Intrusive Level Low
Sub Query Simple
Sub Query Description See Mitsubishi Melsoft Query
Sub Query Advanced
Sub Query Description See Mitsubish Melsoft Query
Parameters

IP
Meaning IP
Format ips
Default -
Example 10.1.39.1
Ports
Meaning ports
Format list of numbers
Default 5002, 5007
Example 5005
plc_side
Meaning type of connection in the side of the PLC (ethernet module/cpu)
Format dropdown
Example PLC Module
network number
Meaning network number we connect to - this is internal Mitsubishi parameter
Format number
Default 1
Example 4
pc station number
Meaning station number representing the engineering station - this is an internal Mitsubishi parameter
Format number
Default 1
Example 3
plc station number
Format number
Default 0
Example 1
target system
Format number
Default 0
Example 1
Rockwell Profile
Table 15. Rockwell Profile
Task ID 24
CTD Task Name Rockwell Profile
Description • Basic: EtherNet/IP (page 71)

• Advanced: CIP Configuration (page 65) read
Port See ENIP (page 71), CIP (page 65)

Custom Info Fields • See EtherNet/IP (page 71), CIP (page 65)
Sub Queries
Sub Query Basic
Sub Query Description Uses the IP Query
Sub Query Advanced
Sub Query Description Uses the TCP CIP HYBRID Query
Parameters
See EtherNet/IP (page 71), CIP (page 65)
Siemens Profile
Table 16. Siemens Profile
Task Name Siemens Profile
Task ID 23
CTD Task Name Siemens Profile
Description • Basic: S7 Basic

Port See S7
Target Devices Siemens Devices
Intrusive Level Low
Custom Info Fields • See S7Comm Query (page 95)
Sub Queries
Sub Query Basic
Sub Query Description Uses the S7Comm Basic Query (page 95)
Sub Query Advanced
Sub Query Description Uses the S7Comm Advanced Query (page 0 )
Sub Query Advanced + SNMP
Sub Query Description Uses the S7Comm Advanced Query as well as SNMP (page 98) (to also collect communication
information)
Parameters
See S7Comm Query (page 95)
Siprotec 5 Profile
Table 17. Siprotec 5 Profile
Task Name Siprotec 5 Profile
Task ID 33
CTD Task Name Siemens Siprotec 5 Profile
Description • SNMP: Uses the Siprotec 5 SNMP Query

• Basic HTTPS: Uses the Digsi5 HTTPS Protocol
• Advanced HTTPS: Uses the Digsi5 HTTPS protocol to collect advanced information
Port See SNMP
Target Devices Siprotec 5 relays

Intrusive Level Low
Custom Info Fields See relevant queries
Sub Queries SNMP, Basic HTTPS, Advanced HTTPS
Sub Query SNMP
Sub Query Description Uses the Siprotec 5 SNMP Query (page 100)
Sub Query Basic HTTPS
Sub Query Description Uses the Basic HTTPS Digsi5 (i.e. Siprotec5) Query (page 105)
Sub Query Advanced HTTPS
Sub Query Description Uses the Advanced HTTPS Digsi5 (i.e. Siprotec5) Query (page 105)
Parameters
See Siprotec 5 SNMP Query
Windows Profile
Table 18. Windows Profile
Task Name Windows Profile
Task ID 22
CTD Task Name Windows Profile
Description Basic: NetBios
Port See NetBios, WMI
Target Devices Windows Hosts
Custom Info Fields See Net Bios (page 87), WMI (page 109)
Sub Queries
Sub Query Basic
Sub Query Description Uses the Net Bios (page 87) Query
Sub Query Medium
Sub Query Description Uses the WMI (page 109) Basic Query
Sub Query Advanced
Sub Query Description Uses the WMI (page 109) Advanced Query
Sub Query Advanced WinRM
Sub Query Description Uses the WinRM (page 111)Advanced Query
Parameters
See NetBios, WMI
4.1.3.9. Siprotec 5 Profile
Table 19. Siprotec 5 Profile
Task ID 33
CTD Task Name Siemens Siprotec 5 Profile
Description • SNMP: Uses the Siprotec 5 SNMP Query

• Basic HTTPS: Uses the Digsi5 HTTPS Protocol
• Advanced HTTPS: Uses the Digsi5 HTTPS protocol to collect advanced information
Port See SNMP

Intrusive Level Low
Custom Info Fields See relevant queries
Sub Queries SNMP, Basic HTTPS, Advanced HTTPS
Sub Query SNMP
Sub Query Description Uses the Siprotec 5 SNMP Query (page 100)
Sub Query Basic HTTPS
Sub Query Description Uses the Basic HTTPS Digsi5 (i.e. Siprotec5) Query (page 105)
Sub Query Advanced HTTPS
Sub Query Description Uses the Advanced HTTPS Digsi5 (i.e. Siprotec5) Query (page 105)
Parameters
See Siprotec 5 SNMP Query
4.1.3.10. Windows Profile
Table 20. Windows Profile
Task Name Windows Profile
Task ID 22
CTD Task Name Windows Profile
Description Basic: NetBios
Port See NetBios, WMI
Custom Info Fields See Net Bios (page 87), WMI (page 109)
Sub Queries
Sub Query Basic
Sub Query Description Uses the Net Bios (page 87) Query
Sub Query Medium
Sub Query Description Uses the WMI (page 109) Basic Query
Sub Query Advanced
Sub Query Description Uses the WMI (page 109) Advanced Query
Sub Query Advanced WinRM
Sub Query Description Uses the WinRM (page 111)Advanced Query
Parameters
See NetBios, WMI
4.1.4. QUERIES
Queries query distinct devices using specific protocols and need a specific IP or IP ranges.
Table 21. Summary Queries Table
Atlas Copco Open Protoco Atlas Copco Open Protocol Query. (Protocol needs to be enabled for this query).
Query (page 61)
BACnet Query (page 63) Query a device using the BACnet protocol

Beckhoff Query (page 64) Query using the Beckhoff AMS protocol
B&R HTTP Query (page 61) Use the B&R Automation SDM web interface to get information about the PLC
B&R Query (page 61) Uses proprietary B&R SNMP OIDs to collect information on B&R PLCs
CIP Query (page 65) Uses CIP to query PLCs for information and scan for nested devices
Cognex Query (page 67) Uses Cognex Discovery protocol to find basic information about Cognex devices (usually
cameras)
CrowdStrike Query (page 67) Retrieves data about a device running CrowdStrike Sensor and uses AppDB to parse OT
projects existing on it
CTI Query (page 66) Uses the CTI Proprietary protocol to query CTI2500 PLCs
DB Enumeration Finds different installed DBs

Query (page 69)
DNP3 (page 70) Reads the Identity object from the RTU using DNP3 protocol
ENIP Query (page 71) Uses EtherNet/IP List Identity message to identify PLCs in the network
Exi 3000 Query (page 72) Exi 3000 Query over TCP
Focas Query (page 73) Fanuc Focas query over TCP
GE SRTP (page 73) Uses TCP GE-SRTP (TCP port 18245) to get GE PLC information
GE Station Manager Uses UDP Unicast GE Station Manager to get GE rx3i/rx7i device information
Query (page 74)
Hirschmann Discovery Queries Hirschmann switches using the HiDiscovery protocol

Query (page 76)
HTTP Query (page 75) Uses HTTP to get the home page of a device and extract information
Indraworks Query (page 77) Uses UDP in unicast to query Bosch IndraDrive devices
Lantronix Unicast Uses the Lantronix Discovery Protocol (LDP) in unicast to query Lantronix devices
Query (page 77)
mDNS Query (page 78) Uses the mDNS protocol to query devices. Uses mDNS matchers.
Mitsubishi Beijer HMI Queries Beijer E1000 HMIs

Query (page 80)
Mitsubishi GOT Establishes a GOT connection to query Mitsubishi GOT 1000 and 2000 HMIs
Query (page 82)
Mitsubishi Melsoft Using proprietary Mitsubishi Melsoft protocol to connect to Mitsubishi PLCs
Query (page 83)
MMS Query (page 78) Uses the IEC 61850 MMS Protocol over TCP to query ABB and other MMS-supporting
devices
Modbus Information Ob- Uses the Modbus protocol Get Information command to query PLCs
ject (page 85)
Moxa Broadcast Uses Moxa broadcast search to find Moxa devices- sent in multicast
Scan (page 85)
Moxa Unicast Scan (page 86) Uses Moxa broadcast search to find Moxa devices- sent in unicast
MS SQL (page 80) Uses TDS and SQL browser protocols to find MS SQL installations
Net Bios (page 87) Uses the Windows NetBIOS service to learn the hostname and OS version. Also uses
SMBv1
Omron FINS Query (page 87) Omron FINS protocol query over UDP/TCP
Opto22 Query (page 89) Uses the Opto22 protocol to query Opto PAC PLCs
PCCC Query (page 89) Query to extract code sections and slots from Rockwell SLC5 devices
P+F DCP Query (page 89) Collecting information about wireless gateways by Pepperl+Fuchs
Profinet-DCP Query (page 91) Uses the Profinet-DCP broadcast message to detect devices
RAFT Gateway Welding Technology Corp. (WTC) RAFT Gateway query over HTTP
Query (page 93)

Reverse DNS (page 93) Reverse DNS resolution is the querying technique of DNS to determine the domain
name associated with an IP address using PTR records.
S7CommPlus Query (page 96) S7CommPlus is a Siemens proprietary protocol that runs between programmable logic
controllers of the Siemens S7-1200/1500 family.
S7Comm Query (page 95) Uses the Siemens S7Comm to query PLCs for information and nested devices
Schneider TSX Uses the PL7 software proprietary protocol to query Schneider TSX devices
Query (page 102)
Schneider Unity Uses the Schneider Unity Modbus function code 90 to query PLCs
Query (page 103)
Sinumerik Query (page 104) Queries the Sinumerik series of Siemens CNC control systems
Siprotec Query (page 105) Uses the Siprotec protocol to query RTUs
SNMP Network Layout Using SNMP and a starting IP, the query recursively gets information about network
Query (page 97) switches and devices, and gets the entities connected to their interfaces
SNMP Query (page 98) Uses the SNMP Protocol to query devices for information
SNMP Siprotec 5 (page 100) Uses SNMP to query the Siprotec5 proprietary OIDs via SNMP
Speedwire Query (page 105) SMA Speedwire query over UDP
SSH Discovery (page 101) Uses SSH to remotely connect and collect data from SSH supporting servers
TBox Query (page 107) Ovarro TBox General Info Query
TCP Port Scan (page 113) TCP Port scanning
Telnet (page 114) Performs a telnet banner grabbing. Extracts info from Scalance, Hirschmann switches
Tridium Fox Query (page 106) Uses the Tridium Fox Protocol to query Tridium stations
Ubiquiti Query (page 107) Uses the Ubiquiti discovery protocol to query Ubiquiti devices
Unitronics Query (page 108) Uses the PCOM-TCP protocol to query Unitronics PLCs
WAGO Query (page 108) Uses IOCHECKD protocol to get basic information on a specific WAGO device
WinRM Query (page 111) Uses WinRM protocol to query information about Windows computers, using WMI and
registry. Uses SOAP over HTTP and must be configured
WMI Query (page 109) Uses WMI to query Windows hosts for information
WSD Query (page 110) Uses WSD and ONVIF to find network devices, based on the WSD IoT Matchers

4.1.4.1. Atlas Copco Open Protocol Query
Table 22. Atlas Copco Open Protocol Query
Task Name Atlas Copco Open Protocol Query
Task Name 87
CTD Task Name Atlas Open Protocol Query
Description Atlas Copco Open Protocol Query. (Protocol needs to be enabled for this query.)
Port 4545 (TCP)
Target Devices Atlas Copco devices with Open Protocol enabled.
Intrusive Level Low
Custom Info Fields --
Sub Query Generic
Sub Query Description Atlas Copco Open Protocol Query. (Protocol needs to be enabled for this query.)
Potential Information Collected IP, Serial, Firmware, Hostname, Vendor
Parameters
Port
Format Number
Default 4545
Example 1234
4.1.4.2. B&R HTTP Query
Table 23. B&R HTTP Query
Task Name B&R HTTP Query
Task ID 63
CTD Task Name B&R HTTP Query
Description Use the B&R Automation SDM web interface to get information about the PLC
Port 80 (TCP)
Intrusive Level
Custom Info Fields family, default gateway
Sub Query Generic
Sub Query Description Use the B&R Automation SDM web interface to get information about the PLC
Potential Information Collected hostname, entity type, model, firmware
4.1.4.3. B&R Query
Table 24. B&R Query
Task Name B&R Query
Task ID 30
CTD Task Name B&R Automation SNMP Query
Description Uses proprietary B&R SNMP OIDs to collect information on B&R PLCs
Ports -
Intrusive Level Low

Task Name B&R Query

• Family
Sub Query V3
Parameters
Port
Format number
Default 161
Example 1234

4.1.4.4. BACnet Query
Table 25. BACnet Query
Task Name BACnet Query
Task ID 28
CTD Task Name BACnet Query
Description Query a device using the BACnet protocol
Port 47808
Target Devices Mainly BMS controllers
Intrusive Level Low
Custom Info Fields • Object Name

• Application Software Version
• Location
• Description
• Object Identifier
Sub Query Generic
Sub Query Description Uses BACnet requests to collect information about devices
Potential Information Collected Firmware, Model, Application version, Object Name, hostname, Location, Object ID, Ven-
dor, IP, Description
Parameters
IP
Meaning IP of the target
Format IP
Default -
Example 10.0.0.1
Use Object ID as Hostname
Meaning Should use the BACnet Object ID as the hostname of the target
Format Checkbox
Default TRUE
Example FALSE

4.1.4.5. Beckhoff Query
Table 26. Beckhoff Query
Task Name Beckhoff Query
Task ID 26
CTD Task Name Beckhoff Query
Description Query using the Beckhoff AMS protocol
Ports 48898, 48899
Target Devices Beckhoff Devices
Intrusive Level Low
Custom Info Fields • N/A
Sub Query Generic
Sub Query Description Uses the Beckhoff AMS protocol to collect information on Beckhoff devices
Potential Information Collected IP, hostname, OS, firmware, model, vendor, serial, installed programs, patches
Parameters
IP
Format IP
Default -
Example 10.0.0.1

4.1.4.6. CIP Query
Table 27. CIP Query
Task Name CIP Query
Task ID 10
CTD Task Name CIP Query
Description Uses CIP to query PLCs for information and scan for nested devices
Port 44818
Sub Queries TCP CIP, TCP CIP CONFIGURATION (page 65), TCP CIP HYBRID (page 65)
Sub Query TCP IP
Sub Query Description Queries the controller for basic information using the CIP Identity request
Potential Information Collected IP, Model, Vendor, Serial, Firmware
Sub Query TCP CIP DEEP
Sub Query Description Queries the controller for information. Also scans for nested devices
Potential Information Collected IP, model, vendor, serial, slots, Mac, code sections, nested devices, firmware
Sub Query TCP CIP CONFIGURATION
Sub Query Description Performs Configuration Upload from the controller. Allows gathering information,
nested devices, and code sections.
Sub Query TCP CIP HYBRID
Sub Query Description Combines both CIP Configuration upload and CIP Deep sub queries methodology. The
sub query first retrieves the queried device configuration and extract all of the slots
and nested devices. After retrieval it will initiate a scan of only these devices and get
the current information from the devices. This methodology reduces the need to scan
wide address ranges to detect slots and nested devices.
Parameters
IP
Format IP
Default -
Example 10.0.0.1
Port
Format Number
Default 44818
Example 1234
Max Inner Depth
Meaning How deep the nested hierarchy should go
Format Number
Default 4
Example 3
Scanning Timeout
Meaning Timeout for scan responses

Task Name CIP Query
Format Number (seconds)
Default 5
Example 10
Specific Address
Meaning Query specific CIP address
Format Card X \ Addr Y
Default -
Example Card 2 \ Addr 53
Scanning Try Best Effort
Meaning Should try best effort for nested scans
Format Bool
Default TRUE
Example FALSE
Device Network Subnet
Meaning External subnet of the Rockwell device
Format CIDR subnet
Default ***If not given, the default is Class C of the GIVEN IP
Example 10.0.0.0/24
4.1.4.7. CTI Query
Table 28. CTI Query
Task Name CTI Query
Task ID 46
CTD Task Name CTI Query
Description Uses the CTI Proprietary protocol to query CTI2500 PLCs
Port 1069
Target Devices CTI2500 PLCs
Intrusive Level Low
Custom Info Fields • Rack Firmware
Sub Query Generic
Sub Query Description Uses the CTI Proprietary protocol to query CTI2500 PLCs
Potential Information Collected IP, Vendor, Family, Model, Firmware, Rack Firmware
Parameters
Port
Format number
Default 1505
Example 1000

4.1.4.8. Cognex Query
Table 29. Cognex Query
Task Name Cognex Query
Task Name 38
CTD Task Name Cognex Query
Description Uses Cognex Discovery protocol to find basic information about Cognex devices (usu-
ally cameras)
Port 1069
Target Devices Cameras and related devices
Intrusive Level Low
Custom Info Fields • Description
Sub Queries
Sub Query Generic
Sub Query Description Uses the Cognex Discovery protocol to identify and collect information from Cognex
devices
Potential Information Collected IP, hostname, Mac, serial, model, firmware, description
Parameters
Port
Format number
Default 1069
Example 51069
4.1.4.9. CrowdStrike Query
Table 30. CrowdStrike Query
Task Name CrowdStrike Query
Task ID 54
CTD Task Name CrowdStrike Query
Description Retrieves data about a device running CrowdStrike Sensor and uses AppDB to parse
OT projects existing on it.
Port 443 (TCP) - Internet Access
Custom Info Fields • -
Sub Queries
Sub Query Basic
Sub Query Description Retrieves data about a device running CrowdStrike Sensor
Potential Information Collected Installed Programs
Parameters
Client ID
Meaning CrowdStrike Client ID
Format numbers and letters a-f
Default -
Example f3bac176a05c544492e83aba9cba08fe

Client Secret
Meaning CrowdStrike Client Secret of Client ID
Format Numbers and letters
Default -
Example F5sd3J8f3wer67Plk
Cloud
Meaning CrowdStrike Cloud
Format dropdown
Default US
Example US-2
Sub Query Advanced
Sub Query Description Retrieves data about a device running CrowdStrike Sensor and uses AppDB to parse
Potential Information Collected On CrowdStrike Sensor: Installed Programs
On Devices from AppDB Files: IP, Mac, Hostname, Model, Firmware, Slots
Parameters
Client ID
Default -
Client Secret
Default -
Cloud
Format dropdown
Default US
Example US-2
Max Recent Files
Meaning Max number of AppDB files to retrieve from Recent Files
Format number (1-50)
Default 20
Example 15
Should Use Windows Recently Opened Files
Meaning Should Use Windows Recently Opened Files (or only from AppDB locations)
Format checkbox
Default FALSE
Example TRUE
Should Get Project Files From Remote Paths
Meaning Should Get Project Files From Remote Paths like \\server-pc\files\my_file.acd
Format checkbox

Default FALSE
Example TRUE
4.1.4.10. DB Enumeration Query
Table 31. DB Enumeration Query
Task Name DB Enumeration Query
Task ID 52
CTD Task Name DB Enumeration Query
Description Finds different installed DBs
Port 1433, 3306 (TCP), 1434 (UDP)
Target Devices DB Servers
Intrusive Level -
Custom Info Fields -
Sub Query Generic
Sub Query Description -
Parameters
MSSQL
Meaning Should query for MSSQL Servers
Format Checkbox
Default True
Example False
MySQL
Meaning Should query for MySQL Servers
Format Checkbox
Default True
Example False

4.1.4.11. DNP3 Query
Table 32. DNP3 Query
Task Name DNP3 Query
Task ID 54
CTD Task Name DNP3 Query
Description Reads the Identity object from the RTU using the DNP3 protocol
Port 20000
Target Devices Devices that implement the Identity object within DNP (PLCs, RTUs, IEDs)
Intrusive Level Low
Custom Info Fields • User Assigned Location

• Device Manufacturer HW version
• Device Manufacturer SW Version
Sub Query Generic
Sub Query Description Use the DNP3 Information Object to query devices with this function implemented
Potential Information Collected Serial, hostname, model, vendor, HW version, SW version, location
Parameters
IP
Format IP address
Default -
Example 10.0.0.1
Port
Format Number
Default 20000
Example 20000
Protocol
Meaning Transmission protocol to use
Format TCP or UDP
Default TCP
Example UDP
Unit ID
Meaning DNP3 unit ID
Format Number
Default 0
Example 1

4.1.4.12. ENIP Query
Table 33. EtherNet/IP Query
Task Name EtherNet/IP Query
Task ID 11
CTD Task Name EtherNet/IP Query
Description Uses EtherNet/IP List Identity message to identify PLCs in the network
Port 44818
Intrusive Level Low
Sub Query UDP Unicast
Sub Query Description Use the EtherNet/IP Identity Request command to collect basic information on Ether-
Net/IP compatible devices
Potential Information Collected IP, model, vendor, serial, firmware
Parameters
IP
Format IP
Default -
Example 10.0.0.1

4.1.4.13. Exi 3000 Query
Table 34. Exi 3000 Query
Task Name Exi 3000 Query
Task ID 95
CTD Task Name Exi 3000 Query
Description Uses the Siemens S7comm to query PLCs for information and nested devices
Port 3000
Target Devices EX-i 3000 Flow Computers
Custom Info Fields
Sub Queries
Sub Query Basic
Sub Query Description UDP Unicast to get model and hostname, gets device Information over TCP
Potential Information Collected IP, Entity Type, Vendor, Model, Hostname over UDP, Serial, Firmware, Slots
Sub Query Advanced
Sub Query Description Runs Basic query and gets extra interfaces and hostname
Potential Information Collected Information from Basic + all interfaces, hostname over TCP
Parameters
Port
Format Number
Default 3000
Example 1234
IP
Meaning IP
Format String
Default -
Example 1.1.1.1

4.1.4.14. Focas Query
Table 35. Focas Query
Task Name Focas Query
Task Name 88
CTD Task Name Fanuc Focas Query
Description Fanuc Focas query over TCP
Port 8193 (TCP)
Target Devices Fanuc CNCs
Intrusive Level Low
Custom Info Fields Mode, Series, Order Number (MLFB)
Sub Query Generic
Sub Query Description Fanuc Focas query over TCP
Potential Information Collected IP, Series, Model, Firmware, Mode, Serial, Order Number (MLFB), Vendor, Entity Type
Parameters
IP
Meaning IP
Format String
Default -
Example 1.1.1.1
Port
Format Number
Default 8193
Example 1234
4.1.4.15. GE SRTP
Table 36. GE SRTP
Task Name GE SRTP
Task ID 61
CTD Task Name GE SRTP
Description Uses TCP GE-SRTP (TCP port 18245) to get GE PLC information
Port 18245 (TCP)
Target Devices GE PLCs
Intrusive Level
Custom Info Fields
Sub Query Generic
Sub Query Description Uses TCP GE-SRTP to get GE PLC information
Potential Information Collected vendor, model, firmware, serial, type, mac address, slots
Parameters
IP
Meaning IP
Format String
Default- -

Task Name GE SRTP
Example 1.1.1.1
4.1.4.16. GE Station Manager Query
Table 37. GE Station Manager Query
Task Name GE Station Manager Query
Task ID 58
CTD Task Name GE Station Manager
Description Uses UDP Unicast GE Station Manager to get GE rx3i/rx7i device information
Port 18245 (UDP)
Target Devices GE rx3i/rx7i PLCs
Intrusive Level
Custom Info Fields
Sub Query UDP UNICAST
Sub Query Description Uses UDP Unicast GE Station Manager to get GE rx3i/rx7i device information
Potential Information Collected vendor, model, firmware, serial, type, mac address
Parameters
port
Format number
Default 18245
Example 18245
IP
Meaning IP
Format String
Default -
Example 1.1.1.1

4.1.4.17. HTTP Query
Table 38. HTTP Query
Task Name HTTP Query
Task ID 34
CTD Task Name HTTP Query
Description Uses HTTP to get the home page of a device and extract information
Port Depending on registered IoT matchers - 80, 443
Target Devices Devices with HTTP Access
Intrusive Level Low
Sub Queries
Sub Query HTTP
Sub Query Description Uses HTTP to access devices
Potential Information Collected Matcher Dependent
Sub Query HTTPS
Sub Query Description Uses HTTPS to access devices
Parameters
Port
Format number
Default 161
Example 1234

4.1.4.18. Hirschmann Discovery Query
Table 39. Hirschmann Discovery Query
Task Name Hirschmann Discovery Query
Task ID 8
CTD Task Name HiDiscoveryQuery
Description Queries Hirschmann switches using the HiDiscovery protocol
Port -
Target Devices Hirschmann devices
Intrusive Level Low
Sub Query Single Device
Sub Query Description Use the Hirschmann HiDiscovery protocol to query Hirschmann devices (2nd layer)
Potential Information Collected Model, vendor, IP, mac, hostname
Parameters
Interface name
Meaning Network interface on the machine from which the packets are sent
Format String
Default -
Example en192
MAC address
Meaning MAC address of the target device
Format MAC address string
Default -
Example 112233445566

4.1.4.19. Indraworks Query
Table 40. Indraworks Query
Task Name Indraworks Query
Task ID 92
CTD Task Name Indraworks Query
Description Uses UDP in unicast to query Bosch IndraDrive devices
Port 35021 (UDP), 35021 (TCP)
Target Devices Bosch IndraDrive devices
Intrusive Level Low
Custom Info Fields Type code, Series
Sub Queries
Sub Query UDP-Unicast
Sub Query Description
Potential Information Collected IP, Vendor, Firmware, Family, Default Gateway, Serial Number, Entity Type, Model,
Type Code, Series
Sub Query TCP-Query
Potential Information Collected IP, Vendor, Firmware, Family, Default Gateway, Serial Number, Entity Type, Model,
Type Code, Series
Parameters
IP
Meaning IP
Format string
Default -
Example 1.1.1.1
Port
Format number
Default 35021
Example 1234
4.1.4.20. Lantronix Unicast Query
Table 41. Lantronix Unicast Query
Task Name Lantronix Unicast Query
Task ID 72
CTD Task Name Lantronix Query
Description Uses the Lantronix Discovery Protocol (LDP) in unicast to query Lantronix devices
Port 30718(UDP)
Target Devices Lantronix Devices
Intrusive Level
Custom Info Fields
Sub Query Generic
Potential Information Collected IP, MAC, Vendor, Model, Hostname, Firmware

Task Name Lantronix Unicast Query
Parameters
IP
Meaning IP
Format string
Default
Example 1.1.1.1
4.1.4.21. mDNS Query
Table 42. mDNS Query
Task Name mDNS Query
Task ID 62
CTD Task Name mDNS Query
Description Uses the mDNS protocol to query devices. Uses mDNS matchers.
Port 5353 (UDP)
Target Devices IoT devices, Apple devices
Intrusive Level
Custom Info Fields
Sub Query Generic
Sub Query Description mDNS Query - Uses the mDNS protocol in unicast to query devices.
Potential Information Collected hostname, entity type, everything supported by IoT matchers
Parameters
Extended services
Meaning whether to use all known services (more network load), or just the main ones
Format Checkbox
Default FALSE
Example TRUE
4.1.4.22. MMS Query
Table 43. MMS Query
Task Name MMS Query
Task ID 74
CTD Task Name MMS Query
Description Uses the IEC 61850 MMS Protocol over TCP to query ABB and other MMS-supporting
devices
Port 102 (TCP)
Target Devices MMS-supporting IEDs/RTUs
Intrusive Level Low
Custom Info Fields Depends on the matcher
Sub Query Generic
Potential Information Collected IP, model, vendor, firmware (ABB Devices). For other devices- depends on the match-
er
Parameters

Task Name MMS Query
IP
Meaning IP
Format string
Default
Example 1.1.1.1
Port
Format Number
Default 102
Example 1234

4.1.4.23. MS SQL
Table 44. MS SQL Query
Task Name MS SQL Query
Task ID 52
CTD Task Name MS SQL Query
Description Uses TDS and SQL browser protocols to find MS SQL installations
Port 1433 (TCP), 1434 (UDP)
Intrusive Level Low
Custom Info Fields
Sub Query Generic
Sub Query Description Uses TDS and SQL browser protocols to find MS SQL installations
4.1.4.24. Mitsubishi Beijer HMI Query
Table 45. Mitsubishi Beijer HMI Query
Task Name Mitsubishi Beijer HMI Query
Task ID 85
CTD Task Name Beijer HMI Query
Description Queries Beijer E1000 HMIs
Port 6001 (TCP)
6000 (TCP)
5900 (TCP)
23 (TCP)
Target Devices Beijer HMIs
Intrusive Level Low
Sub Query Generic
Potential Information Collected IP, Vendor, Model, Entity Type, Firmware
Parameters
IP
Meaning IP
Format String
Default -
Example -
Terminal Control Port
Meaning Terminal Control Port to access for Beijer HMIs
Format Number
Default 6001
Example 1234
Transfer Port
Meaning Transfer Port to access for Beijer HMIs

Task Name Mitsubishi Beijer HMI Query
Format Number
Default 6000
Example 1234
Automatic Terminal Run/Transfer Switching (intrusive)
Meaning Whether to use a mechanism to extract information that requires changing the device
mode
Format Checkbox
Default FALSE
Example FALSE

4.1.4.25. Mitsubishi GOT Query
Table 46. Mitsubishi GOT Query
Task Name Mitsubishi GOT Query
Task ID 84
CTD Task Name Mitsubishi GOT Query
Description Establishes a GOT connection to query Mitsubishi GOT 1000 and 2000 HMIs
Port 5014 (TCP), 5015 (TCP)
Target Devices Mitsubishi HMIs
Intrusive Level Low
Sub Query Generic
Potential Information Collected IP, Vendor, Model, Entity Type, Firmware
Parameters
IP
Meaning IP
Format string
Default -
Example 10.1.39.1
GOT 1000 Port
Meaning Port to access for GOT1000 HMIs
Format Number
Default 5014
Example 1234
GOT 2000 Port
Meaning Port to access for GOT2000 HMIs
Format Number
Default 5015
Example 1234

4.1.4.26. Mitsubishi Melsoft Query
Table 47. Mitsubishi Melsoft Query
Task Name Mitsubishi Melsoft Query
Task ID 44
CTD Task Name Melsoft Query
Description Using proprietary Mitsubishi Melsoft protocol to connect to Mitsubishi PLCs
Port 5002 (TCP), 5007 (TCP)
Intrusive Level Low
Sub Query Simple
Sub Query Description Requires only parameters and only detects whether the PLC is a Mitsubishi PLC
Potential Information Collected IP, vendor
Sub Query Medium
Sub Query Description Requires most parameters and should extract most relevant data.
Potential Information Collected IP, vendor, firmware, model, slots
Sub Query Intelligent
Sub Query Description Requires very few parameters and makes assumptions about common default config-
uration for Mitsubishi devices to gather the most information. This will not work for
advanced configuration for certain devices.
Sub Query Advanced
Sub Query Description Adds target system as well, which is relevant for multi-CPU PLCs.
Parameters
IP
Meaning IP
Format ips
Default -
Example 10.1.39.1
plc_side
Meaning type of connection in the side of the PLC (ethernet module/cpu/auto select)
Format dropdown
Example PLC Module
network and station numbers setting method
Meaning manually choose values, or automatically choose according to IP (e.g. if ip is 10.1.39.5,

network number will be 39, plc station number will be 5)
Format dropdown
Default Not Use IP Address
Example Use IP Address
network number
Meaning network number we connect to- this is internal Mitsubishi parameter
Format number
Default 1
Example 4

Task Name Mitsubishi Melsoft Query
pc station number
Meaning station number representing the engineering station - this is an internal Mitsubishi
parameter
Format number
Default 1
Example 3
plc station number
Format number
Default 1
Example 2
target system
Format number
Default 0
Example 1

4.1.4.27. Modbus Information Object
Table 48. Modbus Information Object
Task Name Modbus Information Object
Task ID 15
CTD Task Name Modbus Query
Description Uses the Modbus protocol Get Information command to query PLCs
Port 502
Target Devices Modbus masters - PLCs
Intrusive Level Low
Custom Info Fields • Product Code
Sub Query Generic
Sub Query Description Use the Modbus Information Object to query devices with this function implemented
Potential Information Collected Vendor, product code, model, project name
Parameters
IP
Format IP address
Default -
Example 10.0.0.1
Port
Format Number
Default 502
Example 1234
Unit ID
Meaning Modbus Unit ID
Format Number list
Default 0
Example 0-10,15
Is a gateway
Meaning Determine whether querying a gateway and the PLCs are nested
Format Boolean
Default FALSE
Example TRUE
4.1.4.28. Moxa Broadcast Scan
Table 49. Moxa Broadcast Scan
Task Name Moxa Broadcast Scan
Task ID 69
CTD Task Name Moxa Discovery
Description Uses Moxa broadcast search to find Moxa devices- sent in multicast
Port 4800 (UDP)
Target Devices Moxa Devices

Task Name Moxa Broadcast Scan
Intrusive Level
Custom Info Fields
Sub Query Broadcast
Sub Query Description Uses the Moxa Discovery protocol to discover Moxa devices
Potential Information Collected IP, MAC, Vendor, Model
4.1.4.29. Moxa Unicast Scan
Table 50. Moxa Unicast Scan
Task Name Moxa Unicast Scan
Task ID 70
CTD Task Name Moxa Query
Description Uses Moxa broadcast search to find Moxa devices- sent in unicast
Port 4800 (UDP)
Target Devices Moxa Devices
Intrusive Level
Custom Info Fields
Sub Query Unicast
Sub Query Description Uses the Moxa Discovery protocol to query Moxa devices
Potential Information Collected IP, MAC, Vendor, Model
Parameters
IP
Meaning IP
Format string
Default
Example 1.1.1.1

4.1.4.30. Net Bios
Table 51. Net Bios
Task Name Net Bios
Task ID 4
CTD Task Name NetBiosQuery
Description Uses the Windows NetBIOS service to learn the hostname and OS version. Also uses
SMBv1
Ports 137, 138, 445
Target Devices Windows devices
Intrusive Level Low
Sub Query Generic
Sub Query Description Use the NetBios Protocol to interrogate Windows devices using this basic discovery
protocol
Potential Information Collected OS, hostname, SMB server version, Mac, IP
Parameters
IP
Format IP address
Default -
Example 10.0.0.1
Port
Meaning Port to use for SMBv1
Format Number
Default 139
Example 445
4.1.4.31. Omron FINS Query
Table 52. Omron FINS Query
Task Name Omron FINS Query
Task ID 75
CTD Task Name FINS Query
Description Omron FINS protocol query over UDP/TCP
Ports 9600 (TCP/UDP)
Target Devices Omron Devices
Intrusive Level Low
Sub Query Generic
Potential Information Collected IP, Vendor, Firmware, Serial, Hostname, Slots, Mode, Entity type
Parameters
Port
Format Number

Task Name Omron FINS Query
Default 9600
Example 1234

4.1.4.32. Opto22 Query
Table 53. Opto22 Query
Task Name Opto22 Query
Task ID 48
CTD Task Name Opto22 Query
Description Uses the Opto22 protocol to query Opto PAC PLCs
Port 22001 (TCP)
Target Devices Opto PAC PLCs
Intrusive Level Low
Sub Queries
Sub Query Basic
Sub Query Description Uses the protocol to collect basic information
Potential Information Collected Model, Firmware, Loader Revision, Project Information
Sub Query Advanced
Sub Query Description Uses the protocol to also upload the strategy archive from the device, if exists
Potential Information Collected Model, Firmware, Loader Revision, Project Information
Parameters
Port
Format number
Default 22001
Example 1234
4.1.4.33. P+F DCP Query
Table 54. P+F DCP Query
Task Name P+F DCP Query
Task ID 64
CTD Task Name P+F DCP Query
Description Collecting information about wireless gateways by Pepperl+Fuchs
Port 25062 (UDP)
Target Devices Pepperl+Fuchs
Intrusive Level
Custom Info Fields family, firmware revision
Sub Query Generic
Sub Query Description Pepperl+Fuchs Discovery and Configuration Protocol
Potential Information Collected IP, MAC, Vendor, Model, Firmware, Firmware Revision, Family
4.1.4.34. PCCC Query
Table 55. PCCC Query
Task Name PCCC Query
Task ID 57
CTD Task Name PCCC Query

Task Name PCCC Query
Description Query to extract code sections and slots from Rockwell SLC5 devices
Port 44818 (TCP)
Target Devices Rockwell SLC5 devices
Intrusive Level
Custom Info Fields
Sub Query Generic
Sub Query Description Query to extract code sections and slots from Rockwell SLC5 devices
Potential Information Collected ip, code sections, slots, vendor
Parameters
IP
Meaning IP
Format string
Default -
Example 1.1.1.1

4.1.4.35. Profinet-DCP Query
Table 56. Profinet-DCP Query
Task Name Profinet-DCP Query
Task ID 13
CTD Task Name ProfinetQuery
Description Uses the Profinet-DCP broadcast message to detect devices
Port -
Target Devices Siemens devices
Intrusive Level Low
Sub Query UDP Unicast
Sub Query Description Use the Profinet-DCP information collection packet to discover (layer 2) relevant net-
work devices
Potential Information Collected IP, model, hostname, vendor, mac
Parameters
Interface name
Meaning Network interface on the machine from the packets are sent
Format String
Default -
Example en192
MAC address
Meaning MAC address of the target device
Format MAC address string
Default -
Example 112233445566
VLAN
Meaning VLAN tag number
Format 300,599,601
Default -
Example Applicable only via trunk port with native VLAN

4.1.4.36. Profinet-DCP Scan
Table 57. Profinet-DCP Scan
Task Name Profinet-DCP Scan
Task ID 14
CTD Task Name ProfinetScan
Port -
Intrusive Level Low
Custom Info Fields • Custom Labels
Sub Query DCP Broadcast
Sub Query Description Use the Profinet-DCP information collection broadcast packet to discover (layer 2)
relevant network devices
Parameters
Interface name
Format string
Default -
Example en192
Custom Label
Meaning Custom Label to add to all assets discovered
Format string
Default -
Example Assembly Line 2
VLAN
Format 300,599,601
Default -

4.1.4.37. RAFT Gateway Query
Table 58. RAFT Gateway Query
Task Name RAFT Gateway Query
Task ID 89
CTD Task Name RaftGateway Query
Description Welding Technology Corp. (WTC) RAFT Gateway query over HTTP
Port 8080 (TCP)
Target Devices WTC RAFT Gateway devices
Intrusive Level Low
Custom Info Fields Order number (MLFB)
Sub Queries
Sub Query Generic
Potential Information Collected IP, Vendor, Family, Model, Hostname, Serial, Order Number (MLFB)
Parameters
Port
Format number
Default 8080
Example 1234
IP
Meaning IP
Format string
Default -
Example 1.1.1.1
4.1.4.38. Reverse DNS
Table 59. Reverse DNS
Task Name Reverse DNS
Task ID 55
CTD Task Name Reverse DNS
Description Reverse DNS resolution is the querying technique of DNS to determine the domain
name associated with an IP address using PTR records.
Port 53
Target Devices
Intrusive Level
Custom Info Fields
Sub Query Generic
Potential Information Collected
Parameters
DNS Server
Meaning IP address of the dns server
Format ip address

Task Name Reverse DNS
Default
Example 192.168.1.13
Domain
Meaning Optional domain name to trim from the revised fully qualified domain name
Format string
Default - (not required)
Example claroty.com

4.1.4.39. S7Comm Query
Table 60. S7Comm Query
Task Name S7Comm Query
Task ID 17
CTD Task Name S7CommQuery
Description Uses the Siemens S7comm to query PLCs for information and nested devices
Port 102
Target Devices Siemens PLCs (S7-300, S7-400 families)
Intrusive Level Low
Custom Info Fields • Order Number (MLFB)
Sub Queries
Sub Query Basic
Sub Query Description S7Comm reads device information from the controller
Potential Information Collected Hostname, vendor, model, firmware, IP, serial, MLFB, mode, slots
Sub Query Advanced
Sub Query Description S7Comm reads configuration from the controller - extracts nested devices and code
sections
Potential Information Collected Hostname, vendor, model, firmware, IP, serial, MLFB, mode, slots, code sections,
nested devices
Parameters
IP
Format IP
Default -
Example 10.0.0.1
Password
Meaning Login password to the PLC
Format String (8 characters or less)
Default -
Example Password
CPU slot
Meaning Slot in which the CPU is on the rack
Format Number
Default 0
Example 2

4.1.4.40. S7CommPlus Query
Table 61. S7 Comm Plus Query
Task Name S7CommPlus Query
Task ID 51
CTD Task Name S7CommPlus Query
Description S7CommPlus is a Siemens proprietary protocol that runs between programmable

logic controllers of the Siemens S7-1200/1500 family.
Port 102 (TCP)
Target Devices Siemens S71500
Siemens S71200
Siemens ET-200
Intrusive Level Low
Custom Info Fields MLFB Variables
Sub Query Identify s71200 s71500
Sub Query Description Identify - try to identify if 1500/1200
Potential Information Collected Model, Firmware, MLFB, Mac, IP, Project Information, Slots
Parameters
Password
Meaning -
Format text
Default -
Example -

4.1.4.41. SNMP Network Layout Query
Table 62. SNMP Network Layout Query
Task Name SNMP Network Layout Query
Task ID 40
CTD Task Name SNMP Network Layout Query
Description Using SNMP and a starting IP, the query recursively gets information about network switches
and devices, and gets the entities connected to their interfaces
Port 161
Target Devices Network devices (especially switches)
Intrusive Level High
Custom Info Fields location
Sub Queries
Sub Query See SNMP Query (page 98)
Sub Query Description See SNMP Query (page 98)
Parameters
SNMP Parameters
Meaning See SNMP Query Parameters (page 98)
Format See SNMP Query Parameters (page 98)
Default See SNMP Query Parameters (page 98)
Example See SNMP Query Parameters (page 98)
Max Recursion Depth
Meaning Maximum recursion depth to reach while querying switches and their neighbors.
Format number
Default 2
Example 3
Max Number of Switches
Meaning Maximum Number of switches to get their CAM tables and neighbors.
Format number
Default 15
Example 10

4.1.4.42. SNMP Query
Table 63. SNMP Query
Task Name SNMP Query
Task ID 1
CTD Task Name SNMPQuery
Description Uses the SNMP Protocol to query devices for information
Port 161
Target Devices All devices implementing SNMP (Networking, PLCs, etc.)
Custom Info Fields • Image

• Series
• Hardware Revision
• Order Number
• Location
• Short Module Name
Sub Queries
Sub Query V1
Sub Query Description Uses SNMP Version 1 to query devices based on the configured SNMP Matchers
Potential Information Collected Matcher dependent, connected devices
Sub Query V2c
Sub Query V3
Parameters
Sub query
Meaning SNMP version
Format Dropdown list
Default -
Example v1, v2, v3...
IP
Format IP
Default -
Example 10.0.0.1
Community (for v1, v2)
Meaning Community string for connection
Format string
Default -
Example public
username (for v3)
Meaning Username for login
Format string
Default -

Task Name SNMP Query
Example administrator
auth proto
Meaning Authentication protocol
Default Md5
Example sha224
priv_proto
Meaning Encryption method
Default des
Example aes128
auth_key
Meaning Authentication key
Format String
Default -
Example password
priv_key
Meaning Private key for authentication
Format Private key
Default -
Example
get_arp
Meaning Should read ARP table to learn net assets
Format Bool
Default FALSE
Example TRUE
get_cam
Meaning Should read CAM table to learn net assets
Format Bool
Default FALSE
Example TRUE
get_comms
Meaning Should generate baselines in the system for CDP, TCP connections
Format Bool
Default TRUE
Example FALSE

4.1.4.43. SNMP Siprotec 5 Query
Table 64. SNMP Siprotec Query
Task Name SNMP Siprotec Query
Task Name 32
CTD Task Name Siemens Siprotec5 SNMP Query
Description Uses SNMP to query the Siprotec5 proprietary OIDs via SNMP
Port See SNMP
Intrusive Level Low
Custom Info Fields N/A
Sub Queries V3
Sub Query Basic
Sub Query Description Uses SNMP v3 with built-in credentials in Siprotec 5
Parameters
Port
Format number
Default 161
Example 1234
get_arp
Meaning Should read ARP table to learn net assets
Format Boolean
Default FALSE
Example TRUE
get_cam
Meaning Should read CAM table to learn net assets
Format Boolean
Default FALSE
Example TRUE

4.1.4.44. SSH Discovery
Table 65. SSH Discovery
Task Name SSH Discovery
Task Name 43
CTD Task Name SSHQuery
Description Uses SSH to remotely connect and collect data from SSH supporting servers.
Port 22
Target Devices SSH Servers
Intrusive Level Low
Custom Info Fields Kemel SSH Server Daemon
Sub Query Generic
Sub Query Description Uses the SSH protocol to connect to relevant hosts and run several commands to
attempt to collect information
Potential Information Collected OS, kernel version, hostname, vendor, serial model
Parameters
username
Meaning username
Format text
Default -
Example myuser
password
Meaning password
Format text
Default -
Example mypassword
port
Meaning port
Format number
Default 22
Example 22

4.1.4.45. Schneider TSX Query
Table 66. Schneider TSX Query
Task Name Schneider TSX Query
Task Name 47
CTD Task Name Schneider TSX Query
Description Uses the PL7 software proprietary protocol to query Schneider TSX devices
Ports 502 (TCP)
Target Devices Schneider TSX
Intrusive Level Low
Custom Info Fields • Node Number
Sub Query Generic
Sub Query Description Uses the PL7 software proprietary protocol to query Schneider TSX devices
Potential Information Collected IP, Vendor, Family, Model, Firmware, Project name
Parameters
Port
Meaning The port on which the PLC listens on Modbus connections
Format number
Default 502
Example 2000
Network ID
Meaning XWay Network ID
Format number
Default 0
Example 1
Station IDs
Meaning XWay Station IDs to try to communicate with
Format List of numbers
Default -
Example 0-1

4.1.4.46. Schneider Unity Query
Table 67. Schneider Unity Query
Task Name Schneider Unity Query
Task Name 29
CTD Task Name Schneider Unity Query
Description Uses the Schneider Unity Modbus function code 90 to query PLCs
Ports 502 (TCP), 21 (TCP)
Target Devices Schneider PLCs
Intrusive Level Low
Custom Info Fields • Mode

• Hardware ID
• Rack Model
Sub Queries Unity Basic, Unity Basic FTP, Unity Advanced
Sub Query Unity Basic
Sub Query Description Uses basic Unity functions to learn information about the PLC
Potential Information Collected Model, Family, Firmware, Hardware ID, vendor, Project, Mode, Project path, Last Stop
Time (M221)
Sub Query Unity Basic FTP
Sub Query Description Uses basic Unity functions as well as default FTP credentials to learn information
about the PLC
Potential Information Collected Model, Family, Firmware, Hardware ID, Vendor, Project, Mode, Mac, Project path, Last
Stop Time (M221)
Sub Query Unity Advanced
Sub Query Description Uses advanced Unity functions to learn information and configuration about the PLC
Potential Information Collected Model, Family, Firmware, Hardware ID, Vendor, Project, Mode, Mac, Code sections,
Project path, Last Stop Time (M221)
Parameters
Modbus Port
Meaning The port on which the PLC listens on Modbus connections
Format Number
Default 502
Example 502
FTP Port
Meaning The port on which the PLC listens on FTP connections
Format number
Default 21
Example 21
Unit ID
Meaning Modbus Unit ID
Format number
Default 0
Example 0

4.1.4.47. Sinumerik Query
Table 68. Sinumerik Query
Task Name Sinumerik Query
Task ID 91
CTD Task Name Sinumerik Query
Description Queries the Sinumerik series of Siemens CNC control systems
Port 22 (TCP)
Target Devices Siemens Sinumerik CNCs
Intrusive Level Low
Custom Info Fields Order Number (MLFB)
Sub Query Generic
Sub Query Description Uses SCP or SFTP over SSH to collect information about Siemens Sinumerik CNCs.
Potential Information Collected IP, Vendor, Family, Model, Firmware, Serial, EntityType, Order Number (MLFB), Slot
Parameters
Port
Meaning SSH port
Format Number
Default 2
Example 1234
Username
Meaning SSH Username
Format Text
Default -
Example myuser
Password
Meaning SSH Password
Format Text
Default -
Example mypassword
Password
Meaning Which file-transfer protocol to use for retrieving files - SCP or SFTP.
Before CTD v4.8.0, always SFTP
Format Dropdown string (SFTP/SCP)
Default SCP
Example SCP

4.1.4.48. Siprotec Query
Table 69. Siprotec Query
Task Name Siprotec Query
Task Name 6
CTD Task Name SiprotecQuery
Description Uses the Siprotec protocol to query RTUs
Port 443
Intrusive Level Low
Custom Info Fields • Order Number (MLFB)

• FPGA Version
• Configuration Version
Sub Queries Basic, Advanced
Sub Query Basic
Sub Query Description Uses the DIGSI protocol version 5 to query the controller for basic information
Potential Information Collected IP, serial
Sub Query Advanced
Sub Query Description Uses the DIGSI protocol version 5 to query the controller for advanced information
Potential Information Collected IP, serial, slots, firmware, configuration version, mac, code sections
Parameters
IP
Format IP
Default -
Example 10.0.0.1
4.1.4.49. Speedwire Query
Table 70. Speedwire Query
Task Name Speedwire Query
Task ID 79
CTD Task Name SMA Speedwire Query
Description SMA Speedwire query over UDP
Port 9522 (UDP)
Target Devices SMA Devices
Intrusive Level Low
Custom Info Fields Device type, Mode
Sub Query Generic
Potential Information Collected IP, MAC, Vendor, Model, Firmware
Parameters
Username
Meaning Permission level
Format Dropdown
Default User

Task Name Speedwire Query
Example User
Password
Meaning Password
Format String
Default --
Example 0000
4.1.4.50. Tridium Fox Query
Table 71. DB Enumeration Query
Task Name Tridium Fox Query
Task ID 68
CTD Task Name Tridium Fox Query
Description Uses the Tridium Fox Protocol to query Tridium stations
Port 1911 (TCP)
Target Devices Tridium stations
Intrusive Level
Custom Info Fields
Sub Query Generic
Sub Query Description Uses the Tridium Fox Protocol to query Tridium stations
Potential Information Collected hostname, entity type, os version, firmware version, model, vendor
Parameters
Port
Format number
Default 1911
Example 1912

4.1.4.51. TBox Query
Table 72. TBox Query
Task Name TBox Query
Task Name 50
CTD Task Name TBox Query
Description Ovarro TBox General Info Query
Port 502 (TCP)
Target Devices Ovarro TBox
Intrusive Level Low
Custom Info Fields • -
Sub Query Generic
Sub Query Description Login with default credentials to provide basic info
Potential Information Collected Hostname, Firmware, IP, Module, Project Information
Parameters
Port
Format number
Default 502
Example 501
4.1.4.52. Ubiquiti Query
Table 73. Ubiquiti Query
Task Name Ubiquiti Query
Task ID 80
CTD Task Name Ubiquiti Query
Description Uses the Ubiquiti discovery protocol to query Ubiquiti devices
Ports 10001 (UDP)
Target Devices Ubiquiti Devices
Intrusive Level Low
Custom Info Fields SSID
Sub Query Generic
Sub Query Description --

4.1.4.53. Unitronics Query
Table 74.
Task Name Unitronix Query
Task ID 49
CTD Task Name Unitronix Query
Description Uses the PCOM-TCP protocol to query Unitronics PLCs
Port 20256 (TCP)
Target Devices Unitronix PLCs
Intrusive Level Low
Custom Info Fields • Hardware Revision
Sub Query Generic
Sub Query Description Uses the PCOM protocol to query Unitronics devices
Potential Information Collected IP, Vendor, Model, Firmware, Hostname
Parameters
Port
Format number
Default 20256
Example 2000
4.1.4.54. WAGO Query
Table 75. WAGO Query
Task Name WAGO Query
Task ID 71
CTD Task Name WAGO Query
Description Uses IOCHECKD protocol to get basic information on a specific WAGO device
Port 6626(TCP)
Target Devices WAGO PFC Devices
Intrusive Level
Custom Info Fields Description
Sub Query Basic
Potential Information Collected Vendor, entity_type, ip, model, serial, version, hostname
Parameters
IP
Meaning IP
Format string
Default
Example

4.1.4.55. WMI Query
Table 76. WMI Query
Task Name WMI Query
Task ID 19
CTD Task Name WMIQuery
Description Uses WMI to query Windows hosts for information
Port 135
Custom Info Fields • Windows Serial Number

• Windows Edition
• Windows Domain
• Logged On User
• Last Program Installed Date
Sub Queries
Sub Query Basic
Sub Query Description Use WMI to collect basic information about the host
Potential Information Collected IP, hostname, OS, Windows serial, Windows edition, model, serial, Mac, installed pro-
grams
Sub Query Advanced
Sub Query Description Uses WMI to collect information about the host, including installed software and
security patches
grams, patches, USB connected devices
Parameters
IP
Format IP
Default -
Example 10.0.0.1
Username
Meaning Username for the Windows login
Format String
Default -
Example Administrator
Password
Meaning Password for the username
Format String
Default -
Example Password1
Domain
Meaning Domain for the login
Format String
Default -
Example domain01

4.1.4.56. WSD Query
Table 77. WSD Query
Task Name WSD Query
Task Name 35
CTD Task Name WSD Query
Description Uses WSD and ONVIF to query network devices, based on the WSD IoT Matchers
Port 3702
Target Devices Network devices
Intrusive Level Low
Custom Info Fields • location
Sub Queries
Sub Query Generic
Sub Query Description Uses the Web Services for Devices (WSD) generic discovery protocol to identify IoT
devices
Parameters
Port
Format number
Default 3702
Example 1234

4.1.4.57. WinRM Query
Table 78. WinRM Query
Task Name WinRM Query
Task ID 39
CTD Task Name WinRM Query
Description Uses WinRM protocol to query information about Windows computers, using WMI
and registry. Uses SOAP over HTTP and must be configured
Port 5985(HTTP)/5986(HTTPS)
Target Devices Windows machines
Custom Info Fields Description
Sub Queries
Sub Query Basic
Sub Query Description Uses WinRM to collect basic information about the host
grams
Sub Query Advanced
Sub Query Description Uses WMI to collect information about the host, including installed software and
security patches
grams, patches, USB connected devices
Parameters
Username
Meaning username
Format string
Default -
Example myuser
Password
Meaning password
Format string
Default -
Example mypassword
Domain
Meaning domain (if in a domain)
Format string
Example mydomain
Service
Meaning service - HTTP or HTTPS
Format string out of enum
Default HTTP
Example HTTP

4.1.4.58. Net Bios
Table 79. Net Bios
Task Name Net Bios
Task ID 4
CTD Task Name NetBiosQuery
Description Uses the Windows NetBIOS service to learn the hostname and OS version. Also uses
SMBv1
Ports 137, 138, 445
Target Devices Windows devices
Intrusive Level Low
Sub Query Generic
Sub Query Description Use the NetBios Protocol to interrogate Windows devices using this basic discovery
protocol
Potential Information Collected OS, hostname, SMB server version, Mac, IP
Parameters
IP
Format IP address
Default -
Example 10.0.0.1
Port
Meaning Port to use for SMBv1
Format Number
Default 139
Example 445

4.1.4.59. TCP Port Scan
Table 80. TCP Port Scan
Task Name TCP Port Scan
Task Name 20
CTD Task Name PortScanQuery
Description TCP Port Scanning
Port -
Target Devices All
Sub Query Generic
Sub Query Description Uses TCP to attempt connection to all specified ports to detect whether those ports
are in "listen" mode
Potential Information Collected Open ports (as baselines), IPs
Parameters
IP
Format IP address
Default -
Example 10.0.0.1
Tcp_ports
Meaning Ports to scan
Format Comma separated ports
Default 22,23,80,102,139,445,502,2222,44818
Example 123456678

4.1.4.60. Telnet
Table 81. Telnet
Task Name Telnet
Task ID 3
CTD Task Name Telnet
Description Performs a telnet banner grabbing. Extracts info from Scalance, Hirschmann switches
Port 23
Target Devices Scalance switches, Hirschmann switches
Intrusive Level Low
Sub Query Generic
Sub Query Description Use the Telnet protocol to perform "banner grabbing" by connecting to the Telnet
service and identifying the returned banner
Potential Information Collected Matcher dependent
Parameters
IP
Format IP
Default -
Example 10.0.0.1
4.1.5. DISCOVERY TASKS

The Discovery Task finds new devices in the network using the specific protocol.
Table 82. Summary Discovery Tasks Table
BACnet Discovery (page 115) Finds BACnet Devices using a broadcast request
CodesysV3 Discovery (page 116) Uses Codesysv3 protocol discovery to identify codesys devices
CrowdStrike Discovery (page 116) Discovers devices running CrowdStrike Sensors using CrowdStrike’s remote API
ENIP Scan (page 117) Uses EtherNet/IP broadcast List Identity message to identify PLCs in the net-
work
Exi 3000 Discovery (page 118) Exi 3000 Discovery over UDP
GE Station Manager Discov- Uses broadcast GE Station Manager to discover GE rx3i/rx7i devices
ery (page 119)
Hirschmann Discovery Scan (page 119) Queries Hirschmann switches using the HiDiscovery protocol. Transmits broad-
cast level 2 messages
Indraworks Discovery (page 120) Indraworks discovery over UDP
Lantronix Broadcast Discov- Uses the lantronix discovery protocol (LDP) to discover Lantronix devices
ery (page 120)
LS Discovery (page 121) Uses the XG5000 discovery protcool to query LS devices
mDNS Discovery (page 121) Uses the mDNS protocol to discover devices. Uses mDNS matchers.
Mitsubishi GOT Discovery (page 123) Discovery for Mitsubishi GOT 1000 and 2000 HMIs
Mitsubishi Melsoft Discovery (page 122) Uses proprietary Mitsubishi Melsoft protocol to discover Mitsubishi PLCs
Omron FINS Discovery (page 123) Omron FINS Discovery
Ping Sweep (page 124) Performs a ping sweep across all IPs specified to detect existing assets

Profinet-DCP Scan Uses the Profinet-DCP broadcast message to detect devices
RAFT Gateway Discovery (page 126) WTC RaftGateway Discovery Query over UDP
Schneider Modicon Discov- Uses the netmanage protocol to discover modicon plc's
ery (page 128)
Sixtnet Discovery (page 128) Red Lion Sixtnet discovery
SNMP Scan (page 126) Uses SNMP to read the ARP cache of devices to generate new assets
Speedwire Discovery Query (page 129) SMA Speedwire discovery query over UDP
SSDP Discovery (page 127) Uses broadcast SSDP to find UPNP devices in the network
TCP Port Discovery (page 129) IPs based on the specific ports. Will detect all IPs where the specified ports are
open
VMware ESX Discovery (page 131) Using VMWare Public API to discover VMs running on the specified ESX
WSD Discovery (page 132) Uses WSD and ONVIF to find network devices, based on the WSD IoT Matchers
4.1.5.1. BACnet Discovery
Table 83. BACnet Discovery
Task Name BACnet Discovery
Task ID 27
CTD Task Name BACnet Discovery
Description Finds BACnet Devices using a broadcast request
Port 47808
Target Devices Mainly BMS controllers
Intrusive Level Low
Custom Info Fields • Object Name

• Application Software Version
• Location
• Description
• Object Identifier
• Custom Label
Sub Query Generic
Sub Query Description Uses BACnet broadcast requests to collect information about devices
Potential Information Collected Firmware, model, application version, object Name, hostname, location, object ID,
vendor, IP, description
Parameters
Interface name
Format string
Default -
Example en192
Subnet
Meaning Subnet on which to broadcast
Format CIDR subnet
Default -
Example 192.168.1.0/24
Use Object ID as Hostname
Meaning Should use the BACnet Object ID as the hostname of the target

Task Name BACnet Discovery
Format Checkbox
Default TRUE
Example FALSE
Query Discovered Devices
Meaning Should query the discovered devices for more details
Format Checkbox
Default TRUE
Example FALSE
4.1.5.2. CodesysV3 Discovery
Table 84. CodesysV3 Discovery
Task Name CodesysV3 Discovery
Task ID 66
CTD Task Name CodesysV3 Discovery
Description Uses Codesysv3 protocol discovery to identify codesys devices
Port 1740, 1741, 1742, 1743 (UDP)
Target Devices All devices running Codesysv3
Intrusive Level -
Sub Query Discovery
Potential Information Collected firmware, model, vendor, serial, entity_type
Parameters
InterfaceName
Format string
Default -
Example -
4.1.5.3. CrowdStrike Discovery
Table 85. CrowdStrike Discovery
Task Name CrowdStrike Discovery
Task ID 53
CTD Task Name CrowdStrike Discovery
Description Retrieves data about a device running CrowdStrike Sensor and uses AppDB to parse
Port 443 (TCP) - Internet Access
Intrusive Level Low
Sub Queries
Sub Query Generic

Task Name CrowdStrike Discovery
Sub Query Description Retrieves data about a device running CrowdStrike Sensor and uses AppDB to parse
Potential Information Collected IP, Mac, OS, Hostname, Vendor, Model
Parameters
Client ID
Default -
Client Secret
Default -
Cloud
Format dropdown
Default US
Example US-2
IP Range
Meaning IP ranges to retrieve from CrowdStrike
Format IP range
Example 192.168.1.0/24
IP Range Exclude
Meaning IP ranges not to retrieve from CrowdStrike
Format IP range
Example 192.168.1.13
Sensor Tags
Meaning CrowdStrike Sensor tags to filter in
Format Comma separated words
Example Claroty,SensorGroupingTags/Siemens
4.1.5.4. ENIP Scan
Table 86. ENIP Scan
Task Name ENIP Scan
Task ID 12
CTD Task Name ENIP BroadcastScan
Description Uses EtherNet/IP broadcast List Identity message to identify PLCs in the network
Port 44818
Intrusive Level Low

Task Name ENIP Scan
Custom Info Fields • Custom Label
Sub Query UDP Broadcast
Sub Query Description Use the ENIP Identity Request command to collect basic information on ENIP compati-
ble devices
Potential Information Collected IP, model, vendor, serial
Parameters
Interface Name
Format string
Default -
Example en192
Subnet
Meaning Subnet on which to broadcast
Format CIDR subnet
Default -
Example 192.168.1.0/24
Custom Label
Format string
Default -
Example Location:aaa, Process: bbb
4.1.5.5. Exi 3000 Discovery
Table 87. Exi 3000 Discovery
Task Name Exi 3000 Discovery
Task ID 94
CTD Task Name Exi 3000 Discovery
Description Uses UDP to discover EX~i 3000 Flow Computers
Port 5680 (UDP)
Target Devices EX~i 3000 Flow Computers
Intrusive Level Low
Sub Query Broadcast
Potential Information Collected IP, Entity Type, Vendor, Model, Hostname
Parameters
Port
Format Number
Default 5680
Example 1234
Interface Name
Meaning Interface name to use
Format String

Task Name Exi 3000 Discovery
Default -
Example en0
check_only_exi3000
Meaning Only accept Exi Model 3000 devices
Format Checkbox
Default Selected (True)
Example True
4.1.5.6. GE Station Manager Discovery
Table 88. GE Station Manager Discovery
Task Name GE Station Manager Discovery
Task ID 59
CTD Task Name GE Station Manager
Description Uses broadcast GE Station Manager to discover GE rx3i/rx7i devices
Port 18245 (UDP)
Target Devices GE rx3i/rx7i PLCs
Intrusive Level -
Sub Query UDP BROADCAST
Sub Query Description Uses broadcast GE Station Manager to discover GE rx3i/rx7i devices
Potential Information Collected vendor, model, firmware, serial, type, mac address
Parameters
Port
Format number
Default 18245
Example 18245
Interface name
Format String
Default -
Example en192
4.1.5.7. Hirschmann Discovery Scan
Table 89. Hirschmann Discovery Scan
Task Name Hirschmann Discovery Scan
Task ID 9
CTD Task Name HiDiscoveryScan
Description Queries Hirschmann switches using the HiDiscovery protocol. Transmits broadcast
level 2 messages
Port -
Target Devices Hirschmann devices

Task Name Hirschmann Discovery Scan
Intrusive Level Low
Sub Query LLC Broadcast
Sub Query Description Use the Hirschmann HiDiscovery protocol to query Hirschmann devices (2nd layer)
Potential Information Collected model, vendor, IP, MAC, hostname
Parameters
Interface name
Format string
Default -
Example en192
Custom label
Format string
Default -
4.1.5.8. Indraworks Discovery
Table 90. Indraworks Discovery
Task Name Indraworks Discovery
Task ID 92
CTD Task Name Indraworks Discovery
Description Indraworks discovery over UDP
Port 35021 (UDP)
Target Devices Bosch IndraDrive devices
Intrusive Level Low
Custom Info Fields Type Code, Series
Sub Query UDP-Broadcast
Potential Information Collected IP, Vendor, Firmware, Family, Default Gateway, Serial Number, EntityType, Model,
Type Code, Series
Parameters
Port
Format Number
Default 35021
Example 1234
4.1.5.9. Lantronix Broadcast Discovery
Table 91. Lantronix Broadcast Discovery
Task Name Lantronix Broadcast Discovery
Task ID 73

Task Name Lantronix Broadcast Discovery
CTD Task Name Lantronix Discovery
Description Uses the lantronix discovery protocol (LDP) to discover Lantronix devices
Port 30718(UDP)
Target Devices Lantronix Devices
Intrusive Level -
Sub Query Generic
Parameters
InterfaceName
Meaning interface name to use
Format string
Default -
Example en0
4.1.5.10. LS Discovery
Table 92. LS Discovery
Task Name LS Discovery
Task ID 78
CTD Task Name Lantronix Discovery
Description Uses the XG5000 discovery protcol to query LS devices
Port 2007 (UDP)
Target Devices LS Devices
Intrusive Level Low
Sub Query Broadcast
Sub Query Description LS broadcast discovery
Potential Information Collected IP, Vendor, Model, Entity type
Parameters
InterfaceName
Format string
Default -
Example en0
4.1.5.11. mDNS Discovery
Table 93. mDNS Discovery
Task Name mDNS Discovery
Task ID 60
CTD Task Name mDNS Discovery
Description Uses the mDNS protocol to discover devices. Uses mDNS matchers.

Task Name mDNS Discovery
Port 5353 (UDP)
Target Devices IoT devices, Apple devices
Intrusive Level -
Sub Query Generic
Sub Query Description mDNS Discovery - Uses the Multicast DNS protocol to discover IOT devices.
Potential Information Collected hostname, entity type, everything supported by IoT matchers
Parameters
Interface name
Meaning interface name to use
Format string
Default - (=all interfaces)
Example en0
Extended services
Meaning whether to use all known services (more network load), or just the main ones
Format Checkbox
Default True
Example False
4.1.5.12. Mitsubishi Melsoft Discovery
Table 94. Mitsubishi Melsoft Discovery
Task Name Mitsubishi Melsoft Discovery
Task ID 65
CTD Task Name Melsoft Discovery
Description Uses proprietary Mitsubishi Melsoft protocol to discover mitsubishi PLCs
Port 5009 (UDP)
Target Devices WAGO PFC Devices
Intrusive Level -
Sub Query Broadcast
Sub Query Description Mitsubishi Melsoft PLC Discovery.
Potential Information Collected Vendor, entity_type, ip, model, serial, version, hostname
Parameters
IP
Meaning IP
Format string
Default -
Example -
Query Example (CLI) -e 65 -p "sub_query:Broadcast,interface_name:__ALL__" -v

4.1.5.13. Mitsubishi GOT Discovery
Table 95. Mitsubishi GOT Discovery
Task Name Mitsubishi GOT Discovery
Task ID 83
CTD Task Name Mitsubishi GOT Discovery
Description Mitsubishi GOT 1000 and 2000 HMI discovery
Port 49153
Target Devices Mitsubishi HMIs
Intrusive Level Low
Sub Query Broadcast
Potential Information Collected IP, MAC, Vendor, Model, Entity type
Parameters
Interface
Format string
Default -
Example en0
Query Example (CLI) python3 -m active_queries.main -e 81 -p "sub_query:Broadcast,inter-

face_name:__ALL__" -v
4.1.5.14. Omron FINS Discovery
Table 96. Omron FINS Discovery
Task Name Omron FINS Discovery
Task ID 76
CTD Task Name FINS Discovery
Description Omron FINS Discovery
Port 9600 (TCP/UDP)
Target Devices Omron Devices
Intrusive Level Low
Sub Query UNICAST, BROADCAST
Potential Information Collected IP, Entity Type
Parameters
Port
Format Number
Default 9600
Example 1234
Interface
Format String

Task Name Omron FINS Discovery
Default -
Example en0
4.1.5.15. Ping Sweep
Table 97. Ping Sweep
Task Name Ping Sweep
Task ID 7
CTD Task Name PingSweep
Description Performs a ping sweep across all IPs specified to detect existing assets
Port -
Target Devices All devices that respond to ping (endpoints, PLCs, networking)
Sub Query Generic
Sub Query Description Send Ping requests to all listed IPs, and determine their existence in the network
based on the response
Potential Information Collected IPs
Parameters
IP Range
Meaning Range of IPs to ping
Format IP, CIDR or IP range
comma separated
Default -
Example work,192.168.1.0/24
IP Range exclude
Meaning Range of IPs to not ping
Format IP, CIDR or IP range
comma separated
Default -
Example 10.0.0.1-10.0.0.10, 192.168.1.0/24
Concurrent scans
Meaning Number of packets to send concurrently
Format number
Default 50
Example 50
Retransmissions
Meaning Number of times to ping an IP if no response was received
Format number
Default 2
Example 2
Custom Label
Format key:value, key:value...

Task Name Ping Sweep
Default -
Sub Query Host Name Resolving
Sub Query Description Performs a ping as well as a reverse DNS query on the found IPs, to collect hostnames
as well
Potential Information Collected IP, hostname
Parameters
DNS Server
Meaning The IP of the DNS Server to query. If empty will use the default server configured to
CTD
Format IP address
Default -
Example 8.8.8.8
Domain Name
Meaning The Domain name, to strip from the returning names
Format string
Default -
Example company.co
4.1.5.16. Profinet-DCP Scan
Table 98. Profinet-DCP Scan
Task ID 14
CTD Task Name ProfinetScan
Port -
Intrusive Level Low
Sub Query DCP Broadcast
Sub Query Description Use the Profinet-DCP information collection broadcast packet to discover (layer 2)
relevant network devices
Parameters
Interface name
Format string
Default -
Example en192
Custom Label
Format string
Default -

VLAN
Format 300,599,601
Default -
4.1.5.17. RAFT Gateway Discovery
Table 99. RAFT Gateway Discovery
Task Name RAFT Gateway Discovery
Task ID 90
CTD Task Name RaftGateway Discovery Query
Description WTC RAFT Gateway Discovery Query over UDP
Port 50804 (UDP)
Target Devices WTC RAFT Gateway devices
Intrusive Level Low
Sub Query Unicast
Potential Information Collected IP, Vendor, Family, Hostname
Broadcast
IP, Vendor, Family, Hostname
Parameters
Interface Name
Format String
Default -
Example en0
Port
Format Number
Default 50804
Example 1234
4.1.5.18. SNMP Scan
Table 100. SNMP Scan
Task Name SNMP Scan
Task ID 16
CTD Task Name SNMPArpCacheScan
Description Uses SNMP to read the ARP cache of devices to generate new assets
Port 161
Target Devices All devices implementing SNMP (Networking, PLCs)

Task Name SNMP Scan
Sub Queries See SNMP (page 98) Sub queries
Sub Query Description Uses SNMP to collect the ARP table from a network device, to discover all devices
connected to it
Parameters
See SNMP (page 98) Parameters
Custom Label
Format key:value, key:value...
Default -
4.1.5.19. SSDP Discovery
Table 101. SSDP Discovery
Task Name SSDP Discovery
Task ID 56
CTD Task Name WSD Discovery
Description Uses broadcast SSDP to find UPNP devices in the network
Port 1900 (UDP)
Target Devices IoT devices
Intrusive Level -
Sub Query Basic
Sub Query Description Uses SSDP to find devices in the network, not adding any information on them
Potential Information Collected -
Parameters
port
Format number
Default 1900
Example 1234
Interface name
Format string
Default -
Example en192
Sub Query Advanced
Sub Query Description Uses SSDP to find devices in the network, and using the "location" field to get more
information
Potential Information Collected vendor, model, firmware, serial, type
Parameters
Port

Task Name SSDP Discovery
Format number
Default 1900
Example 1234
Interface name
Format string
Default -
Example en192
4.1.5.20. Schneider Modicon Discovery
Table 102. Schneider Modicon Discovery
Task Name Schneider Modicon Discovery
Task ID 67
CTD Task Name Schneider Modicon Discovery
Description Uses the netmanage protocol to discover modicon plc's
Port 27127 (UDP)
Target Devices Schneider Modicon
Intrusive Level -
Sub Query Discovery
Potential Information Collected ip, firmware, project_name, mac address
Parameters
Interface Name
Format String
Default -
Example -
4.1.5.21. Sixtnet Discovery
Table 103. Sixtnet Discovery
Task Name Sixtnet Discovery
Task ID 86
CTD Task Name Sixtnet Discovery
Description Red Lion Sixtnet Discovery
Port 1594 (UDP)
Target Devices Sixnet Devices
Intrusive Level Low
Custom Info Fields --
Sub Query Broadcast

Task Name Sixtnet Discovery
Potential Information Collected IP, Entity Type, Vendor, Family, Model, Hardware ID, Serial
Parameters
InterfaceName
Format String
Default --
Example en0
InterfaceName
Format String
Default 1594
Example 1234
4.1.5.22. Speedwire Discovery Query
Table 104. Speedwire Discovery Query
Task Name Speedwire Discovery Query
Task ID 80
CTD Task Name Speedwire Discovery Query
Description SMA Speedwire discovery query over UDP
Port 9522 (UDP)
Target Devices SMA Devices
Intrusive Level Low
Sub Query UNICAST, BROADCAST
Sub Query Description SMA Speedwire discovery query over UDP
Potential Information Collected Vendor
Parameters
IP
Meaning IP address
Format String
Default --
Example 1.1.1.1
Interface
Format String
Default -
Example en0
4.1.5.23. TCP Port Discovery
Table 105. TCP Port Discovery
Task Name TCP Port Discovery
Task ID 41

Task Name TCP Port Discovery
CTD Task Name PortScanDiscovery
Description Scans IPs based on the specified ports. Will detect all IPs where the specified ports are
open
Port 22,23,80,102,139,445,502,2222,44818
Target Devices All
Sub Query Generic
Sub Query Description Discovers assets in the network using the Port Knocking technique on the specified
ports
Potential Information Collected IPs, open ports (as baselines)
Parameters
IP range
Meaning IP range to scan
Format IP range
Default -
Example 192.168.1.0/24
ip_range_exclude
Meaning IPs not to scan
Format IPs
Example 192.168.1.13
tcp_ports
Meaning TCP ports to check
Format List of numbers
Default 22,23,80,102,139,445,502,2222,44818
Example 1234
concurrent_ports
Meaning Maximum number of ports to concurrently scan in a single IP
Format number
Default 1
Example 10
concurrent_ips
Meaning Maximum number of IPs to concurrently scan
Format number
Default 50
Example 3
4.1.5.24. Ubiquiti Broadcast Discovery
Table 106. Ubiquiti Broadcast Discovery
Task Name Ubiquiti Broadcast Discovery
Task ID 79
CTD Task Name Ubiquiti Discovery
Description Uses the Ubiquiti discovery protocol to discover Ubiquiti devices

Task Name Ubiquiti Broadcast Discovery
Port 10001 (UDP)
Target Devices Ubiquiti Devices
Intrusive Level Low
Custom Info Fields SSID
Sub Query Generic
Parameters
InterfaceName
Format string
Default -
Example en0
4.1.5.25. VMware ESX Discovery
Table 107. VMware ESX Discovery
Task Name VMware ESX Discovery
Task ID 42
CTD Task Name esxScan
Description Using VMWare Public API to discover VMs running on the specified ESX
Port 443
Target Devices VMware ESX
Intrusive Level Low/Medium
Custom Info Fields • Machine UUID

• ESX IP
Sub Query Generic
Sub Query Description Uses the VMWare API protocol to identify the ESX/VSphere server as well as all VMs
running on top of it
Potential Information Collected For Host: IP, OS For Guests: OS, UUID, hostname, vendor
Parameters
IP range
Meaning IP range to scan
Format IP range
Default -
Example 192.168.1.0/24
port
Meaning port
Format number
Default 443
Example 443
username
Meaning username
Format text
Default -

Task Name VMware ESX Discovery
Example root
password
Meaning password
Format text(number)
Default -
Example toor
4.1.5.26. WSD Discovery
Table 108. WSD Discovery
Task Name WSD Discovery
Task ID 37
CTD Task Name WSD Discovery
Description Uses WSD and ONVIF to find network devices, based on the WSD IoT Matchers
Port 3702
Target Devices Network devices
Intrusive Level Low
Custom Info Fields • location
Sub Query Generic
Sub Query Description Uses the Web Services for Devices (WSD) generic discovery protocol to identify IoT
devices
Parameters
Format number
Default 3702
Example 1234

CTD Reference Guide IoT Asset Management and Moni-
toring
4.2. IoT Asset Management and Monitoring
4.2.1. IOT MATCHERS CONFIGURATION

CTD provides out-of-the-box predefined IoT matchers able to detect various types of IoT devices,
such as IP phones, printers, and cameras.
IoT matchers are code sections, written in JSON format, that describe how to address IoT devices
using HTTP or Telnet communication protocols. They also describe how the response received
from the device should be interpreted to understand what the device is and what its attributes
are. These IoT matchers work with passive collection as well.
These predefined matchers unlike user defined custom matchers, cannot be edited or deleted.
They can only be disabled. Custom matcher’s rules can also be disabled to stop their activity and
enabled later if needed.
To create your own custom IoT matchers:
1. Navigate to the IoT Matchers configuration tab under Configuration > Data Sources >
IoT Matchers.
2. Click Add to open the Create New Matcher popup:
Figure 9. IoT – Create New Matcher popup

toring
3. Type in a name for the matcher

4. Upload a matcher file (any text file in a JSON format) either by selecting a file on your comput-
er or by dragging it directly into the box.
5. Edit the file as needed and click Create.
Figure 10. Edit Matcher dialog
The file, which can be uploaded to CTD or edited within the console, contains parameters
used for the collection of information, such as:
• The ports, if they differ from the default (such as http:80)
• A “verify” statement, to make sure the accessed page is the one requested, and for which
the parsers can actually work, for example, looking for a vendor’s name like “Rockwell
Automation” in the HTTP page header.
A set of parsers are used to grab asset information from the device to be able to classify the IoT
device, such as:
Figure 11. Set of parsers to grab asset Info

toring
IMPORTANT
Claroty recommends that Admins review the existing, predefined system IoT match-
ers to understand how the parsers are defined, before trying to create your own.
4.2.1.1. List of available information keywords

{KEYWORD} → Information type (Case sensitive!)
• module/model → Model
• firmware → Firmware version
• hostname → Hostname
• serial → Serial number
• vendor → Vendor
• type → Asset type (needs to be the asset type as appears in CTD, with “e” before - “ePLC”,
“eCamera”, “eEngineeringStation” etc.)
• family → Family
• description → Description
4.2.1.2. Links
• Vendor OIDs list:
https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers
• SNMP Walk for Windows (Not tested):
https://www.softpedia.com/get/Network-Tools/Misc-Networking-Tools/SnmpWalk.shtml
4.2.1.3. IoT Matcher Examples

The following is an example of an IoT Matcher in JSON format. You can modify the relevant fields
from the example in order to obtain the expected results.
JSON
SNMP

toring
HTTP
Banner
WSD

toring
4.2.1.4. IoT Active Query Configuration

For the IoT matchers to work using CTD active detection, you should first define the required
active query for IoT matching.
To configure an IoT active query:
1. Navigate to the Active Detection query configuration tab under Configuration > Data
Sources > Active Detection > Queries tab.
2. Click Create New to open the New Query popup:
Figure 18. IoT - New Query popup

toring
3. Provide a name for the query, and in Type dropdown menu, select “IoT Query”
4. Choose a Sub-Type
5. Enable the Recurring Task toggle button.
6. Choose the Start and Expire date.
7. Choose Run Every (hour, day, or week).
8. Choose the Time Frame (From and the To time).
9. Click Create.
4.2.1.5. IoT Active Task Configuration

After defining the IoT query, continue to create the active task to define the IP addresses or
segments to apply the query to.
To configure active tasks:
1. Navigate to the Active Detection query configuration tab under Settings >Extended Discov-
ery > Active Detection > Tasks
2. Click Add New Task to open the New Task popup:

toring
Figure 19. IoT – New Task popup
3. Provide a name for the task and select your desired Task Type in the dropdown menu.
4. Choose the Network from the dropdown menu.
5. Enable the Recurring Task toggle button.
6. Choose the Start and Expire date.
7. Choose Run Every (hour, day, or week).
8. Choose the Time Frame (From and the To time).
9. Click Create.
IoT Discovery Task and Classification

IoT Matchers can be treated as signatures matched against the information obtained from the IoT
asset. They can detect the device type, the OS, and the version. The information can be obtained

CTD Reference Guide Configuring Application Database
(App DB) Sources
using Active Task and Query, or passively by listening to traffic sent from/to the IoT asset that
discloses the required asset information.
To configure IoT Matchers using Active Task and Query, follow these steps:
1. Configure IoT Active Query

2. Configure Active task(s)
3. Configure IoT Matchers
4. For more information about Active Detection capabilities and configuration, refer to the CTD
User Guide.
4.2.2. IOT ASSETS INFORMATION

For IoT Assets, the type of information and level of detail depend on several factors:
• The techniques used to obtain the information – Passive or Active

• With Passive, the amount and type of traffic transmitted on the network determines what
information is available for CTD to process
• With Active, the availability of the relevant HTTP pages and their information
• The quality and level of detail of the IoT matchers
In the following example, a Vending Machine was classified, and its Virtual Zone, Risk Level, Type,
Criticality, and Class were obtained:
Figure 14. Asset View – IoT Example
4.3. Configuring Application Database (App DB) Sources

Follow the procedure of one-time parsing or recurring parsing of configuration projects files to set
up the Application Database. There is an option to manually select a file and parse it immediately.
To set up the Application Database:
• Click Settings > Data Sources > App DB:

(App DB) Sources
Figure 15. App DB - Configuring Asset Sources
4.3.1. APP DB: ONE TIME PARSING

To configure one-time parsing:
1. Navigate to the One-time parsing area:
Figure 16. App DB One Time Parsing – Select Network
2. From the dropdown, ‘Assign learned assets to network’, select the network:

(App DB) Sources
Figure 17. Choose the Network
3. Click Choose file to browse the relevant files;repeat this step as needed:
Figure 18. Choose the file/s to parse
• The system displays the filename/s of the uploaded files, including their sizes.
4. Click Start Parsing.
Figure 19. Start Parsing
5. The system displays the status of the files on the bottom of the One-time parsing area:

(App DB) Sources
Figure 20. System displays the status of file parsing process
6. Navigate to the Visibility > Assets. Then show the Parsed Assets column in the table by
clicking the More menu in the tool bar, selecting Select Columns, and selecting the
Parsed Asset item from the Select Columns list.
Figure 21. Selecting the Parsed Assets column for the Assets View
4.3.2. APP DB: RECURRING PARSING

To configure recurring parsing:

(App DB) Sources
1. Navigate to the Recurring Parsing area of Settings > Data Sources > App DB.
Figure 22. Recurring Parsing
2. Provide the Configuration Projects path. After you type a valid path, the Test button
becomes enabled.
This input is mandatory. This can be either a local path on the CTD Server or a Share on a
remote Windows machine. Use the Fully Qualified Domain Name (FQDN) format to specify the
share (for example \\1.1.1.1\share).
For the local path:
• You must provide permissions for the lkpo user for this path/folder.
• The folder should be above and outside of the "root" folder, and the folder's ownership
should be given to user 'lkpo'.
• The set of commands needed to run a viable folder is as follows:
cd / mkdir <local folder name> sudo chown -R lkpo /<local folder name>/
3. Username – If the share is protected with an account, enter the username.
4. Password – If the share is protected with an account, enter the password.
5. Provide the Interval (in hours). The Read files from path every (hours) determines how
often the system checks for new configuration projects. This input is mandatory. The default is
1 hour.
• The set interval enables users to control the overhead on the system and balance it with the
speed at which it parses the configuration projects. As soon as these assets are parsed, the
system onboards the assets and logs the activity.
6. Select the Network from Assign learned assets to network in which the onboarded assets
will be assigned. This input is mandatory. It defaults to the default network.
7. Retain Old Files (in MB). Set the limit in MB for the maximum space for retaining old files.
After the parsing process is done and all relevant data has been extracted from the configura-
tion file, the file is moved automatically to an Old folder.
8. Click the Test button to test if the Configuration Projects path you provided to the
configuration projects (in Step 2) is to a valid folder on the machine and that both read and
write permissions were given.

(App DB) Sources
• If the path test passes successfully, a check appears as shown:
Figure 23. Configuration Path – Test Passed
4.3.3. SUPPORTED APP DB TOOLS

Currently the following tools are supported by the App DB, listed alphabetically. Claroty will
provide instructions for the exact file type and process used in order to obtain the file. This
information is available upon request.
Table 109. App DB Tools Supported
Vendor Family Tool File Extension
ABB 800xA afw/zip with afw

files
ABB AC800M ABB AC 800M Compact Control Builder Directory with *.con
and *.hwu files
ABB Composer Directory with *.ebp

file
ABB Advant .zip
ABB Totalflow PCCU .zip, .fcu
B&R Automation Studio v3 /v4 .zip
CodeSys V3 ZIP/PROJECT
Emerson DeltaV Exploring DeltaV .fhx, DT.SCR
GE Bently Nevada 3500 System Configuration Directory with 'as-

setinfo.txt' and .xml
file (e.g.
'BN-3500.xml')
GE MarkVI ToolBoxST Entire project direc-

tory, zipped
GE rx3i,9030 PacsAnalyzer .txt
GE rx3i,9030 Proficy Machine Edition .SwxCF
Generic
Generic SCL=Substation Configuration File .icd, .ssd, .scd, .cid, .i

id, .sed, .xml
Honeywell EHPM CSV (.re)
Honeywell Experion Ctools .xls
Honeywell Experion SIT .cab
Kepware Kepware OPC Kepware OPC .json/.zip
Mitsubishi MELSEC-Q GX Works2
Mitsubishi MELSOFT GX Developer .zip/folder
Mitsubishi Melsoft (R) GX Works3 .gx3
Mitsubishi Hitachi DIASYS Netmation DIASYS Netmation .zip

Power Systems
(MHPS)

(App DB) Sources
Motorola ACE, MOSCAD ACE3600 System Suite Tools 17.50 .zip
Omron Generic CX-One .cxp/.cxt
Red Lion Redlion HMIs Crimson 3.0/3.1 .cd3, .cd31
Rockwell ISaGRAF (multiple) .zip, .ccwarc
Rockwell RSLinx .rsh
Rockwell AAdvance AADvance Log Collection Tool .xtx
Rockwell AssetCentre AssetCentre .raai
Rockwell FactoryTalkView / RSView FactoryTalkSE/FactoryTalkME .apa
Rockwell ICSTriplex ICSTriplex Log Collection Tool .ztx/.zxm
Rockwell MicroLogix Factory View .acd
Rockwell MicroLogix RS System Ferret DEVICES.xml
Rockwell MicroLogix RSLogix 5 .rsp
Rockwell MicroLogix RSLogix 500 .rss
Rockwell MicroLogix RSLogix 5000 .acd
Rockwell (ISaGRAF) Trusted TMR IEC 1131 Toolset .pia
Schneider Concept Concept .ccf
Schneider EcoStruxure Building Operation .xbk
Schneider GP-3000 GP-Pro EX .prx
GP-4000
SP-5000
LT-3000
LT-4000
ST3000 IPC (PC/AT)
Schneider M221 SoMachine .smbp
Schneider Modicon, Quantum Unity L/XL .stu
Schneider SCADAPack 32 Telepace Studio .tpj
Schneider TSX Micro, Premium PL7 .stx
Schneider Twido TwidoSuite .twd, .xtwd
SEL SEL AcSELerator .zip
SEL SEL AcSELerator QuickSet .rdb
Siemens - Proneta .xml
Siemens LOGO!Soft LOGO!Soft Comfort .lnp
Siemens PCS7 PCS7 .zip
Siemens S7 TiaPortal (v13, 14,15,16) .zip, .zap13, .zap14, .

zap15
Siemens S7/T3000 Step7 .zip
Siemens Simatic Softshop 505 .fss
Siemens Siprotec Digsi4 .zip
Siemens Siprotec Digsi5 .zip, .dex5
Triconex Tricon/Trident/TriGP TriStation 1131 .pt2
Xinje Xinje PLCs XDPPro .xdp
Yokogawa CentumVP/CS3000 .csv
Yokogawa CentumVP/CS3000 CentumVP Entire project direc-

tory, zipped

CTD Reference Guide Importing Assets via CSV
Yokogawa Prosafe ProsafeRS Entire project direc-

tory, zipped
4.4. Importing Assets via CSV

CTD provides an optional asset inventory capability that enables Administrators to manually on-
board assets from a CSV file. This Import Assets feature is valuable for Administrators who want to
perform bulk on-boarding of assets manually or to perform bulk changes to their Asset Inventory,
such as changing their asset names.
4.4.1. PREREQUISITES
• Only users with admin rights working on a Site can use the Import Asset feature.
• Select a site. If you are working in the EMC, select a target site before proceeding:
Figure 24. Selecting a site
4.4.1.1. Recommendations
• Claroty recommends the following when importing assets via CSV:

• Asset properties not compliant with section Table & Guidelines for Structuring the CSV Import
File (page 151) are skipped. These assets will appear in a pop-up that will present the assets
and the reasons why they failed.
• For example: For an IP or MAC value, when the entry is not a valid address with the required
format, it is ignored.
• IP address format – nnn.nnn.nnn.nnn (such as, 91.6.191.10)
• MAC address format – xx:xx:xx:xx:xx:xx (such as, 00:50:56:A0:E7:64)
• Instead of building the CSV file from scratch, download your existing asset list, from the Assets
Page, to minimize input errors. Then, modify the CSV file.

Figure 25. Default Columns on the Assets page
Figure 26. CSV File with Default Columns highlighted in Red; system added columns ‘Asset ID’, ‘Site ID’, ‘Is Ghost’ in
Blue
4.4.2. IMPORTING ASSETS

To import assets:
1. Press the Import Assets button.

2. Press Choose File to browse and select the modified CSV file:

Figure 27. Selecting CSV file to import
3. Choose the TestFile button to check the validity of your CSV file.
4. Check the Test Summary output to determine the success of the Import Assets operation.
• This response tells you how many assets will be imported successfully; how many are
expected to fail; and the reasons for any failures.
Figure 28. Sample of Successful Test Summary Results

IMPORTANT
Claroty recommends that users use the Test feature to determine the success
of your CSV file. The Import operation displays the results in the same man-
ner as with the ‘Test’ feature.
Figure 29. Samples of Test Summary Results with Errors
5. If necessary, modify your CSV input file according to the Summary output and repeat the Test
step.
6. After you are satisfied with the test summary results, press the Import button to implement
your changes.

Figure 30. Sample Import Summary Result
For more details on the Summary Results, see Summary Results (page 156).
NOTE
If the system is in Operational mode when the CSV file is imported, it is possible that
New Asset alerts or Information Change alerts will be displayed.
The alerts raised will need to be approved; until these approvals are done, the
system will not honor the new values.
4.4.3. TABLE & GUIDELINES FOR STRUCTURING THE CSV IMPORT FILE
Table 110. CSV Import Table: Parameters whose Values can be Modified
Parameter Parameter Description Type Parameter Example/Notes

Name Details
PARAMETERS WHOSE VALUES CAN BE MODIFIED
Name The asset name Text 10.91.6.91
See notes: Name/Display

Name (page 154)
Display Name The display name for the asset Text 10.91.6.91
See notes: Name/Display

Name (page 154)


Name Details
Criticality A value representing the rela- List Low Low

tive criticality of this asset to
Medium See notes: Type/Criticality
the overall operation
High
Type The asset type List See Supported Endpoint

Asset Types
See notes: Type/Criticality
(page 218)
Custom At- Any user defined custom at- List As configured LOB
tributes tributes by Admin and
See notes: Custom Attrib-
defined by
utes (page 155)
user
OS The Operating System for this List See notes: Supported Operating
asset Systems - Passive (page 165)
Virtual Zone The name of the assigned vir- Text PLC: Rockwell
tual zone
See notes: Custom Attrib-
utes (page 155)
Network The network assigned to this Text Default or Default

asset The name of a network named net-
See notes:Network (page 154)
in the system (or Default). work
Vendor The equipment vendor of the Text Rockwell Automation

asset
PARAMETERS WHOSE VALUES SHOULD NOT BE CHANGED
Asset ID The internal ID assigned to the Numeric Used to 28

asset by the system uniquely iden-
tify the asset
for the CSV.
Site ID The ID of the current site Numeric Used to 1

uniquely iden-
tify the asset
for the CSV.
NETWORK PROPERTIES WHOSE VALUES SHOULD NOT BE CHANGED
Additional values can be added for these properties (except for VLAN)
IP The asset’s IP address Text 91.6.91.10
See notes: IP/MAC address-

es (page 155)
MAC The asset’s MAC address Text 00:50:56:A0:E7:64
See notes: IP/MAC address-

es (page 155)
Address The asset’s gateway address Text 001B8EE0049F:Card 1 \ Addr

727
VLAN The number for the VLAN Numeric N/A
NOTE
No addi-
tional val-
ues for
VLAN are
possible.


Name Details
DEFAULT PARAMETERS
These parameters can be modified, but preference is given to the information obtained from sniffing/active query/
etc.
Firmware The firmware version for this Text Chemical_plant

asset
See notes: Firmware (page 154)
Model The hardware model Text 1756-ENBT/A
See notes: Model (page 155)
PARAMETERS THAT CANNOT BE CHANGED VIA CSV IMPORT
WARNING
Any changes to these parameters will be ignored
Active Queries Queries used to actively monitor the system and discover assets Not supported
Class Whether the asset is a security (IT) or an ICS (IOT) type device or an Not supported
Internet of Things (IoT) device
Custom Informa- Custom information for this asset Not supported

tion
First Seen The first date and time this asset was seen in the communication in the Not supported
network
Host Name The name of the host Not supported
Last Seen The last date and time this asset was seen in the communication in the Not supported
network
Mode Whether this asset is in training mode or not Not supported
Old IPs List of previous identified IPs for this asset Not supported
Parsed Asset Whether this asset was identified by sniffing the network or from parsing Not supported
a configuration file (Yes/No)
Protocols The list of protocols that the asset uses for communication Not supported
Purdue Level The level in the Purdue model. Not supported
Risk Level The risk level assigned to this asset; How often the asset generates alerts, Not supported
and the severity of these alerts
Serial Number The serial number of this asset Not supported
Site The name of the CTD Site Not supported
NOTE
The asset can only be overridden by the Admin.
4.4.4. CSV IMPORT GUIDELINES

The system enables input of CSV files that comply with the following conventions:
• The values in the table are not case sensitive.

• However, on free text fields, the UI will display the exact parameter names and capitalization.
• Empty fields will be ignored by the system, whether they are any of the following:
• Blank
• A dash (-)
• ‘N/A’
• Max Length of text fields – 256 characters
4.4.4.1. Name/Display Name
• These fields are interdependent:

• Name – The asset name, which may contain additional information such as "ghost" or "exter-
nal". The names are case sensitive.
• Display Name – Claroty recommends changing this parameter instead of changing the Name
parameter. When you change the Display Name, it changes the Name automatically without
effecting any additional attributes (like ghost, external). The Display Name is case sensitive.
4.4.4.2. Type and Criticality
• Changing these values in the imported CSV file will have the same effect as changing these fields
from the UI. The new value will be kept unless you change it again.
• Type – The specific type of asset; includes IoT types in addition to IT and OT ones. The system
derives the Class based on the Asset Type.
4.4.4.3. Default Parameters (for example, Firmware version):
• The system gives preference to the information it can obtain from the sniffing or from an active
query. The system will only take the information from the imported CSV file for these default
values when it cannot get the information from any other source.
• If an asset’s Firmware is changed through the Import CSV, when the system sniffs this asset
again in Operational mode, if it conflicts with the data supplied via the CSV, it will raise an Asset
Information Change alert.
4.4.4.4. Mandatory Parameters
• Network
• Network is always a mandatory column
• Note there may be only one network.
• When only the Default network exists, the network column should be present, and labelled
‘Default’.
• An entry without a network value will result in an error.
• When a new network is added, the Administrator must associate assets to it.
• When parsing an asset from one network to another, the system will duplicate it and not
move it between the networks.
• Key Parameters - Asset ID and Site ID:
• Asset ID and Site ID are used to uniquely identify the asset for the CSV.

• Rack Slots and Nested Devices use these keys to correlate information.
4.4.4.5. Multiple IP/MAC addresses
• Multiple IP and multiple MAC addresses are supported in a limited manner:
NOTE
The tool is not intended for editing multiple IPs and MACs simultaneously. A
common consequence of this is merging assets unintentionally.
• Adding new assets with multiple IP and MAC addresses simultaneously is supported as follows:
• Multiple IPs work with a single MAC
• A single IP with Multiple MACs works
• A combination of a new asset with both. It will only consider the newly added IPs
• Editing assets with multiple IP and MAC addresses simultaneously is supported as follows:
• All the information should be added only to the first IP address
• The first MAC address is taken when no IP address previously exists
• When there is no MAC address, it gets added to the asset by its Asset ID
• If a user makes a mistake in the Import CSV, delete the specific asset/s via the UI and import
it/them again.
4.4.4.6. Operating System

You can choose from the list of supported Operating Systems.
4.4.4.7. Custom Attributes

Custom Attributes are supported (refer to the CTD User Guide for details)
4.4.4.8. Virtual Zones
• If a virtual zone already exists for an asset being imported via CSV, the zone is editable.
• New assets can be added to the existing zones.
• Assets can be moved between zones.
• You cannot create a virtual zone via the CSV.
• There should not be a Virtual Zone column in the CSV when importing assets for a new site or
when you want to import new assets without assigning them to a pre-existing zones.
4.4.4.9. Model
If an asset’s Model number is changed through the Import CSV, when the system sniffs this
asset again in Operational mode, if it conflicts with the data from the CSV, it will raise an Asset
Information Change alert.
4.4.4.10. Hostname
The Hostname is not editable, even if it is from a new asset.

CTD Reference Guide Exporting Assets to CSV
4.4.4.11. Ghost Assets

Ghost Assets cannot be imported via CSV.
4.4.5. SUMMARY RESULTS

The CSV Asset Import is successful when the system correctly updates existing assets and/or
imports new assets. See the following for several common error messages.
NOTE
‘Success’ means the system added these assets to the queue for processing.
The Summary Results pop-up displays the amount of assets successfully onboarded and the
amount of assets that failed, with the relevant failure message.
NOTE
CTD can import an asset that has no data other than its network. In this case, it is
imported as ‘Asset# ‘.
Table 111. Common Error Messages for CSV Import
Message Meaning/Resolution/Notes
Network <network name> does not ex- The network name in the CSV file is not configured in the CTD as a valid network
ist and cannot be used.
Network <network name> does not ex- The selected CSV file is empty
ist
Invalid CSV structure Please use the same structure of the asset CSV report; See Guidelines for Struc-
turing the CSV Import File (page 133)
Internal errors while processing asset Check that the CSV file meets the guidelines for structuring the file.
details
4.5. Exporting Assets to CSV

1. Before performing the Download assets operation, set up the Assets View with the relevant
columns and display them in the desired order.
Figure 31. Setting up the Assets View Page with the Relevant Parameters

2. Press More > Download to export your existing assets from the Assets Page.
• Choose the CSV format.
• Only choose the Rack Slots and/or Nested Devices options when you intend to modify
them.
NOTE
If you choose Nested Devices, ensure you include the Address parameter in
the Assets Page display before downloading (it is not a default parameter).
• The resulting file will contain your current assets inside a file with the valid CSV structure.
• Pressing Download will download selected assets or filtered assets. If you select assets, it
shows only the selection from the partial filtered list.
If you don’t select assets, it downloads all the assets in the specific applied filter.
Figure 32. Download Report window
Figure 33. Example of Exported Assets with Custom Attributes
3. Open and modify the exported CSV file while retaining the existing structure.
• Be careful to only modify the parameters that you need to change

• Beware that a change you make in the CSV file will only be applied if the input conditions
are met as per Parameter Details.

CTD Reference Guide Upgrade Permission Mapping
5. Upgrade Permission Mapping
In versions 4.3.2 and previous of CTD, user groups were assigned access on a site-by-site basis to
an entire site or to groups of assets on a site. The permission also specified Admin, Write, or Read
access to the site or assets.
In version 4.4.0 and above of CTD, user groups can not only be assigned access to specific sites
and groups of assets, they can also be restricted to the areas of CTD that they can access and what
they are permitted to do in those areas.
When upgrading from version 4.3.2 and below to version 4.4.0 and above, permissions are as-
signed as follows:
Table 112. Permission Mapping
Old Permission Area of CTD New Permission
Admin All Admin
Write Dashboards & Reports Manage
Visibility Manage
Threat Detection Manage
Threat Detection - Download Network Capture Allowed
Risk & Vulnerabilities Manage
Investigation Manage
Settings - Site Management Allowed
Settings - Admin Denied
Settings - Data Sources Denied
Read All areas but Settings View
Settings Denied
For further information about permissions in version 4.4.0 and above, see Assigning Role-based
Permissions (RBAC) to Groups in the Administration Guide.

CTD Reference Guide CTD Required Open Ports
6. CTD Required Open Ports
The following firewall ports must be open for:
EMC (page 160)
CTD Site
Sensor
Edge
6.1. Required Firewall Rules for EMC Connectivity

From Destination Protocol/Port Purpose Direction
Customer Net- EMC HTTPS (443) Access to the EMC web interface Inbound
work
Customer Net- EMC SSH (22) Access to the EMC CLI Inbound
work
EMC Multiple Serv- Multiple Services SRA, DNS, LDAP, NTP, SMTP, etc Outbound
ices
CTD EMC SSH (22) (Default) Reverse SSH Tunnel between the Inbound (EMC)
Site and the EMC.
SSL (443) (If configured) Outbound (Site)
6.2. Required Firewall Rules for CTD Site Connectivity

From Destina- Protocol/Port Purpose Direction
tion
Customer CTD HTTPS (443) Access to the CTD web interface Inbound
Network
Customer CTD SSH (22) Access to the CTD CLI Inbound

Network
CTD Multiple Multiple Services SRA, DNS, LDAP, NTP, SMTP, etc Outbound
Services
Site and the EMC.
SSL (443) (if configured) Outbound (Site)
Sensor CTD SSH (22) (Default) Reverse SSH Tunnel between the Inbound (CTD)
Sensor and the CTD.
SSL (443) (If configured) Outbound (Sensor)
6.3. Required Firewall Rules for Sensor Connectivity

Customer Net- Sensor SSH (22) Access to the Sensor CLI Inbound
work
Sensor CTD SSH (22) (Default) Reverse SSH Tunnel between Inbound (CTD)
the Sensor and the CTD.

CTD Reference Guide Required Firewall Rules for Edge
Connectivity
6.4. Required Firewall Rules for Edge Connectivity

CTD Edge Host SSL (443) Sending processed Edge file to CTD Inbound
NOTE
Edge can be run offline and saved to a file, which does not require the above
connectivity.
6.5. Required Firewall Rules for CTD Site Connectivity

From Destina- Protocol/Port Purpose Direction
tion
Customer CTD HTTPS (443) Access to the CTD web interface Inbound
Network
Customer CTD SSH (22) Access to the CTD CLI Inbound

Network
CTD Multiple Multiple Services SRA, DNS, LDAP, NTP, SMTP, etc Outbound
Services
Site and the EMC.
SSL (443) (if configured) Outbound (Site)
Sensor CTD SSH (22) (Default) Reverse SSH Tunnel between the Inbound (CTD)
Sensor and the CTD.
6.6. Required Firewall Rules for Sensor Connectivity

Customer Net- Sensor SSH (22) Access to the Sensor CLI Inbound
work
Sensor CTD SSH (22) (Default) Reverse SSH Tunnel between Inbound (CTD)
the Sensor and the CTD.
6.7. Required Firewall Rules for Edge Connectivity

CTD Edge Host SSL (443) Sending processed Edge file to CTD Inbound
NOTE
Edge can be run offline and saved to a file, which does not require the above
connectivity.

CTD Reference Guide System Boundaries
7. System Boundaries
The system boundaries show the data collection boundaries status, baselines retention, and the
number of sensors you can use.
7.1. Data Collection Boundaries Status (only Admin)

The data collection boundaries status shows the boundaries of collecting assets and baselines in
the following colors:
• Green – system is collecting assets/baselines.

• Red – system stopped collecting assets/baselines.
To see the data collection boundaries status:
• Click Settings >System Health Dashboard.
Figure 34. Data Collection Boundaries Status
NOTE
The red status occurs only in uncommon situations.

CTD Reference Guide Supported Browsers
Table 113. Data Collection Boundaries
Assets Limit Baselines Limit
30K internal 1,000,000 baselines per protocol
20K external More than 50K baselines per protocol in 5 minutes
NOTE
The limits are configurable via the CLI.
7.1.1. STEPS TO TAKE WHEN ASSETS REACH BOUNDARY

See Steps to take when Assets reach boundary in the Troubleshooting Guide section.
7.1.2. STEPS TO TAKE WHEN BASELINES REACH BOUNDARY

See Steps to take when Baselines reach boundary in the Troubleshooting Guide section.
7.2. Supported Browsers

CTD supports the following web browsers:
• Google Chrome, version 91.0.4472.114 and above

• Microsoft Edge, version 88 and above
NOTE
CTD is optimized for display resolutions of 1680 X 1050 and higher.
7.3. Baseline, Asset, and Alert Retention

To optimize database performance, inactive Baselines, Assets, and Alerts are deleted from the
system after set periods of time, as follows:
Table 114. Deletion Times
Data Deletion Time
Base- Baselines not active in the system are removed after one month. This affects all the system components such
lines as Insights and Assets.
NOTE
If you need to save inactive Baselines for more than a month, contact Claroty Support for
assistance with configuration via the CLI.

CTD Reference Guide Number of Sensors
Data Deletion Time
Assets Inactive Assets are deleted from the system if last seen under the following conditions:
• IT and IoT Assets - If last seen more than 12 months ago on an internal subnet, or more than 6 months ago
on an external or out-of-scope subnet
• OT Assets - Retained regardless of date last seen
• Ghost Assets - If last seen more than 3 months ago
Alerts • In general, inactive Alerts are deleted after 12 months.

• Host Scan, Port Scan, and Login Alerts are deleted after 3 months.
7.4. Number of Sensors

The maximum number of sensors attached to a single site varies and is determined by the
number depicted in the specific license attached to the CTD site. For the current maximum limit,
there is a technical limit of 50 sensors per CTD site, however this is not recommended in most
scenarios. For most installations, sensors should be limited to no more than 20 per CTD site. If a
design requires more than this, please contact the Claroty post-sales team to create the appropri-
ate architecture.
NOTE
This limit does not cover Sensor Lite integrations, which are limited by the accumu-
lated bandwidth aggregated by all Sensor Lites.
7.5. DNS Record and Cleanup Thresholds

To optimize the bandwidth utilized by the EMC, the DNS storage and cleaning cycles settings are as
follows:
DNS storage and cleaning cycle settings Default value

max_amount_of_dns_artifacts 55,000
dns_artifacts.clean_chunk_size 5000
dns_artifacts.clean_interval.hours 2 hours
If an adjustment is required to these settings, contact your Claroty Support representative for
assistance.

CTD Reference Guide Supported Operating Systems -
Passive
8. Supported Operating Systems - Passive
CTD passively detects traffic from all devices in the network, and can identify many device operat-
ing systems from passive traffic only.
For other devices, further information can be captured through other means, such as Active
Detection, AppDB, or Edge.
CTD passively detects the following operating systems:
Windows Operating Systems

• Windows 3.1
• Windows NT 3.5
• Windows for Workgroups 3.11
• Windows for Workgroups 3.51
• Windows 95 / Windows NT 4.0
• Windows 98
• Windows ME
• Windows 2000
• Windows XP
• Windows Server 2003
• Windows Vista/Server 2008
• Windows 7/Server 2008 R2
• Windows 8/Server 2012
• Windows 8.1/Server 2012 R2
• Windows 10 Beta
• Windows 10/Server 2016
Other Operating Systems

• UNIX
• Linux
• MacOS X

CTD Reference Guide Supported Passive Protocols
9. Supported Passive Protocols
The following passive protocols are supported by CTD. Not all of them are configured by default.
For information on configuring the protocols, see Configuring Passive Protocols in CTD User Guide.
NOTE
In most cases, when CTD intercepts OS from passive protocols, the information in
the packet will just be the version number (such as, 5.0, 6.1). CTD then translates it
to the OS name (6.1 --> Windows 7/Server 2008 R2).
You can see the mapping of the version number and OS name in the following link:
https://docs.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version
Table 115. Passive Protocols Supported
Protocol Vendor
ABB DMS system ABB
ABB HC800 (Infinet) ABB
ABB Melody ABB
Alspa (Multicast messages) Alstom
Altus ALnet Altus
AMS (ADS) Beckhoff
B&R INA2000 B&R
B32 Enedis
BACNET -
Bailey ABB
BSAP Bristol
CAPWAP -
Caterpillar AHS Caterpillar
CC Link IE - Field CC Link IE
CIP Rockwell
Cisco Discovery Protocol (CDP) Cisco
Citect HMI -
ClearSCADA ViewX AVIVA (Schneider)
Codesys V2 Codesys
CodesysV3 Codesys
Cognex Discovery Cognex
CoLa-A SICK
Comtrol NS Link Comtrol
Control Technologies Inc. (CTI) CTI
CPHA (Checkpoint High Availability) Checkpoint

Protocol Vendor
Cotp -
Cspv4 -
Cygnet SCADA Cygnet
DACP Willowglen
DeltaV Emerson
DHCP -
Digi real port -
Digsi4 (Siprotec 4) Siemens
Digsi5 Siemens
DLMS COSEM -
DNP3 -
DPI (over PCCC) Rockwell
Dropbox LAN-sync Dropbox
E-Terra Alstom
E-Terra Workstation -
Enhanced Modbus Themis
ENIP Rockwell
EtherCAT Beckhoff
Ethernet POWERLINK -
ITEPM - Endpoint Mapper -
ETHERNET/IP -
FINS Omron
FactoryTalk RNA -
FL-net - All Jema
FI-net- Fuji Fuji Electric
FI-net Toyoda Toyota
Focas Fanuc Robotics
Foundation Fieldbus (FF) -
Foxboro LLC Foxboro
Foxboro RTV Foxboro
FTP - SEL Schweitzer
Gaz Modem Plum
GE Bentley Nevada (BNC3500) GE
GE PAC8000 (AXE) GE
GE QuickPanel (TRAPI+HTTP) GE
GE SDI (MarkVie) GE
GE SDI Classic (MarkVie) GE
GE SRTP GE
GE-ALM GE
GE-EGD GE
GE-EGD-CMP GE
GE-iFix GE
Goose (IEC-61850) IEC
HART-IP -

Protocol Vendor
HiDiscovery Hirschmann
Hikvision Discovery Protocols Hikvision
Honeywell C200 - Ftebcip Honeywell
Honeywell EpicMo (C300 management) Honeywell
Honeywell Experion - CeeNTComm (C300,EHPM) Honeywell
Honeywell Firewall CF9 Honeywell
Hot Standby Router Protocol (HSRP) -
HP Switch HP
HTTP -
HTTP-XML (specific schemes) -
IEC101 -
IEC103 -
IEC104 -
IQ3 Trend
Keyence Host-Link Communication Keyence
JRC Vessel Display JRC
Keyence KV Studio Keyence
Keyence Logger Keyence
Knapp Knapp
Kongsberg Kongsberg
Lantronix Serial GW Lantronix
Koyo (HEI/K-Sequence/DirectNet) Koyo
Linux High Availability Linux
LLDP -
MasterBus 300 ABB
Matrikon OPC Tunneler Matrikon
MaxDNA (maxNET) Valmet
MDLC data Motorola
MDLC management Motorola
Melsec Mitsubishi
Melsoft Mitsubishi
Microsoft DCE RPC - ABB DCS Service Manager -
Microsoft CIFS (SMB) -
Microsoft DCE RPC -
Microsoft DCE RPC - ABB DCS Service Manager -
Microsoft NTLMSSP (Auth protocol) -
Microsoft RDP -
Microsoft SAMR -
Mitsubishi GOT Mitsubishi
MMS (IEC-61850/ICCP/TASE.2) -
MNDP Mikrotik
Modbus -
Modbus Modsoft Schneider
Modbus Concept Schneider

Protocol Vendor
Modbus Eltec Eltec
Modbus Execload -
Modbus GE Enervista GE
Modbus ScadaPack ScadaPack
Modbus Schneider Schneider
Modbus Twinsoft Twinsoft
Modbus Xinje
MQTT -
NASNavigator Buffalo
NDP Nortel
NetBIOS Browser (UDP 138) -
NetBios Datagram Service -
NMEA-0183 NMEA
Odeq Yokogawa
Omniflow Flow computer Omniflow
OPC-DA -
OPC-UA
OPTO OPTO
OPTO MMP OPTO
Opto SoftPAC Agent Opto
Ovation Emerson
Ovation ADMD Emerson
Ovation Alarm Emerson
Ovation DBXmit Emerson
Ovation PTEdit Emerson
OvationRPC Emerson
P+F DCP Pepperl+Fuchs
P2 Siemens
PCCC Rockwell
PCWin Toyoda
PI1 OSISoft
PI3 OSISoft
POP3 -
Portwell Portwell
PowerLogic Discovery Schneider
ProConoS (TCP 20547) Phoenix Contact
Profinet DCP -
Profinet I/O -
Profinet Real-Time -
Prosoft Discovery -
PRP -
PTP -
Radius -
RCDP Ruggedcomm

Protocol Vendor
Redlion Crimson Redlion
Redlion NView-2 Discovery Redlion
RNRP ABB
ROC Plus Emerson
RTCP -
S7Comm Siemens
S7Comm Plus Siemens
Sattbus -
SBUS SAIAS
Schneider NetManage Schneider
Schneider EGX UDP 59 Schneider
Schneider ION Schneider
SECSGEM -
Siemens FWL LOAD (firmware upload) Siemens
Siemens IEM Siemens
Sinaut FW8 Siemens
SIP -
Skinny (SCCP) Cisco
SLMP (CC Link IE Field Basic) CC Link
SNMP -
Spirit ABB
Spotify P2P Spotify
SSH -
Sunny WEBBOX SMA
Symphony Plus ABB
Synchrophasor -
T3000 Protocols Siemens
TDS Microsoft
Telnet - Hirschmann Hirschmann
Telnet - DeltaV Emerson
Telnet - Moxa Moxa
Telnet - Omniflow Omniflow
Telnet - SEL Schweitzer
TFTP -
Totalflow ABB
TRDP Process Data TCNOpen
Triconex Tristation Schneider
Triconex TSAA Schneider
Tridium Niagara
TTSAC (Sistema Avanzado de Control -
UDLD Cisco
Valmet DNA Alarms Valmet
Valmet DNA Damatic configuration Valmet
Valmet DNA Damatic data -

Protocol Vendor
Valmet DNA Data -
Valmet DNA Frontend -
VNC -
VNET (VHF) Yokogawa
WAGO WAGO
Windows Update Delivery Optimization Microsoft
WonderWare Suitelink IOTalk WonderWare
X-Pact Data -
X-Pact Diagnostics SMS Group
X-Pact Discovery SMS Group
XG5000 (LS) LS Electric

CTD Reference Guide Data Encryption and Password
Management in CTD
10. Data Encryption and Password Management in CTD
The following are common questions asked about data encryption and password management in
CTD.
Are there any hard-coded passwords (encrypted or not) in the product code? If so, how can
they be changed during installation?
• Admin user and password - Configured during installation. Stored in the DB, encrypted with RSA
algorithm
• Bootstrap password - Set by the user during installation
• DBs passwords - Can be configured in the lkpo.conf file
What is the encryption level (or technology) used to store any password within the CTD per
application/module?
• Passwords are stored in the DB and encrypted with the best practice RSA encryption algorithm.
Does CTD store any passwords in cleartext?
• We do not use cleartext under any circumstances.
What is the encryption level (or technology/protocol) used when credential passwords are
sent over the network?
• When data is transferred, it is either over SSL or SSH.
Does CTD transfer any type of password in cleartext over the network using insecure proto-
cols such as HTTP, LDAP, FTP, or Telnet?
• CTD does not transfer any data under any circumstances using cleartext.

CTD Reference Guide Services and Dependencies
11. Services and Dependencies
CTD has several services and dependencies running on the machine.
11.1. CTD Running Services

• icsranger
• icsranger-watchdog
11.2. Dependent Services

• mariadb
• rabbitmq-server
• redis
• postgressql-11.2

CTD Reference Guide Supported Activity Types
12. Supported Activity Types
Table 116. Activity Types
Activity Types
Active Baseline
Alert Acknowledged
Alert Assign
Alert Auto Resolved
Alert Enrichment
Alert Ignored
Alert New
Alert Non-Relevant
Alert Resolved
Alert Resolved By Rule
Alerts Resolved
Asset Changed IP
Asset User Changed Info
Comment Add
Communication Down
Communication Up
Message
Policy Invalidated
Policy Updated
Policy Validated
Rule Added
Site Down
Site Up
Training Mode Off
Training Mode On

CTD Reference Guide Claroty Syslog Specification
13. Claroty Syslog Specification
13.1. Introduction
CTD can be configured to send Syslog messages to external tools such as SIEM solutions, analytic
tools, and log collectors. Syslog messages can be configured to be sent automatically for:
• Alerts
• Events (of which an alert is composed)
• Insights
• System health monitoring information.
NOTE
Since Syslog is essentially a real-time solution, there might be mismatches between
Syslog logs and data that was subsequently updated in CTD.
The system can send the above configured messages to Syslog, allowing users to connect CTD
data into 3rd party systems such as SIEMs and System Management Tools.
NOTE
Currently TLS 1.2 is supported through Syslog.
SYSLOG CONFIGURATION
For information on Syslog configuration, see Configuring Syslog Integration in the CTD Admin Guide.
13.2. CEF Format
IMPORTANT
Prior to CTD 4.3.0, the CEF format did not fully align with the CEF Specification
and as a result created parsing errors. As part of the 4.3.0 release, we rebuilt the
CEF format to align with the industry specification. The previously CEF format was
renamed "CEF (Legacy) and is being retained to minimize any integration disruption
during upgrades. We recommend all customers to reconfigure their syslog logging
to use the the new CEF format going forward. The CEF Legacy format is not being
supported going forward and will be removed altogether in a later release.

CTD Reference Guide CEF Format
Each CEF message consist of 3 parts: The Syslog prefix, the CEF Header, and CEF Extensions. For
example:
• Syslog prefix: Jan 18 11:07:53 host

• CEF header: CEF:Version|Device Vendor|Device Product|Device Version|Device
Event Class ID|Name|Severity|
• CEF extensions:[Extension]
13.2.1. CEF HEADER

Table 117. CEF Header
# CEF Header Fields Expected Values
1 CEF CEF
2 The version of the CEF format 0
3 Device Vendor Claroty
4 Device Name CTD
5 Device Version CTD version #, e.g. 4.3.0
6 Device Event Class ID For Alerts: "Alert/Alert Type". Examples:
(AKA signatureId) • Alert/Baseline Deviation

• Alert/Host Scan
• Alert/Known Threat Alert
For Events: "Event/Event Type". Examples:
• Event/Baseline Deviation
• Event/Host Scan
For Insights: "Insight"
7 Name of the Event For Alerts & Events:
• Alert Type with the exception of Known Threats.

• For Known Threat type, include the actual signature detail, e.g. Known Threat:
Threat ET TROJAN DNS Reply Sinkhole - Anubis/BitSight
For Insights:
• Insight Name
8 Severity (between 0 - 10) CTD uses these default severity values to map Alerts, Events and Insights
• 2 = Low
• 5 = Medium
• 7 = High
• 10 = Critical
Examples:
• Alert Test Message (CEF Format) (page 180)

• Event Test Message (CEF Format) (page 183)

13.2.2. CEF EXTENSIONS
IMPORTANT
Only use keys that are explicitly listed in the table.
The extensions vary by message type as detailed in the following sections:
• Alert Specific Keys - CEF Format (page 177)

• Events Specific Keys - CEF Format (page 180)
• Insights - CEF Format (page 183)
13.2.3. FREQUENCY AND TIMING OF SYSLOG LOGGING
• Each Alert/Event/Baseline is logged only once

• Baselines and Events are only logged on creation
• Alerts are logged once they are qualified (a threshold is met)
• Auto-resolve/unqualified/archived alerts are not sent
NOTE
These alerts are not sent by default because they can cause performance issues.
If your organization needs these alerts to be sent, contact Claroty Support for
assistance.
13.2.4. ALERT SPECIFIC KEYS - CEF FORMAT

In addition to the CEF Header, the following fields may be logged if relevant and available for the
specific alert. If a value is not available or if there are multiple values for a field that can't take
multiple values, the key will not be logged. In addition, the order of logging will vary from message
to message.
13.2.4.1. CEF Extensions for Alerts
Table 118. CEF Extensions for Alerts
Key Value Description Example
suser Source user name suser=johnf
src The IPv4 address of the primary asset involved in the event. src=123.45.56.78
c6a2=SourceIPv6 Address The IP address of the primary (source) asset involved in the c6a2=SourceIPv6
insight (if IPv6)
Address c6a2=[addr]
spt Source Port spt=1234
smac The MAC address of the primary asset involved in the event
shost Source host name. May be either FQDN or hostname shost=wk1.do-

main.com

duser Destination user name duser=ronaldf
dhost Destination host name. May be either FQDN or hostname dhost=work3
dst The IPv4 address of the secondary asset involved in the dst=123.45.56.78
event. If multiple destinations exist for the alert, do not
include them
c6a3=Destination IPv6 Address The IP address of the destination asset involved in the event c6a3=Destination IPv6
(if IPv6) Address c6a3=[addr]
dpt Destination Port dpt=443
• If multiple destinations exist, do not include them
dmac The MAC address of the secondary asset involved in the -

insight
proto Transport protocol, i.e. TCP, UDP TCP
externalID The ID of the alert which this event is part of externalID=[alert#]
cat Category/Type of the Alert cat=security/failed log-

in
start Timestamp of alert creation start = alert timestamp
Format is: MMM dd yyyy HH:mm:ss
Timezone should be UTC
msg Full description of the event msg = Known

Threat: Threat ET AT-
TACK_RESPONSE Pos-
sible Lateral Move-
ment - File Creation
Request in Remote
System32 Directory
(T1105) was detected
from 10.86.35.15 to
10.86.35.19
destinationservicename Service name being highlighted as risk (if known) destinationservice-

name=http
• If multiple destinations exist, don't include them
cs1label=SourceAssetType The asset type of the primary asset, e.g. Engineering Station cs1label=SourceAsset-
Type
cs1 = [Asset Type]
cs2label=DestAssetType The asset type of the secondary asset, e.g. Engineering Sta- cs2label=DestAsset-
tion Type
• If multiple destinations exist, don't include them cs2=[Asset Type]
deviceExternalId Name of the site generating the message DeviceExternalId= Si-

teABC
cs3label=SourceZone Source Zone Name cs3label=SourceZone
cs3=Manufacturing
cs4label=DestZone Destination Zone Name cs4label=DestZone
• If multiple destinations exist, don't include them cs4=Manufacturing
cn1=IndicatorScore Indicator Score cn1label=Indicator-

Score

cs6=CTDlink URL for viewing the event in CTD cs6=CTDlink
cs6=https://[insert ctd
url to alert]
filepath The filepath or file share fiepath = \\host-

name\Users
• Use for Open SMB Share insight
Configuration Download Example

<14>Jun 17 2021 12:39:52 23663d5b48db CEF:0|Claroty|CTD||Alert/Config-
uration Download|Configuration Download|10|src=10.1.30.40 dst=10.1.30.1
smac=00:50:56:b9:e2:ad dmac=00:1d:9c:c0:04:9d externalId=47 cat=Integri-
ty/Configuration Download start=Jun 17 2021 12:39:15 msg=Configuration
Download: Configuration Download critical change operation was performed
for the first time by 10.1.30.40 on 10.1.30.1 deviceExternalId=Default
cs1Label=SourceAssetType cs1=Engineering Station cs2Label=DestAssetType
cs2=PLC cs3Label=SourceZone cs3=Engineering Station: Rockwell cs4Label=Dest-
Zone cs4=PLC: Rockwell cs6Label=CTDlink cs6=https://localhost:5000/detec-
tion/alert/47-1 cn1Label=IndicatorScore cn1=100<14>Jun 17 2021 12:39:24
23663d5b48db CEF:0|Claroty|CTD|4.3.0|Alert/Known Threat Alert|Known Threat:
Threat ET TROJAN Conficker.b Shellcode was detected|10|src=192.168.0.121
dst=192.168.0.104 externalId=1 cat=Security/Known Threat Alert start=Jun 17
2021 12:39:15 msg=Known Threat: Threat ET TROJAN Conficker.b Shellcode
was detected from 192.168.0.121 to 192.168.0.104 deviceExternalId=Default
cs1Label=SourceAssetType cs1=Endpoint cs3Label=SourceZone cs3=Endpoint: Oth-
er cs4Label=DestZone cs4=Endpoint: Other cs6Label=CTDlink cs6=https://local-
host:5000/detection/alert/1-1 cn1Label=IndicatorScore cn1=100
Known Threat Alert Example

<14>Jun 17 2021 12:39:24 23663d5b48db CEF:0|Claroty|CTD||Alert/Known Threat
Alert|Known Threat: Threat ET TROJAN Conficker.b Shellcode was detected|10|
src=192.168.0.121 dst=192.168.0.104 externalId=1 cat=Security/Known Threat
Alert start=Jun 17 2021 12:39:15 msg=Known Threat: Threat ET TROJAN Con-
ficker.b Shellcode was detected from 192.168.0.121 to 192.168.0.104 de-
viceExternalId=Default cs1Label=SourceAssetType cs1=Endpoint cs3Label=Sour-
ceZone cs3=Endpoint: Other cs4Label=DestZone cs4=Endpoint: Other cs6La-
bel=CTDlink cs6=https://localhost:5000/detection/alert/1-1 cn1Label=Indica-
torScore cn1=100

13.2.4.2. Alert Test Message (CEF Format)
Syslog Message String

CEF:0|Claroty|CTD|4.8.0 |Alert/Test|Test Alert|0|start=May 12 2021 17:28:33
Table 119. Alert Test Message Example
Name Description Value in Example

Protocol The name of the syslog message format in use CEF:0
Vendor The name of the vendor of the product Claroty
Product The name of the product in use CTD
Product The version number of the product in use 4.8.0
Version
Signature The category of the underlying object that the sy- Alert/Test
slog refers to:
Alert/Event/Baseline/Status Check/HealthCheck
Name The type of event. Test Alert
Severity The degree of impact of the alert, represented as 0
an integer ranging from 2 to 5 where the Severity
scale is as follows:
• 2 = Low
• 5 = Medium
• 7 = High
• 10 = Critical
start The alert creation timestamp May 12 2021 17:28:33
13.2.5. EVENTS SPECIFIC KEYS - CEF FORMAT

specific event. If a value is not available or if there are multiple values for a field that can't take
to message.
13.2.5.1. CEF Extensions for Events
Table 120. CEF Extensions for Events
suser Source user name suser=johnf
src The IPv4 address of the primary asset involved in the event. src=123.45.56.78
c6a2=SourceIPv6 Address The IP address of the primary (source) asset involved in the c6a2=SourceIPv6
insight (if IPv6)
Address c6a2=[addr]
spt Source Port spt=1234
smac The MAC address of the primary asset involved in the event
shost Source host name. May be FQDN or hostname shost=wk1.do-

main.com
dhost Destination host name. May be FQDN or hostname dhost=work3
dst The IPv4 address of the secondary asset involved in the dst=123.45.56.78
event. If multiple destinations exist, do not include them

c6a3=Destination IPv6 Address The IP address of the destination asset involved in the event c6a3=Destination IPv6
(if IPv6) Address c6a3=[addr]
dpt Destination Port; If multiple destination ports exist this key dpt=443
will not be logged
dmac The MAC address of the secondary asset involved in the -

event
proto Transport protocol, i.e. TCP, UDP TCP
externalID The ID of the event externalID=[event#]
cat Category/Type of the Alert cat=security/failed log-

in
start Timestamp of alert creation start = alert timestamp
• The format is: MMM dd yyyy HH:mm:ss

• Timezone should be UTC
msg Full description of the event msg = KHTTP: CON-

NECT for host:
go.microsoft.com:80,
remote path: go.micro-
soft.com:80
destinationservicename Service name being targeted (if known) destinationservice-

name=http
cs1label=SourceAssetType The asset type of the primary asset, e.g. Engineering Station cs1label=SourceAsset-
Type
cs1 = [Asset Type]
cs2label=DestAssetType The asset type of the secondary asset, e.g. Engineering Sta- s2label=DestAssetType
tion
cs2=[Asset Type]
deviceExternalId Name of the site generating the message DeviceExternalId= Si-

teABC
cs3=Manufacturing
cs4=Manufacturing
cn1=IndicatorScore Indicator Score cn1label=Indicator-

Score
cn2label=AlertID Alert reference for any events that map to an alert cn2label=AlertID
cn2=AlertID cn2=Alert#
cs6=CTDlink URL for viewing the related alert in CTD cs6=CTDlink
cs6=https://[insert ctd
url to related alert]
filepath The filepath for the suspicious file transfer filepath = filename
13.2.5.2. Event - Known Threat Event Example

<14>Jun 17 2021 12:39:24 23663d5b48db CEF:0|Claroty|CTD|4.3.0|Event/Known
Threat Event|Known Threat Event|10|src=192.168.0.121 dst=192.168.0.104 ex-
ternalId=9 cat=Security/Known Threat Event start=Jun 17 2021 12:39:15 msg=ET
TROJAN Conficker.b Shellcode (192.168.0.121:3285 -> 192.168.0.105:445). Sig-
nature: content:"|e8 ff ff ff ff c2|_|8d|O|10 80|1|c4|Af|81|9MSu|f5|8|ae c6

9d a0|O|85 ea|O|84 c8|O|84 d8|O|c4|O|9c cc|Ise|c4 c4 c4|,|ed c4 c4 c4 94|

&<O8|92|\\;|d3|WG|02 c3|,|dc c4 c4 c4 f7 16 96 96|O|08 a2 03 c5 bc ea 95|\
\;|b3 c0 96 96 95 92 96|\\;|f3|\\;|24 |i|95 92|QO|8f f8|O|88 cf bc c7 0f
f7|2I|d0|w|c7 95 e4|O|d6 c7 17 cb c4 04 cb|{|04 05 04 c3 f6 c6 86|D|fe
c4 b1|1|ff 01 b0 c2 82 ff b5 dc b6 1f|O|95 e0 c7 17 cb|s|d0 b6|O|85 d8
c7 07|O|c0|T|c7 07 9a 9d 07 a4|fN|b2 e2|Dh|0c b1 b6 a8 a9 ab aa c4|]|e7
99 1d ac b0 b0 b4 fe eb eb|"; deviceExternalId=Default cs1Label=SourceAs-
setType cs1=Endpoint cs3Label=SourceZone cs3=Endpoint: Other cs4Label=Dest-
Zone cs4=Endpoint: Other cs6Label=CTDlink cs6=https://localhost:5000/detec-
tion/alert/1-1 cn1Label=IndicatorScore cn1=100 cn2Label=AlertID cn2=1
13.2.5.3. Event - Protocol Example

<14>Jun 17 2021 12:39:52 23663d5b48db CEF:0|Claroty|CTD|4.3.0|Event/
Protocol|Protocol|10|src=10.1.30.40 dst=10.1.30.1 smac=00:50:56:b9:e2:ad
dmac=00:1d:9c:c0:04:9d externalId=500 cat=Integrity/Protocol start=Jun 17
2021 12:39:15 msg=Editing was done on Symbol object (Operation: Cre-
ate Instance) deviceExternalId=Default cs1Label=SourceAssetType cs1=Engi-
neering Station cs2Label=DestAssetType cs2=PLC cs3Label=SourceZone cs3=En-
gineering Station: Rockwell cs4Label=DestZone cs4=PLC: Rockwell cs6La-
bel=CTDlink cs6=https://localhost:5000/detection/alert/47-1 cn1Label=Indica-
torScore cn1=100 cn2Label=AlertID cn2=47
13.2.5.4. Event - Baseline Deviation Example

<14>Jun 17 2021 12:39:53 23663d5b48db CEF:0|Claroty|CTD|4.3.0|Event/
Baseline Deviation|Baseline Deviation|10|src=10.1.30.40 dst=10.1.30.1
smac=00:50:56:b9:e2:ad dmac=00:1d:9c:c0:04:9d externalId=475 cat=Integri-
ty/Baseline Deviation start=Jun 17 2021 12:39:15 msg=CIP : Set Attribute
'Recon Data' of object UserTemplate deviceExternalId=Default cs1Label=Sour-
ceAssetType cs1=Engineering Station cs2Label=DestAssetType cs2=PLC cs3La-
bel=SourceZone cs3=Engineering Station: Rockwell cs4Label=DestZone cs4=PLC:
Rockwell cs6Label=CTDlink cs6=https://localhost:5000/detection/alert/47-1
cn1Label=IndicatorScore cn1=100 cn2Label=AlertID cn2=47

13.2.5.5. Event Test Message (CEF Format)

CEF:0|Claroty|CTD|4.8.0 |Event/Test|Test Event|0|start=May 12 2021 17:28:33
Table 121. Alert Test Message Example

Version
Signature The category of the underlying object that the sy- Event/Test
slog refers to:
Name The type of event. Test Event
Severity The degree of impact of the event, represented as 0
• 0 = Test purposes
• 2 = Low severity
• 3 = Medium severity
• 4 = High severity
• 5 = Critical severity
start The alert creation timestamp May 12 2021 17:28:33
13.2.6. INSIGHTS - CEF FORMAT

specific Insight. If a value is not available or if there are multiple values for a field that can't take
to message.
13.2.6.1. CEF Extensions for Insights
Table 122. CEF Extensions for Insights
src The IPv4 address of the primary asset involved in src=123.45.56.78

the insight.
c6a2=SourceIPv6 Ad- The IP address of the primary (source) asset in- c6a2=SourceIPv6
dress volved in the insight (if IPv6)
Address c6a2=[addr]
smac The MAC address of the primary asset involved in

the event
shost Source host name. May be FQDN or hostname shost=wk1.domain.com
dhost Destination host name. May be FQDN or hostname dhost=work3
dst The IPv4 address of the secondary asset involved in dst=123.45.56.78

the event.

c6a3=Destination The IP address of the destination asset involved in c6a3=Destination IPv6 Address
IPv6 Address the insight (if IPv6) c6a3=[addr]
dmac The MAC address of the secondary asset involved -

in the insight
start Timestamp of insight creation start = alert timestamp
Format is: MMM dd yyyy HH:mm:ss
Timezone should be UTC
cs1Label=CVE CVE Reference cs#Label=CVE
cs#=CVE-2017-3803
cfp1label=CVEScore CVE Score cfp1label=CVEScore
cfp1=4.7
msg Full description of the insight msg = Cisco IOS
Software Login
Enhancements Login
Block Denial of Service Vulnerabilities
destinationservice- Service name being highlighted as risk (if known) destinationservicename=http

name
cs1label=SourceAs- The asset type of the primary asset, e.g. Engineer- cs1label=SourceAssetType
setType ing Station
cs1 = [Asset Type]
cs2label=DestAsset- The asset type of the secondary asset, e.g. Engi- cs2label=DestAssetType
Type neering Station
cs2=[Asset Type]
deviceExternalId Site name generating the message DeviceExternalId= SiteABC
cs3=Manufacturing
cs4=Manufacturing
filepath filepath or file share filepath = \\hostname\Users
13.2.6.2. Insight Example: Assets Accessed SMB Shares

<14>Jun 17 2021 18:24:17 25dc3d3f1858 CEF:0|Claroty|CTD|4.3.0|In-
sight|Assets Accessed SMB shares|2|src=192.168.0.102 dst=192.168.0.100
smac=00:0b:ab:1a:de:03 shost=OWS1 dmac=00:0b:ab:1a:de:be dhost=OISERVM ex-
ternalId=1256 start=Jun 17 2021 18:23:57 deviceExternalId=Default cs1La-
bel=SourceAssetType cs1=Endpoint cs2Label=DestAssetType cs2=Endpoint cs3La-
bel=SourceZone cs3=Endpoint: Other cs4Label=DestZone cs4=Endpoint: Other
filePath=\\\\OISERVM\\SHAREDWORKSPACE
13.2.6.3. Insight Example: Vendor Match CVEs - CVE-2016-20009

<14>Jun 17 2021 18:24:17 25dc3d3f1858 CEF:0|Claroty|CTD|4.3.0|Insight|Ven-
dor Match CVEs|2|smac=00:1d:9c:bd:a9:4f externalId=1251 start=Jun 17 2021
18:23:56 deviceExternalId=Default cs1Label=SourceAssetType cs1=Endpoint
cs3Label=SourceZone cs3=Endpoint: Other cs6Label=CVE cs6=CVE-2016-20009

cfp1Label=CVEScore cfp1=9.8 msg=DNS "Name:Wreck" Vulnerabilities Affect Mul-

tiple Rockwell Automation and ABB Products
13.2.6.4. Insight Example: Vendor Match CVEs - CVE-2021-1356

<14>Jun 17 2021 18:24:17 25dc3d3f1858 CEF:0|Claroty|CTD|4.3.0|Insight|Ven-
dor Match CVEs|2|smac=00:1d:9c:bd:a9:4f externalId=1250 start=Jun 17
2021 18:23:56 deviceExternalId=Default cs1Label=SourceAssetType cs1=End-
point cs3Label=SourceZone cs3=Endpoint: Other cs6Label=CVE cs6=CVE-2021-1356
cfp1Label=CVEScore cfp1=4.3 msg=IOS XE Software Web UI Denial-of-Service
Vulnerability

CTD Reference Guide CEF (Legacy) Format
13.3. CEF (Legacy) Format
IMPORTANT
The CEF(Legacy) formatted messages do not comply with the CEF specification and
will not be fully parsed by SIEMs. Customers can leverage them on a "as is" basis
and should expect these formats to be removed from the product at a later date.
NOTE
In Syslog CEF legacy, the maximum number of assets supported per alert is 10.
13.3.1. SYSLOG ALERT EXAMPLES

13.3.1.1. Known Threat Alert (CEF Legacy Format)

CEF:0|Claroty|CTD|4.2.3|Alert|Known Threat Alert|5| cn1Label=SiteId cn1=1
cs1Label=Site cs1=Default cs2Label=Network cs2=Default cs3Label=Resolve-
dAs cs3=Unresolved cs5Label=Src Zone cs5=Default Zone cs6Label=Dst
Zone cs6=Default Zone cs7Label=Category cs7=Security cs8Label=AlertUrl
cs8=http://<IP.Address>/alert/1-1 outcome=Unresolved request=http://<IP.Ad-
dress>/alert/1-1 cn2Label=Alert Score cn2=100 cs10Label=PrimaryAssetIP
cs10=10.5.22.101 cs11Label=PrimaryAssetType cs11=Endpoint cs12Label=Pri-
maryAssetHostname cs12=N/A cs13Label=PrimaryAssetMAC cs13=00:08:02:1c:47:ae
cs14Label=PrimaryAssetOS cs14=Windows 7/Server 2008 R2 cs15Label=PrimaryAs-
setVendor cs15=Hewlett Packard cs16Label=NonPrimaryAssetIP cs16=185.52.2.154
cs17Label=NonPrimaryAssetType cs17=Endpoint cs18Label=NonPrimaryAssetHost-
name cs18=N/A cs19Label=NonPrimaryAssetMAC cs19=20:e5:2a:b6:93:f1 cs20La-
bel=NonPrimaryAssetOS cs20=N/A cs21Label=NonPrimaryAssetVendor cs21=Netgear
cn3Label=StoryId cn3=1 src=10.5.22.101 smac=00:08:02:1c:47:ae shost=N/A
dst=185.52.2.154 dmac=20:e5:2a:b6:93:f1 dhost=N/A externalId=1 cat=Create
rt=Nov 17 10:18:55 start=Oct 12 2020 17:28:33 msg=Out of working hours Known
Threat: Threat Claroty Rule: GranCrab Ransomware - C2 Certificate was detec-
ted from 10.5.22.101 to 185.52.2.154
Table 123. Known Threat Alert Example

Version
Signature The category of the underlying object that the sy- Alert
slog refers to: Alert/Event/Baseline/Status Check/
HealthCheck
Name The type of event. Known Threat Alert
An alert is considered
critical if its calcula-
• 2 = Low severity ted score is in the
highest 20% of the
section above the
threshold
SiteID The ID of the site 1
Parameters: The format of the list of parameters is:
csNLabel=<parameter name> csN=<value>
where:
N is incremental according to the number of parameters


Site The Site from which the message is being sent. Default
• When an alert/event involves more than one as-

set this parameter will hold the site name of the
primary asset involved in the alert/event.
Network The network of the primary asset involved in the Default
alert
ResolvedAs How the event was treated; whether or not the Unresolved
event was resolved:
• Resolved or Unresolved
Src Zone The source zone Default Zone
Dst Zone The destination zone Default Zone
Category The type of event: Integrity or Security Security
AlertURL The URL for this alert http://<IP.Ad-
dress>/alert/1-1 out-
come=Unresolved re-
quest=http://<IP.Ad-
dress>/alert/1-1
Alert Score The score for this alert 100
NOTE
The Primary IP, hostname and MAC parameters support multiple values, with the full list of asset address-
es output as:
ip1, ip2, ip3 …
PrimaryAssetIP The IP address of the primary asset 10.5.22.101

PrimaryAsset- The asset type of the primary asset Endpoint
Type
PrimaryAsse- The host name of the primary asset N/A

tHostname
PrimaryAssetMAC The MAC address of the primary asset cs13=00:08:02:1c:47:a

e
PrimaryAssetOS The OS of the primary asset Windows 7/Server
2008 R2
PrimaryAsset- The vendor of the primary asset Hewlett Packard
Vendor
NOTE
The Non-Primary IP, hostname and MAC parameters support multiple values, with the full list of asset
addresses output as:
asset1_ip1, asset1_ip2, asset1_ip3, …; asset2_ip1, asset2_ip2, asset2_ip3, …;
NonPrimaryAsse- The IP address/es of the non-primary asset 185.52.2.154

tIP
NonPrimaryAs- The asset type/s of the non-primary asset Endpoint

setType
NonPrimaryAsse- The host name/s of the non-primary asset N/A

tHostname
NonPrimaryAs- The MAC address of the non-primary asset 20:e5:2a:b6:93:f1

setMAC


NonPrimaryAsse- The OS/es of the non-primary asset N/A
tOS
NonPrimaryAs- The vendor/s of the non-primary asset Netgear

setVendor
storyID The ID of the story for this event 1

src The IP address of the primary asset involved in the 10.5.22.101
event
smac The MAC address of the primary asset involved in 00:08:02:1c:47:ae
the event
shost The host name of the primary asset involved in the N/A
event
dst The IP address of the secondary asset involved in 185.52.2.154
the event
dmac The MAC address of the secondary asset involved 20:e5:2a:b6:93:f1
in the event
dhost The host address of the secondary asset involved N/A
in the event
externalId The ID of the alert which this event is part of. 1
cat The type of notification, depending on whether Update
this event is a new event in the system (Create)
or an existing event being updated (Update)
rt The timestamp of the current time (not of the Nov 17 10:18:55
alert)
start The alert creation timestamp Oct 12 2020 17:28:33
msg The message containing the description of the Out of working
event hours Known Threat:
Threat Claroty Rule:
GranCrab Ransom-
ware - C2 Certifi-
cate was detected
from 10.5.22.101 to
185.52.2.154

13.3.1.2. Login Alert (CEF Legacy Format)

CEF:0|Claroty|CTD|4.2.3|Alert|Login|5| cn1Label=SiteId cn1=1 cs1Label=Site
cs1=site-1 cs2Label=Network cs2=Default cs3Label=ResolvedAs cs3=Unre-
solved cs5Label=Src Zone cs5=Endpoint: Other cs6Label=Dst Zone cs6=End-
point: Other cs7Label=Category cs7=Security cs8Label=AlertUrl cs8=https://
10.91.2.188/alert/14-1 outcome=Unresolved request=https://10.91.2.188/alert/
14-1 cn2Label=Alert Score cn2=100 cs10Label=PrimaryAssetIP cs10=10.1.31.12
cs11Label=PrimaryAssetType cs11=Endpoint cs12Label=PrimaryAssetHostname
cs12=N/A cs13Label=PrimaryAssetMAC cs13=00:50:56:8d:df:b8 cs14Label=Pri-
maryAssetOS cs14=N/A cs15Label=PrimaryAssetVendor cs15=VMware cs16Label=Non-
PrimaryAssetIP cs16=10.1.31.1 cs17Label=NonPrimaryAssetType cs17=Endpoint
cs18Label=NonPrimaryAssetHostname cs18=N/A cs19Label=NonPrimaryAssetMAC
cs19=28:63:36:26:f0:74 cs20Label=NonPrimaryAssetOS cs20=N/A cs21Label=Non-
PrimaryAssetVendor cs21=Siemens cn3Label=StoryId cn3=1 duser=N/A destina-
tionServiceName=S7COMM src=10.1.31.12 smac=00:50:56:8d:df:b8 shost=N/A
dst=10.1.31.1 dmac=28:63:36:26:f0:74 dhost=N/A externalId=14 cat=Security
rt=Nov 17 10:18:55 start=Oct 12 2020 17:28:33 msg=Failed Login: Failed Login
attempts were made to asset 10.1.31.1 from 10.1.31.12
Table 124. Login Alert Example

Pro- The name of the syslog message format in use CEF:0
tocol
Ven- The name of the vendor of the product Claroty

dor
Prod- The name of the product in use CTD

uct
Prod- The version number of the product in use 4.2.3

uct
Ver-
sion
Sig- The category of the underlying object that the syslog Alert
na- refers to: Alert/Event/Baseline/Status Check/Health-
ture Check
Name The type of event. Login
Severity The degree of impact of the alert, represented as an 5
integer ranging from 2 to 5 where the Severity scale
An alert is considered critical if
is as follows:
its calculated score is in the high-
• 2 = Low severity est 20% of the section above the
threshold


Parame- The format of the list of parameters is:
ters:
where:
Site The Site from which the message is being sent. site-1
• When an alert/event involves more than one asset

this parameter will hold the site name of the pri-
mary asset involved in the alert/event.
alert
ResolvedAs How the event was treated; whether or not the event Unresolved
was resolved:
Src Zone The source zone Endpoint: Other
Dst Zone The destination zone Endpoint: Other
AlertURL The URL for this alert https://10.91.2.188/alert/14-1
outcome=Unresolved re-
quest=https://10.91.2.188/alert/
14-1
Alert The score for this alert 100
Score
NOTE
es output as: ip1, ip2, ip3 …
PrimaryAs- The IP address of the primary asset 10.1.31.12

setIP
PrimaryAs- The asset type of the primary asset Endpoint

setType
PrimaryAs- The host name of the primary asset N/A

setHost-
name
PrimaryAs- The MAC address of the primary asset 28:63:36:26:f0:74

setMAC
PrimaryAs- The OS of the primary asset N/A

setOS
PrimaryAs- The vendor of the primary asset Siemens

setVendor
NOTE
addresses output as: asset1_ip1, asset1_ip2, asset1_ip3, …; asset2_ip1, asset2_ip2, as-
set2_ip3, …;
NonPrimar- The IP address/es of the non-primary asset 10.1.31.1

yAssetIP


NonPrimar- The asset type/s of the non-primary asset Endpoint
yAssetType
NonPrimar- The host name/s of the non-primary asset N/A

yAsse-
tHostname
NonPrimar- The MAC address of the non-primary asset 28:63:36:26:f0:74

yAssetMAC
NonPrimar- The OS/es of the non-primary asset N/A

yAssetOS
NonPrimar- The vendor/s of the non-primary asset Siemens

yAssetVen-
dor
story The ID of the story for this event 1

ID
duser The username of this attempted login N/A

des- The name of the destination service S7COMM
tina-
tion-
Serv-
ice-
Names
rc

event
smac The MAC address of the primary asset involved in the 00:50:56:8d:df:b8
event
event
dst The IP address of the secondary asset involved in the 10.1.31.1
event
dmac The MAC address of the secondary asset involved in 28:63:36:26:f0:74
the event
dhost The host address of the secondary asset involved in N/A
the event
ex- The ID of the alert which this event is part of. 14
ter-
nalId
cat The type of notification, depending on whether this Security

event is a new event in the system (Create) or an
existing event being updated (Update)
rt The timestamp of the current time (not of the alert) Nov 17 10:18:55
msg The message containing the description of the event Failed Login: Failed Login at-
tempts were made to asset
10.1.31.1 from 10.1.31.12

13.3.1.3. Configuration Download Alert (CEF Legacy Format)

CEF:0|Claroty|CTD|4.2.3|Alert|Configuration Download|5|rt=Nov 01 2020
11:04:44 cn1Label=SiteId cn1=1 cs1Label=Site cs1=site-1 cs2Label=Net-
work cs2=Default cs3Label=ResolvedAs cs3=Unresolved cs5Label=Src Zone
cs5=Engineering Station: Rockwell cs6Label=Dst Zone cs6=PLC: Rockwell
cs7Label=Category cs7=Integrity cs8Label=AlertUrl cs8=https://10.91.2.188/
alert/40-1 outcome=Unresolved request=https://10.91.2.188/alert/40-1 cn2La-
bel=Alert Score cn2=100 cs10Label=PrimaryAssetIP cs10=10.1.30.40 cs11La-
bel=PrimaryAssetType cs11=Engineering Station cs12Label=PrimaryAssetHost-
name cs12=N/A cs13Label=PrimaryAssetMAC cs13=00:50:56:b9:e2:ad cs14La-
bel=PrimaryAssetOS cs14=N/A cs15Label=PrimaryAssetVendor cs15=VMware cs16La-
bel=NonPrimaryAssetIP cs16=10.1.0.40,10.1.30.1 cs17Label=NonPrimaryAsset-
Type cs17=PLC cs18Label=NonPrimaryAssetHostname cs18=N/A cs19Label=NonPri-
maryAssetMAC cs19=00:1d:9c:c0:04:9d cs20Label=NonPrimaryAssetOS cs20=N/A
cs21Label=NonPrimaryAssetVendor cs21=Rockwell Automation cn3Label=Story-
Id cn3=2 src=10.1.30.40 smac=00:50:56:b9:e2:ad shost=N/A dst=10.1.0.40
dmac=00:1d:9c:c0:04:9d dhost=N/A externalId=40 cat=Integrity rt=Nov 17
10:18:55 start=Oct 12 2020 17:28:33 msg=Configuration Download: Configura-
tion Download critical change operation was performed for the first time by
10.1.30.40 on 10.1.30.1
Table 125. Configuration Download Example

Version
HealthCheck
Name The type of event. Configuration Down-
load
highest 20% of the
section above the
threshold
Timestamp The timestamp of the alert rt=Nov 01 2020
11:04:44


where:
Site The Site from which the message is being sent. site-1

alert
event was resolved:
Src Zone The source zone Engineering Station:
Rockwell
Dst Zone The destination zone Rockwell
Category The type of event: Integrity or Security Integrity
AlertURL The URL for this alert https://10.91.2.188/
alert/40-1 out-
come=Unresolved
request=https://
10.91.2.188/alert/
40-1
NOTE
es output as:
ip1, ip2, ip3 …

PrimaryAsset- The asset type of the primary asset Engineering Station
Type

tHostname
PrimaryAssetMAC The MAC address of the primary asset cs13=00:50:56:b9:e2:

ad
PrimaryAssetOS The OS of the primary asset N/A
PrimaryAsset- The vendor of the primary asset VMware
Vendor
NOTE
NonPrimaryAsse- The IP address/es of the non-primary asset 10.1.0.40,10.1.30.1

tIP


NonPrimaryAs- The asset type/s of the non-primary asset PLC
setType

tHostname
NonPrimaryAs- The MAC address of the non-primary asset 00:1d:9c:c0:04:9d

setMAC

tOS
NonPrimaryAs- The vendor/s of the non-primary asset Rockwell Automation

setVendor

event
smac The MAC address of the primary asset involved in 00:50:56:b9:e2:ad
the event
event
the event
dmac The MAC address of the secondary asset involved 00:1d:9c:c0:04:9d
in the event
in the event
cat The type of event: Integrity or Security Integrity
alert)
msg The message containing the description of the Configuration Down-
event load: Configuration
Download critical
change operation
was performed for
the first time
by 10.1.30.40 on
10.1.30.1

13.3.1.4. Host Scan (CEF Legacy Format)

CEF:0|Claroty|CTD|4.2.3|Alert|Host Scan|5|cn1Label=SiteId cn1=7 cs1La-
bel=Site cs1=ZZZ cs2Label=Network cs2=Default cs3Label=ResolvedAs cs3=Unre-
solved cs5Label=Src Zone cs5=10.77.109.0/24 - Endpoint: Other cs6Label=Dst
Zone cs6=10.77.119.0/24 - Endpoint: Other cs7Label=Category cs7=Security
cs8Label=AlertUrl cs8=https://Claroty/alert/286659-71 outcome=Unresolved re-
quest=https://claroty/alert/286659-71 cn2Label=Alert Score cn2=100 cs10La-
bel=PrimaryAssetIP cs10=10.77.109.112,10.77.109.9 cs11Label=PrimaryAssetType
cs11=Endpoint cs12Label=PrimaryAssetHostname cs12=Host-abc cs13Label=Pri-
maryAssetMAC cs13=84:a9:3e:8c:57:d7,84:a9:3e:8c:6d:86,c8:d3:ff:bc:46:0c
cs14Label=PrimaryAssetOS cs14=Windows 10/Server 2016 cs15Label=PrimaryAsset-
Vendor cs15=Hewlett Packard cs16Label=NonPrimaryAssetIP cs16=Multiple As-
sets cs17Label=NonPrimaryAssetType cs17=Multiple Assets cs18Label=NonPrimar-
yAssetHostname cs18=Multiple Assets cs19Label=NonPrimaryAssetMAC cs19=Mul-
tiple Assets cs20Label=NonPrimaryAssetOS cs20=Multiple Assets cs21La-
bel=NonPrimaryAssetVendor cs21=Multiple Assets cn3Label=StoryId cn3=58
{}src=10.77.109.112 smac=84:a9:3e:8c:57:d7 shost= ABC-DEF dst=Multiple As-
sets dmac=c4:34:6b:62:60:b7 dhost= GHI-JKL externalId=999999 cat=Create
rt=Nov 17 10:18:55 start=Oct 12 2020 17:28:33 msg=TCP Host scan: Asset
10.77.109.9 sent packets to different IP destinations on the same port: 7680
Table 126. Host Scan Example

Version
slog refers to:
Name The type of event. Host Scan
highest 20% of the
section above the
threshold
where:


Site The Site from which the message is being sent. ZZZ

alert
event was resolved:
Src Zone The source zone 10.77.109.0/24 -End-
point: Other
Dst Zone The destination zone 10.77.119.0/24 -End-
point: Other
AlertURL The URL for this alert https://claroty/alert/
286659-71 out-
come=Unresolved re-
quest=https://claroty/
alert/286659-71
NOTE
es output as:
ip1, ip2, ip3 …
PrimaryAssetIP The IP address of the primary asset 10.77.109.112,10.77.1

09.9
Type
PrimaryAsse- The host name of the primary asset Host-abc

tHostname
PrimaryAssetMAC The MAC address of the primary asset 84:a9:3e:8c:57:d7,
84:a9:3e:8c:6d:86,
c8:d3:ff:bc:46:0c
PrimaryAssetOS The OS of the primary asset Windows 10/Server
2016
PrimaryAsset- The vendor of the primary asset Hewlett Packard
Vendor
NOTE
NonPrimaryAsse- The IP address/es of the non-primary asset Multiple Assets

tIP
NonPrimaryAs- The asset type/s of the non-primary asset Multiple Assets

setType


NonPrimaryAsse- The host name/s of the non-primary asset Multiple Assets
tHostname
NonPrimaryAs- The MAC address of the non-primary asset Multiple Assets

setMAC
NonPrimaryAsse- The OS/es of the non-primary asset Multiple Assets

tOS
NonPrimaryAs- The vendor/s of the non-primary asset Multiple Assets

setVendor
storyID The ID of the story for this event 58 {}

event
smac The MAC address of the primary asset involved in 84:a9:3e:8c:57:d7
the event
shost The host name of the primary asset involved in the ABC-DEF
event
dst The IP address of the secondary asset involved in Multiple Assets
the event
NOTE
In scan alert types, the dst as-
set data is “multiple assets” to
avoid spam and to comply with
the CEF format
dmac The MAC address of the secondary asset involved c4:34:6b:62:60:b7

in the event
dhost The host address of the secondary asset involved GHI-JKL
in the event
cat The type of notification, depending on whether Create
alert)
msg The message containing the description of the TCP Host scan: As-
event set 10.77.109.9 sent
packets to different
IP destinations on the
same port: 7680

13.3.1.5. Suspicious File Transfer Alert (CEF Format)

CEF:0|Claroty|CTD|4.2.3|Alert|Suspicious File Transfer|5|rt=Nov 01
2020 11:04:44 cn1Label=SiteId cn1=1 cs1Label=Site cs1=De-
fault cs2Label=Network cs2=Default cs3Label=ResolvedAs cs3=Unre-
solved cs5Label=Src Zone cs5=Endpoint: Other cs6Label=Dst
Zone cs6=Endpoint: Other cs7Label=Category cs7=Security cs8La-
bel=AlertUrl cs8=http://<IP.Address>/alert/60-1 outcome=Unresolved re-
quest=http://<IP.Address>/alert/60-1 cn2Label=Alert Score cn2=100 cs10La-
bel=PrimaryAssetIP cs10=10.20.6.205 cs11Label=PrimaryAssetType cs11=End-
point cs12Label=PrimaryAssetHostname cs12=N/A cs13Label=PrimaryAssetMAC
cs13=f0:18:98:66:5a:0c cs14Label=PrimaryAssetOS cs14=N/A cs15Label=Pri-
maryAssetVendor cs15=Apple cs16Label=NonPrimaryAssetIP cs16=10.10.10.10
cs17Label=NonPrimaryAssetType cs17=Endpoint cs18Label=NonPrimaryAssetHost-
name cs18=N/A cs19Label=NonPrimaryAssetMAC cs19=N/A cs20Label=NonPrimar-
yAssetOS cs20=N/A cs21Label=NonPrimaryAssetVendor cs21=N/A cn3Label=Story-
Id cn3=4 filePath=/private/var/lib/icsranger/master/workers/known_threats/
yara_exported_files/matched_yara_files/1/smb/1597600276270606_0.bin
src=10.20.6.205 smac=f0:18:98:66:5a:0c shost=N/A dst=10.10.10.10 dmac=N/A
dhost=N/A externalId=60 cat=Create rt=Nov 17 10:18:55 start=Oct 12
2020 17:28:33 msg=Suspicious file transfer found! File '/Teams/QA/all/
imain.bin' was transferred via 'smb' and matched the following Yara
rules: ['ics_cert_hatman.yara/hatman_payload', 'ics_cert_hatman.yara/hat-
man'], Transferred from 10.20.6.205
Table 127. Suspicious File Transfer Alert Example

Version
slog refers to:
Name The type of event. Suspicious File Trans-
fer
highest 20% of the
section above the
threshold


where:

alert
event was resolved:
AlertURL The URL for this alert http://<IP.Ad-
dress>/alert/60-1 out-
come=Unresolved re-
quest=http://<IP.Ad-
dress>/alert/60-1
NOTE
es output as:
ip1, ip2, ip3 …

Type

tHostname
PrimaryAssetMAC The MAC address of the primary asset f0:18:98:66:5a:0c

PrimaryAsset- The vendor of the primary asset Apple
Vendor
NOTE

tIP

setType


tHostname
NonPrimaryAs- The MAC address of the non-primary asset N/A

setMAC

tOS
NonPrimaryAs- The vendor/s of the non-primary asset N/A

setVendor

filepath The IP address of the primary asset involved in the /private/var/lib/ics-
event ranger/master/work-
ers
known_threats/
yara_exported_files/
match-
ed_yara_files/1/smb/
1597600276270606_0
.bin
event
smac The MAC address of the primary asset involved in f0:18:98:66:5a:0c
the event
event
the event
dmac The MAC address of the secondary asset involved N/A
in the event
in the event
alert)
msg The message containing the description of the Suspicious file
event transfer found!
File '/Teams/QA/all/
imain.bin' was trans-
ferred via 'smb'
and matched the
following Yara
rules: ['ics_cert_hat-
man.yara/hat-
man_payload',
'ics_cert_hat-
man.yara/hatman'],
Transferred from
10.20.6.205

13.3.1.6. New Asset Alert (CEF Legacy Format)

CEF:0|Test_Brand|CTD|4.2.3|Alert|New Asset|5| cn1Label=SiteId cn1=1 cs1La-
bel=Site cs1=Default cs2Label=Network cs2=Default cs3Label=ResolvedAs
cs3=Unresolved cs4Label=SiteId cs4=1 cs5Label=SrcZone cs5=Endpoint: Oth-
er cs6Label=DstZone cs6=Endpoint: Other cs7Label=Category cs7=Integri-
ty cs8Label=AlertUrl cs8=https://10.91.1.20/alert/105-1 cs9Label=Score
cs9=80 cs10Label=PrimaryAssetIP cs10=10.10.6.121 cs11Label=PrimaryAsset-
Type cs11=Endpoint cs12Label=PrimaryAssetHostname cs12=N/A cs13Label=Pri-
maryAssetMAC cs13=N/A cs14Label=PrimaryAssetOS cs14=N/A cs15Label=PrimaryAs-
setVendor cs15=N/A cs16Label=NonPrimaryAssetIP cs16=10.20.10.166 cs17La-
bel=NonPrimaryAssetType cs17=Endpoint cs18Label=NonPrimaryAssetHostname
cs18=N/A cs19Label=NonPrimaryAssetMAC cs19=ac:bc:32:d1:40:b7 cs20Label=Non-
PrimaryAssetOS cs20=N/A cs21Label=NonPrimaryAssetVendor cs21=N/A cs22La-
bel=StoryId cs22=2 src=10.10.6.121 smac=N/A shost=N/A dst=10.20.10.166
dmac=ac:bc:32:d1:40:b7 dhost=N/A externalId=105 cat=Create rt=Nov 17
10:18:55 start=Oct 12 2020 17:28:33 msg=A new asset has been detected:
10.10.6.121.
Table 128. New Asset Alert Example

Vendor The name of the vendor of the product Test_Brand
Version
HealthCheck
Name The type of alert. There are several types of alerts New Asset
(e.g. ‘baseline deviation’, ‘new asset’, ‘configuration
downloaded to PLC’, ‘known attack signature de-
tected’, etc. See Common Alerts.
highest 20% of the
section above the
threshold
where:



alert
event was resolved:
AlertURL The URL for this alert https://10.91.1.20/
alert.105-1
NOTE
es output as:
ip1, ip2, ip3 …

Type

tHostname
PrimaryAssetMAC The MAC address of the primary asset N/A

PrimaryAsset- The vendor of the primary asset N/A
Vendor
NOTE
addresses output as: asset1_ip1, asset1_ip2, asset1_ip3, …; asset2_ip1, asset2_ip2, as-
set2_ip3, …;

tIP

setType

tHostname
NonPrimaryAs- The MAC address of the non-primary asset ac:bc:32:d1:40:b7

setMAC

tOS
NonPrimaryAs- The vendor/s of the non-primary asset N/A

setVendor


storyID The ID of the story for this event (i.e. the chain of 2
events that provide the context for this alert)
event
smac The MAC address of the primary asset involved in N/A
the event
event
the event
dmac The MAC address of the secondary asset involved ac:bc:32:d1:40:b7
in the event
in the event
externalId The ID of the corresponding alert 105
NOTICE
An event with externalId 7
is associated with an alert with
externalId 7

alert)
msg The message containing the description of the A new asset has been
alert detected: 10.10.6.121
13.3.2. SYSLOG EVENT EXAMPLES

13.3.2.1. Protocol Specific OT Alert (CEF Legacy Format)

CEF:0|Claroty|CTD|4.2.3|Event|Protocol|5|rt=Nov 01 2020 11:04:44 cn1La-
bel=SiteId cn1=1 cs1Label=Site cs1=site-2 cs2Label=Network cs2=Default
cs3Label=Resolved As cs3=Unresolved cs4Label=SiteId cs4=2 cs5Label=SrcZone
cs5=Engineering Station: Rockwell cs6Label=DstZone cs6=PLC: Rockwell cs7La-
bel=Category cs7=Integrity cs8Label=AlertUrl cs8=https://10.91.1.186:5000/
alert/25-2 cs9Label=Score cs9=100 cs10Label=PrimaryAssetIP cs10=10.1.30.40
cs11Label=PrimaryAssetType cs11=Engineering Station cs12Label=Prim aryAsse-
tHostname cs12=N/A cs13Label=PrimaryAssetMAC cs13=00:50:56:b9:e2:ad cs14La-
bel=NonPrimaryAss etIP cs16=10.1.0.40,10.1.30.1 cs17Label=NonPrimaryAsset-
maryAssetMAC cs19=00:1d:9c:c0:04:9d cs20Label =NonPrimaryAssetOS cs20=N/A
cs21Label=NonPrimaryAssetVendor cs21=Rockwell Automation cs22Label=StoryId
cs22=3 src=10.1.30.40 smac=00:50:56:b9:e2:ad shost=N/A dst=10.1.0.40 d
mac=00:1d:9c:c0:04:9d dhost=N/A externalId=25 cat=Update rt=Nov 17 10:18:55
start=Oct 12 2020 17:28:33 msg=Editing was done on DataTable object (Opera-
tion: Create Instance).format(ctd_version, site_name, alertURL)
Table 129. Protocol Specific OT Alert Example

Version
Signature The category of the underlying object that the sy- Event
slog refers to:
Name The type of event. Protocol
highest 20% of the
section above the
threshold
Timestamp The timestamp of the alert rt=Nov 01 2020
11:04:44
where:


Site The site from which the message is being sent. site-2
When an alert/event involves more than one asset

mary asset.
alert
event was resolved:
Src Zone The source zone Engineering Station:
Rockwell
Dst Zone The destination zone PLC: Rockwell
AlertURL The URL for this alert https://
10.91.1.186:5000/
alert/25-2
NOTE
es output as:
ip1, ip2, ip3 …

PrimaryAsset- The asset type of the primary asset Engineering Station
Type

tHostname
PrimaryAssetMAC The MAC address of the primary asset 00:50:56:b9:e2:ad

PrimaryAsset- The vendor of the primary asset VMware
Vendor
NOTE
NonPrimaryAsse- The IP address/es of the non-primary asset 10.1.0.40,10.1.30.1

tIP
NonPrimaryAs- The asset type/s of the non-primary asset PLC

setType

tHostname
NonPrimaryAs- The MAC address of the non-primary asset 00:1d:9c:c0:04:9d

setMAC

tOS


NonPrimaryAs- The vendor/s of the non-primary asset Rockwell Automation
setVendor

event
smac The MAC address of the primary asset involved in 00:50:56:b9:e2:ad
the event
event
the event
dmac The MAC address of the secondary asset involved 00:1d:9c:c0:04:9d
in the event
in the event
cat The type of notification, depending on whether Update
baseline)
msg The message containing the description of the Editing was done
event on DataTable ob-
ject (Operation:
Create Instance).for-
mat(ctd_version,
site_name, alertURL)

13.3.3. SYSLOG NEW BASELINE EXAMPLE

CEF:0|Claroty|CTD|4.2.3|Event|Baseline Deviation|5|rt=Nov 01 2020 11:04:44
cn1Label=SiteId cn1=1 cs1Label=Site cs1=site-2 cs2Label=Network cs2=Default
cs3Label=ResolvedAs cs3=Unresolved cs4Label=SiteId cs4=2 cs5Label=SrcZone
cs5=Engineering Station: Rockwell cs6Label=DstZone cs6=PLC: Rockwell cs7La-
bel=Category cs7=Integrity cs8Label=AlertUrl cs8=https://10.91.1.186:5000/
alert/25-2 cs9Label=Score cs9=100 cs10Label=PrimaryAssetIP cs10=10.1.30.40
cs11Label=PrimaryAssetType cs11=Engineering Station cs12Label=PrimaryAsse-
tHostname cs12=N/A cs13Label=PrimaryAssetMAC cs13=00:50:56:b9:e2:ad cs14La-
bel=NonPrimaryAssetIP cs16=10.1.0.40,10.1.30.1 cs17Label=NonPrimaryAsset-
maryAssetMAC cs19=00:1d:9c:c0:04:9d cs20Label=NonPrimaryAssetOS cs20=N/A
cs21Label=NonPrimaryAssetVendor cs21=Rockwell Automation cs22Label=Story-
Id cs22=3 src=10.1.30.40 smac=00:50:56:b9:e2:ad shost=N/A dst=10.1.0.40
dmac=00:1d:9c:c0:04:9d dhost=N/A externalId=25 cat=Update rt=Nov 17 10:18:55
start=Oct 12 2020 17:28:33 msg=CIP : Service Get Attribute All called on
ExtendedDevice
Table 130. New Baseline Example

Version
Signature The category of the underlying object that the sy- Baseline
slog refers to:
• Alert/Event/Baseline/Status Check/HealthCheck
Name The type of baseline None
Approved Whether this baseline is approved or not, repre- 1
sented as an integer of 0 or 1 where
• 0 = Baseline Approved
• 1 = Baseline Unapproved
where:


Site The site from which the message is being sent. Default
When an alert/event involves more than one asset

mary asset.
alert
Transmission The type of transmission protoocol in use None
Src Zone The source zone Default Zone
Dst Zone The destination zone Default Zone
Category The type of alert: Network
• Integrity/Security/Network/Other
For a baseline , the category shall be Network

CategoryAccess Access type: None
• None, Read, Write, Execute, Publish

Frequency Frequency of recurrence if timed. NotTimed
Otherwise: NotTimed
FirstSeen Timestamp of when the baseline was first detec- Aug 16 2020 17:50:52
ted
src The IP address of the primary asset involved in the N/A
event
smac The MAC address of the primary asset involved in 00:80:f4:12:8b:10
the event
event
dst The IP address of the secondary asset involved in N/A
the event
dmac The MAC address of the secondary asset involved ff:ff:ff:ff:ff:ff
in the event
in the event
baseline)
msg The message containing the description of the msg=ARP : Gratuitous
event ARP for ipv4 ad-
dress 84.18.139.16
with mac address
00:80:f4:12:8b:10

13.3.4. SYSLOG SNIFFER STATUS CHECK EXAMPLE

This is a type of system event.

CEF:0|Claroty|CTD|4.2.3|SnifferStatus|SnifferStatus|3|rt=Nov 01 2020 11:04:44 cn1La-
bel=SiteId cn1=1 cs1Label=SiteName cs1=site-1 cs2Label=SiteId cs2=1 cs3Label=InterfaceName
cs3=ens224 cs4Label=Network cs4=Default cs5Label=IPaddress cs5=10.10.6.207 cs6Label=Sniffer-
Status cs6=down rt=Jul 15 2020 09:04:53 msg=interface ens224 is currently not receiving any
packets
Table 131. Sniffer Status Alert Example

Protocol The name of the syslog message for- CEF:0
mat in use
Vendor The name of the vendor of the prod- Claroty
uct
Product Ver- The version number of the product in 4.2.3
sion use
Signature The category of the underlying object SnifferStatus
that the syslog refers to:
• Alert/Event/Baseline/Status Check/
HealthCheck
Name The name of the message Sniffer Status
Severity The severity of the status message- 3
For a Sniffer Status alert, the Severity
is always 3.
For a Site Status alert:
• Site Down = 8
• Site up = 0
Timestamp The timestamp of the event rt=Nov 01 2020
11:04:44
where:
SiteName The site from which the message is site-1

being sent.
When an alert/event involves more

than one asset this parameter will
hold the site name of the primary as-
set involved in the alert/event.


Site When an alert/event involves more Default
than one asset this parameter will
hold the site name of the primary as-
set.
Interface Name The name of the interface in use Ens224
Network The network involved Default
IP address The IP address involved 10.10.6.207
Sniffer Status Whether the sniffer is currently ac- Down
tive:
• Up or Down
rt The timestamp of the status check Jul 15 2020 09:04:53
msg The message containing the descrip- interface ens224 is
tion of the sniffer status check currently not receiving
any packets

13.3.5. HEALTH CHECK MONITORING EXAMPLE

Below is an example of a Syslog message for Health Check monitoring. Note that this message
structure is dependent on your environment and on your CTD configuration. For example, Site
output will differ from Central output; as there are no dissectors in the EMC.
NOTE
The labeling in the values in this example changes according to the user’s running
environment.

CEF:0|Claroty|CTD|4.2.3|HealthCheck| cn1Label=SiteId cn1=1 cs1Label=Site
cs1=Default cs2Label=cpu cs2=0.19 cs3Label=mem cs3=54.3 cs4La-
bel=used__opt_icsranger cs4=9.23 cs5Label=used__var cs5=9.23 cs6La-
bel=used__tmp cs6=9.23 cs7Label=used__etc cs7=9.23 cs8Label=busy_sda
cs8=0.84 cs9Label=busy_sda1 cs9=0.0 cs10Label=busy_sda2 cs10=0.84 cs11La-
bel=busy_sr0 cs11=0.0 cs12Label=busy_dm-0 cs12=0.93 cs13Label=busy_sdb
cs13=0.19 cs14Label=busy_sdb1 cs14=0.19 cs15Label=drop_ens192 cs15=0
cs16Label=drop_lo cs16=0 cs17Label=service_mariadb cs17=Up cs18Label=serv-
ice_postgres cs18=Up cs19Label=service_redis cs19=Up cs20Label=service_rab-
bitmq cs20=Up cs21Label=service_icsranger cs21=Up cs22Label=service_watch-
dog cs22=Up cs23Label=q_baseline_tracker cs23=0 cs24Label=q_bridge cs24=0
cs25Label=q_central_bridge cs25=0 cs26Label=q_concluding cs26=0 cs27La-
bel=q_diode_feeder cs27=0 cs28Label=q_dissector-0 cs28=0 cs29Label=q_dissec-
tor-1 cs29=0 cs30Label=q_dissector-2 cs30=0 cs31Label=q_dissector_ng cs31=0
cs32Label=q_enricher cs32=0 cs33Label=q_leecher cs33=0 cs34Label=q_monitor
cs34=0 cs35Label=q_packets cs35=0 cs36Label=q_packets_errors cs36=0 cs37La-
bel=q_preprocessing cs37=0 cs38Label=q_processing cs38=0 cs39Label=q_pro-
cessing_errors cs39=0 cs40Label=q_processing_high cs40=0 cs41Label=q_zor-
don_updates cs41=0 cs42Label=queue_purge cs42=0 cs43Label=rd_bridge cs43=11
cs44Label=rd_dissector-0 cs44=0 cs45Label=rd_dissector-1 cs45=0 cs46La-
bel=rd_dissector-2 cs46=0 cs47Label=rd_dissector_ng cs47=0 cs48Label=rd_pre-
processing cs48=0 cs49Label=unhandled_events cs49=0 cs50Label=conclude_time
cs50=0 cs51Label=exceptions cs51=0 cs52Label=mysql_query cs52=0.02 cs53La-
bel=postgres_query cs53=0.0 cs54Label=dropped_entities cs54=0 cs55La-
bel=workers cs55=26 cs56Label=workers_stop cs56=0 cs57Label=workers_restart
cs57=0 cs58Label=workers_info_mitre cs58={'api': 'Not Available', 'last_re-
start': '5 min, 41 sec'} cs59Label=workers_info_sensor cs59={'api': 'Avai-
lable', 'last_restart': '5 min, 42 sec'} cs60Label=workers_info_web./auth
cs60={'api': 'Available', 'last_restart': '5 min, 34 sec'} msg=Successfully
ran health monitoring

Table 132. Health Check Monitoring Example
Name Description Value in Exam-

ple
Version
Signature The category of the underlying object that HealthCheck

the syslog refers to: Alert/Event/Insight/Health-
Check
where:
Site The site from which the information contained Default

in the message is being sent.
cpu CPU Utilization: CPU load average as a per- 0.19
centage of the total available CPU capacity (in-
cluding all available cores)
mem Memory Usage: The percent of current mem- 54.3
ory consumption.The value is a number be-
tween 0 and 100
Disk Utilization
The percent of disk space currently used in this particular directory

used__opt_icsranger 9.23
used__var 9.23
used__tmp 9.23
used__etc 9.23
Disk Busy Percent
How frequently the particular disk partition is in use (as a percentage between 0 and 1)
busy_sda 0.84
busy_sda1 0.0
busy_sda2 0.84
busy_sr0 0.0
busy_dm-0 0.93
busy_sdb 0.19
busy_sdb1 0.19
Network Interface Packet Drops
The number of packets that are dropped when using this network interface
drop_ens192 0
drop_lo 0
Services Running
Whether the service is running (Up or Down)

service-mariadb Up


ple
service-postgres Up
service-redis Up
service-rabbitmq Up
service-icsranger Up
service-watchdog Up
Queue Message Counts
Each worker has its own read queue

q_baseline_tracker 0
q_bridge 0
q_central_bridge 0
q_concluding 0
q_diode_feeder 0
q_dissector-0 . . n 0...
q_dissector_ng 0
q_enricher 0
q_leecher 0
q_monitor 0
q_packets 0
q_packets_errors 0
q_preprocessing 0
q_processing 0
q_processing_errors 0
q_processing_high 0
q_zordon_updates 0
Queue Purges
Queue purges counted in the last 24 hours

q_purge 0
Queue Read Count
The queue read count for each component

rd_bridge 11
rd_dissector-0 0
rd_dissector-1 0
rd_dissector-2 0
rd_dissector-ng 0
rd_preprocessing 0
Event Handling
The number of events that have not been handled by the system
unhandled_events 0
Conclusion Time
The number of events that have not been handled by the system
conclude_time 0


ple
Logs Exceptions
The number of new logged exceptions

exceptions 0
MySQL Query time, in seconds

mysql_query 0.02
PostgreSQL Query time, in seconds

postgreSQL_query 0
Dropped Entities
The number of entities dropped by the system due to reaching the limit of number of entities
dropped_entities 0
Worker Info
The number of events that have not been handled by the system and status of specific workers
workers The total number of workers (processes) in the 26
system
workers_stop The total number of stopped workers 0
workers_restart The total number of workers restarted 0
workers_info_mitre Availability and last restart info for the Mitre 'Not Available',
worker 'last_restart': '5
min, 41 sec'
workers_info_sensor Availability and last restart info for the Sensor 'Available',
min, 42 sec'
workers_info_web Availability and last restart info for the Web 'Available',
min, 34 sec'
msg The message containing the description of the health check monitoring test Successfully ran
health monitor-
ing
13.3.6. HEALTH CHECK WORKER LIST

Especially useful for those users that work with 3rd party tools that integrate with CTD, the status
of all running components, including all workers, can be sent via Syslog.
This information is configured via the CLI only, and can be enabled by contacting Claroty Support.
Status info is available for the following workers:
• active_executor
• sensor
• authentication
• mailer
• mitre
• notifications (Syslog DB pollers, mail notifications)
• processor
• export_data

• export_data_puller
• cloud_agent
• cloud_client
• scheduler
• known_threats
• cacher
• insights
• active
• enricher
• indicators
• indicators_api
• concluder
• preprocessor
• leecher
• sync_manager
• bridge
• web
• configurator
• capsaver
• baseline_tracker

CTD Reference Guide Supported Reports
14. Supported Reports
The following report types are generated by the system.
Table 133. Report Types
Report Name Report Contents
CTD Inactive assets from the last week Report with unicast assets that didn’t communicate in the last week.
CTD Completed Insights All marked as completed insights, include vulnerabilities.
CTD Resolved alerts from the last week Activities report for alerts that resolved in the last week.
CTD Site connectivity from the last Site connectivity status from the last week (site up or down).
week
CTD New Alerts from the last week Critical and High alerts that created in the last week and their status.
CTD Alerts Ignored/Acknowledged Activities of alerts that marked as ignored or acknowledge from the last week.
from the last week
CTD Top Risky Assets This is a report for the top risky assets.
CTD Insights with High Criticality Insights with high criticality.
CTD Assets that talk with external IP Unicast and remote assets that are talking with external assets. External IPs
coupled with respective network interfaces expose the asset to users outside of
the company's perimeter, enabling attackers to enter the OT network.
CTD Assets discovered in the last week All assets discovered in the last week.
CTD Assets with unsecured protocols All assets that are using unsecured protocols. Assets with unsecured protocols
contain security weaknesses that attackers can leverage to compromise the
network's security.
CTD Assets from the Industrial Security Assets in the industrial security zone (level 3).
Zone
CTD Assets with unpatched CVEs All assets with unpatched vulnerabilities that have Full Match CVEs. Assets that
run software versions that are vulnerable and can be leveraged by attackers for
various malicious purposes such as remote code execution, DDoS, etc.
CTD Assets performed Data Acquisi- All assets that performed data acquisition write. These assets should be consid-
tion Write (Operated PLCs) ered as potential assets that can change the process by changing values.
CTD Assets using remote connections All assets using remote connections.
CTD Assets from the Enterprise Securi- CTD assets from the Enterprise Security Zone and assets from the enterprise
ty Zone network (level 4 and level 5).
CTD Assets Changed IP in the last Activities about assets that changed their IP in the last month.
month
CTD Parsed Assets All assets discovered as parsed assets via App DB.
CTD Insights Report All open Insights (severity: High, Medium, Low)

CTD Reference Guide Supported Asset Types
15. Supported Asset Types
Table 134. List of Asset Types
Asset Types
AAA Server Access Control Access Point
AD Server Autonomous Vehicle AV Server
Barcode Scanner Bluetooth Device Broadcast
Camera Cleaning Device Controller
DB Server Data Logger Domain Controller
Endpoint Engineering Station File Server
Firewall Front End Processor Gateway
GPS Clock GPS Device Historian
HMI Home Assistant IED
Infusion Pump Media Server Medical Device
Microscope Modem Network Access Storage
Networking NTP Server OPC Server
OT PLC Printer
Proxy Server Remote IO Reverse Proxy Server
Robot Router RTU
SCADA Client SCADA Master SCADA Server
Smart Light Smart Phone Smart Watch
SNMP Server/Scanner Biometric Scanner DNS Server
Storage Array Streamer Switch
Syslog Server Terminal Server TV Screen
UPS User Console User Workstation
Vending Machine Video Recorder Virtualization Server
Vision Camera Barcode Reader Vision Controller
Vision Sensor
VOIP Phone VOIP Server Web Server
Wireless LAN Controller Vulnerability Scanner VOIP Access Point
15.1. Purdue Level Classifications of Asset Types

Table 135. Purdue Levels
Asset Type Purdue Level
Autonomous Vehicle 0
Remote IO 0
Robot 0
UPS 0
Access Control 1
Controller 1
GPS Device 1
IED 1

CTD Reference Guide Purdue Level Classifications of As-
set Types
Infusion Pump 1
Medical Device 1
Microscope 1
PLC 1
RTU 1
Smart Light 1
Vision Sensor 1
Access Point 1.5
Firewall 1.5
Gateway 1.5
Networking 1.5
Router 1.5
Switch 1.5
Engineering Station 2
Front End Processor 2
HMI 2
OPC Server 2
OT 2
SCADA Client 2
SCADA Master 2
SCADA Server 2
Vision Camera 2
Barcode Reader 2
Vision Controller 2
Broadcast 2.5
Cleaning Device 3
Data Logger 3
Endpoint 3
Home Assistant 3
Media Server 3
NTP Server 3
Proxy Server 3
Reverse Proxy Server 3
Streamer 3
Syslog Server 3
User Console 3
User Workstation 3
Video Recorder 3
DNS Server 3
AAA Server 4
AD Server 4
AV Server 4
Barcode Scanner 4
Bluetooth Device 4

CTD Reference Guide Asset Classes
Camera 4
DB Server 4
Domain Controller 4
File Server 4
GPS Clock 4
Historian 4
Modem 4
Network Access Storage 4
Printer 4
Smart Phone 4
Smart Watch 4
Storage Array 4
Terminal Server 4
TV Screen 4
Vending Machine 4
Virtualization Server 4
VOIP Phone 4
VOIP Server 4
Web Server 4
Wireless LAN Controller 4
Vulnerability Scanner 4
VOIP Access Point 4
SNMP Server/Scanner 4
Biometric Scanner 4
15.2. Asset Classes

Table 136. Asset Classes
Asset Type Asset Class
AAA Server IT
Access Control IoT
Access Point IT
AD Server IT
Autonomous Vehicle OT
AV Server IT
Barcode Reader OT
Barcode Scanner IoT
Biometric Scanner IoT
Bluetooth Device IoT
Broadcast IT
Camera IoT
Cleaning Device IoT
Controller OT
Data Logger IT

DB Server IT
DNS Server IT
Domain Controller IT
Endpoint IT
Engineering Station OT
File Server IT
Firewall IT
Front End Processor OT
Gateway OT
GPS Clock IoT
GPS Device IT
Historian OT
HMI OT
Home Assistant IoT
IED OT
Infusion Pump IoT
Media Server IT
Medical Device IoT
Microscope IoT
Modem UT
Network Access Storage IT
Networking IT
NTP Server IT
OPC Server OT
OT OT
PLC OT
Printer IT
Proxy Server IT
Remote IO OT
Reverse Proxy Server IT
Robot OT
Router IoT
RTU OT
SCADA Client OT
SCADA Master OT
SCADA Server OT
Smart Light IoT
Smart Phone IoT
Smart Watch IoT
SNMP Server/Scanner IT
Storage Array IT
Streamer IoT
Switch IoT
Syslog Server IT

Terminal Server IT
TV Screen IoT
UPS IoT
User Console IT
User Workstation IT
Vending Machine IoT
Video Recorder IoT
Virtualization Server IT
Vision Camera OT
Vision Controller OT
Vision Sensor OT
VOIP Access Point IoT
VOIP Phone IoT
VOIP Server IoT
Vulnerability Scanner IT
Web Server IT
Wireless LAN Controller IT

CTD Reference Guide Terminology
16. Terminology
Table 137. CTD Terminology
Term Meaning
ACS Assertion Consumer Service
AD Active Directory
Alert An event that may cause a threat or a risk to the security of the network and requires attention and
investigation.
Alert Indica- A predefined characteristic of an alert that affects the alert score.
tor
Alert Score A number representing the overall alert importance, resulting from the collection of observed indicators
and network activities.
App DB Application Database
ARP Address Resolution Protocol. A communication protocol used for discovering the link layer address associ-
ated with a given IPv4 address, a critical function in the Internet protocol suite. Used for mapping a network
address such as an IPv4 address, to a physical address, such as a MAC address.
Asset Any distinguishable network entity.
Attack Vec- A path or means by which a hacker can gain access to a computer or network server to deliver a payload or
tor a malicious outcome. Attack vectors enable hackers to exploit system vulnerabilities.
Baseline The CTD collection of valid network behaviors. An individual baseline represents a command or an instance
of communication between two assets.
Baseline De- During training mode, the system learns the existing asset communication and defines a baseline for how
viation a normal asset (or group of assets) behaves on the network in terms of its communication patterns. A
baseline deviation occurs when a communication occurs that has not been defined yet. During operational
mode, baselines can be changed or further defined by auto-generated virtual zones and user approved
alerts.
BPF Berkeley Packet Filter. A mechanism to write/read packets to/from the network interface.
CSR Certificate Signing Request
CAM Content Addressable Memory table. Used to record a station’s MAC address and its corresponding switch
port location. Common in Layer 2 switching.
Cloud Repu- Indications about the common rates of policy zone rules among different sites. This feature enables com-
tation mon rate of a specific rule among sites around the world.
CDP Cisco Discovery Protocol. A proprietary Data Link Layer protocol developed by Cisco Systems. Used to share
information about other directly connected Cisco equipment, such as the operating system version and IP
address.
CEF Common Event Format. A proprietary syslog-based event format that can be used by other vendors.
Chain of A series of alerts/events that are correlated with each other and generated an alert and require investiga-
Events tion as group.
CIDR Classless Inter-Domain Routing. IP Address syntax that uses IPv4 address space and prefix aggregation,
known as route summarization or super-netting.
CIP Common Industrial Protocol. Industrial protocol for industrial automation applications.
ClarotyOS A hardened, purposely built Linux OS, ready for use for CTD out-of-the-box. Every Claroty Appliance is
delivered pre-installed with ClarotyOS for quick deployment.
CMDB Configuration Management Database. A data repository that acts as a data warehouse or inventory for
information technology (IT) installations. It holds data relating to a collection of IT assets, the relationships
between assets and enables understanding the composition of critical assets such as information systems.
Also help organizations track the configuration of components in the system.
Community Group of CTD devices that are interconnected with the same EMC.

Term Meaning
CQL CTD Query Language. Provided for users to build swift SQL-like query statements for filtering data in the
system.
CSV Comma-separated values. A delimited text file that uses a comma to separate values. A CSV file stores
tabular data (numbers and text) in plain text. Each line of the file is a data record. Each record consists of
one or more fields, separated by commas. The use of the comma as a field separator is the source of the
name for this file format.
CTD Continuous Threat Detection. The anomaly detection product within the Claroty Platform for ICS networks,
providing rapid and concrete situational awareness through real-time alerting. Constantly monitors ICS
network traffic and generates alerts for anomalous network behavior that indicates a malicious presence
and for changes that have the potential for disrupting the industrial processes.
CTI Claroty Threat Intelligence. A highly curated, multi-source and tailored feed that enriches Claroty’s RCA with
proprietary research and analysis of OT zero-day vulnerabilities and ICS-specific Indicators of compromise
(IoC) linked to adversary tactics, techniques and procedures (TTP). CTI’s YARA rules, for example, run on OT
asset configuration changes and code sections, not just IT artifacts. CTI equips threat hunters and incident
responders with the relevant context needed to detect and prevent targeted attacks early in the kill chain
and mitigate the consequences of malware infections.
CVE Common Vulnerabilities and Exposures. A catalog of known security threats. The threats are classified as
vulnerabilities or exposures. The CVEs originate in software or firmware, and are identified, standardized
and cataloged into a free “dictionary” for organizations to improve their security.
CVSS Common Vulnerability Scoring System. A standardized method to indicate how critical a specific CVE is.
DCP Discovery and Basic Configuration Protocol. A protocol definition within the PROFINET context. A link
layer-based protocol to configure station names and IP addresses. It is restricted to one subnet and mainly
used in small and medium applications without an installed DHCP server.
DDoS Distributed Denial-of-Service. An attempt to make an online service unavailable by overwhelming it with
traffic from multiple sources. In this type of attack, multiple compromised computer systems attack a
target, such as a server, website or other network resource, and cause a denial of service for users of the
targeted resource.
DHCP Dynamic Host Configuration Protocol. A network protocol that enables a server to automatically assign an
IP address to a computer from a defined range of numbers configured for a given network.
DN Distinguished Name. The fully qualified name of a domain or network device.
DNP Distributed Network Protocol. A set of communication protocols used between components in process
automation systems.
DNS Domain Name System. A hierarchical decentralized naming system for computers, services, or other re-
sources connected to the Internet or a private network.
DoS Denial-of-Service (attack). Also known as DDoS (Distributed Denial of Service)
DPI Deep Packet Inspection. A form of computer network packet filtering that examines the header and data
part of a packet as it passes an inspection point, searching for protocol non-compliance, viruses, spam,
intrusions, or defined criteria. This method is used for identifying specific assets in the ICS network, lines of
asset communication, communication timing, protocol communication between assets, types of commands
and registers used, and the values of valid responses.
EMC Enterprise Management Console, i.e. the Central Appliance at operation headquarters.
ENIP Ethernet Industrial Protocol (Ethernet/IP)
Event A single network event that CTD has collected using Deep Packet Inspection (DPI). Some of the events will
be classified as alerts, e.g. when they pose a risk or threat to the network. See also Master Event.
Event Indi- See Indicator (page 225)

cator
EWS Engineering WorkStation. A high-end very reliable computing platform designed for configuration, mainte-
nance and diagnostics of control system applications and other control system equipment.
FQDN Fully Qualified Domain Name
FW Firewall

Term Meaning
GDPR General Data Protection Regulation. A European Union regulation that specifies standards for data protec-
tion and electronic privacy in the European Economic Area, and the rights of European citizens to control
the processing and distribution of personally identifiable information. Aims primarily to give control to
individuals over their personal data and to simplify the regulatory environment for international business
by unifying the regulation within the EU.
HDD Hard Disk Drive
HMI Human-Machine Interface. A software application that presents information to an operator about the state
of a process and accepts and implements the operator’s control instructions.
HTTP Hypertext Transfer Protocol. An application protocol for distributed, collaborative, and hypermedia infor-
mation systems. HTTP is the foundation for data communication on the web.
Hygiene CTD widget displaying the current cumulative risk level posed to the system by the insights. This score
Score comprises the critical security insights, CVEs and anomalies that were detected, as well as how many critical
assets were identified. A low hygiene score indicates that the system is highly vulnerable to attacks.
ICMP Internet Control Message Protocol. A supporting protocol in the Internet protocol suite used by network
devices.
ICS Industrial Control Systems. Control systems used in industrial production, including supervisory control and
data acquisition (SCADA) systems.
IdP Identity Provider. A system entity that creates, maintains, and manages identity information for principals
while providing authentication services to relying applications within a federation or distributed network
IED Intelligent Electronic Devices
IoC Indicators of Compromise
Incident An instance of invalid network activity (network failure, malicious attack, user error, etc.)
Indicator • Static Indicator – Static information that con potentially affect the score of an alert.
For example: The asset type, subnet, and virtual zone group.
• Event Indicator – An observed related network activity that can potentially affect the score of an alert
and provides context to the given alert.
For example: Whether an asset has performed write operations, or whether an asset has communicated
using SMBv1.
Knowledge mined from CTD about the system or about one of the entities in the system.
Insight
IoT Internet of Things. A system of interrelated computing devices, machines or objects that transfer data over
a network. CTD’s proprietary framework swiftly incorporates and processing these devices and provides
micro-segmentation in the same manner as it does for IT and OT assets, with unified visibility, security
monitoring and risk assessment. By automatically discovering and classifying IoT devices in the network,
CTD correlates them with known vulnerabilities and continuously monitors them.
IoT Matcher Simple code section in JSON format describing the retrieval of information from an IoT device. These Active
HTTP and Telnet queries made to the assets obtain important device information (such as vendor, model,
type, OS version, role).
IP Internet Protocol. A numerical label assigned to each device connected to a computer network that uses
the Internet Protocol for communication. It provides identification of the host or network interface and the
device’s location address.
IT Information Technology
JSON A lightweight format for storing and transporting data, usually used when data is sent from a server to a
web page. It is "self-describing" and easy to understand.
Known CTD uses a sophisticated signatures-based database to enhance its capability for identifying known attacks.
Threats
KPI Key Process Indicator. A quantifiable measure used to evaluate the success of an organization, employee,
etc., in meeting performance objectives.
MAC Media Access Control address. This device address is a unique identifier assigned to a network interface for
communication at the data link layer of a network segment.
Master An event that occurs whose sensitivity value determines that it is not interesting or relevant enough to be
Event classified as an alert.

Term Meaning
MitM Man-in-the-Middle. Type of attack in which the attacker secretly relays and possibly alters the communica-
tion between two parties who believe they are communicating with each other directly.
ML Machine Learning. CTD’s ML alert algorithm delivers fast response without the distracting noise of unneces-
sary alerts.
MLFB Order Number
NetFlow Source of asset data and network anomaly detection whose summarized data flows through the network.
Enhances CTD’s statistical data for network analytics.
NTP Network Time Protocol
Operator A person in charge of operating CTD.
Operational System mode in which the system raises alerts about new assets, baselines, and abnormal communication,
mode having already learned the necessary information about the network communications in the site from
Training mode
OS Operating System
OT Operational Technology. Hardware and software that detect or cause a change through the direct monitor-
ing and/or control of physical devices, processes and events in the enterprise.
PCAP Packet Capture. By using PCAPs to records events, CTD can display which information was changed during
a particular action/activity.
PCS 7 SIMATIC PCS 7 Process Control System.
Ping Sweep AKA an Internet Control Message Protocol (ICMP) sweep. A supporting protocol in the Internet protocol
suite used by network devices, including routers, to send error messages and operational information
indicating, for example, that a requested service is not available or that a host or router could not be
reached. Whereas a single ping will tell you whether one specified host computer exists on the network, a
ping sweep consists of ICMP ECHO requests sent to multiple hosts; if a given address is live, it will return an
ICMP ECHO reply.
PLC Programmable Logic Controller. An industrial digital computer that has been ruggedized and adapted for
the control of manufacturing processes.
Policy Rule An expression that differentiates between communication that is considered a corporate policy violation
and that which is allowed.
Policy Viola- Type of alert triggered when the detected communication did not match any explicit ‘Allow’ or ‘Alert’ policy
tion rule
PsExec A lightweight telnet-replacement that lets you execute processes on other systems, complete with full
interactivity for console applications, without having to manually install client software.
RCA Root Cause Analytics. This CTD feature provides visibility into the chain of events leading up to every single
alert, which is particularly important for OT security alerts. RCA enables fast and easy triage of alerts, as
well as proactive threat hunting. By providing the context surrounding the associated threat and risk, RCA
helps users hunt for threats and resolve security events.
RTU Remote Terminal Unit. A multipurpose device used for remote monitoring and control of various devices
and systems for automation. It is typically deployed in an industrial environment and serves a similar
purpose to PLCs but to a higher degree.
SAML Security Assertion Markup Language. An open standard for exchanging authentication and authorization
data between parties, in particular, between an identity provider (IdP) and a service provider SP. SAML
is an XML-based markup language for security assertions (statements that service providers use to make
access-control decisions).
S7Comm Siemens proprietary protocol that runs between PLCs of the Siemens S7-300/400 family
SCADA Supervisory Control And Data Acquisition
Sensitivity Entity that controls the level to be used when correlating between associated alerts. For example, high
sensitivity is in effect when the user trusts the communication between zones.
SIEM Security Information and Event Management
SMB Server Message Block. SMB operates as an application-layer network protocol mainly used for providing
shared access to files, printers, and serial ports and miscellaneous communications between nodes on a
network. It also provides an authenticated inter-process communication mechanism.

Term Meaning
SMTP Simple Mail Transfer Protocol. An Internet standard for electronic mail (email) transmission.
SNMP Simple Network Management Protocol
SOC Security Operations Center. A centralized unit dealing with security issues on an organizational and techni-
cal level.
SP Service Provider. A system entity that receives and accepts authentication assertions
SPAN Switched Port Analyzer. Used to monitor network traffic. With port mirroring enabled, the SPAN switch
sends a copy of all network packets seen on one port (or an entire VLAN) to another port, where the packet
can be analyzed.
SSH Secure Shell. Cryptographic network protocol for operating network services securely over an unsecured
network. Provides administrators with a secure way to access a remote computer. This encryption and pro-
tocol technology is used to connect two computers to lock out eavesdroppers by encrypting the connection
and scrambling the transmitted data so it is meaningless to anyone outside of the two computers.
SSL Secure Sockets Layer. Standard security technology for establishing an encrypted link between a web
server and a browser. This link ensures that all data passed between the web server and browsers remain
private and integral.
Story See Chain of Events
Subnet A group of IPs. Used to segregate the internet
SYN A type of Distributed Denial of Service (DDoS) attack that exploits part of the normal TCP three-way
handshake to consume resources on the targeted server and render it unresponsive.
TCP Transmission Control Protocol
Training Learning mode in which CTD dynamically profiles the site’s normal process behavior, assembling a baseline
mode by observing all network traffic and registering it as valid. Alerts are triggered for critical changes and
security risks, and newly discovered assets and communication patterns are recorded in the baseline as
shown on the System Management page.
UDP User Datagram Protocol
UEFI Unified Extensible Firmware Interface. A specification for a software program that connects a computer's
firmware to its operating system (OS). UEFI is expected to eventually replace BIOS. Like BIOS, UEFI is
installed at the time of manufacturing and is the first program that runs when a computer is turned on.
UI User Interface
UPS Uninterruptible Power Supply
User A person using the CTD web interface.
UUID Unique User Identification.
Virtual Capability for grouping related assets in a logical view. Virtual Zones allow definition of a Baseline Deviation
Zones alert policy for each Virtual Zone or communication between Virtual Zones.
VM Virtual Machine
WMI Windows Management Instrumentation. The infrastructure for management data and operations on Win-
dows-based operating systems.
Zones See Virtual Zones

Claroty CTD v4.8.0 Reference Guide 20230329

Uploaded by

Copyright:

Available Formats

Claroty CTD v4.8.0 Reference Guide 20230329

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Claroty CTD v4.8.0 Reference Guide 20230329

Uploaded by

Copyright:

Available Formats

Continuous Threat

Detection (CTD) Reference

29-Mar-2023 CTD Version 4.8.0 Page 2 of 227

29-Mar-2023 CTD Version 4.8.0 Page 3 of 227

4.2.1. IoT Matchers Configuration ..................................................................... 133

29-Mar-2023 CTD Version 4.8.0 Page 4 of 227

13.3. CEF (Legacy) Format ......................................................................................... 186

29-Mar-2023 CTD Version 4.8.0 Page 5 of 227

To view the most updated version of this document, visit docs.claroty.com

29-Mar-2023 CTD Version 4.8.0 Page 6 of 227

29-Mar-2023 CTD Version 4.8.0 Page 7 of 227

2.1. Detection Engines

1. Sniffs packets from the network

Figure 1. Claroty CTD has five detection engines

2.1.1. BEHAVIOR ANOMALIES DETECTOR

29-Mar-2023 CTD Version 4.8.0 Page 8 of 227

2.1.2. SIGNATURE BASED DETECTOR

2.1.3. SECURITY BEHAVIOURAL PATTERN DETECTOR

2.1.4. OPERATIONAL BEHAVIOURAL PATTERN DETECTOR

2.1.5. RULE-BASED THREAT DETECTOR

2.2. Events, Alerts, and Stories

29-Mar-2023 CTD Version 4.8.0 Page 9 of 227

• CTD Correlates alerts and combines them into stories.

Figure 2. Events, Alerts, and Stories

2.3. Alerts Table

It also lists the following:

Alert Name Description Alert Resolution Resolution MI- Cap- Reten-

Baseline Rule This alert detects Integri- Not gener- • Approve No No 12

Configuration This alert de- Integri- • Approve • Approve Yes No 12

29-Mar-2023 CTD Version 4.8.0 Page 10 of 227

Alert Name Description Alert Resolution Resolution MI- Cap- Reten-

Configuration This alert detects Integri- • Approve • Approve Yes No 12

DCS Configu- This alert detects Integri- • Approve • Approve Yes No 12

Firmware This alert detects Integri- • Approve • Approve Yes Yes 12

Known Threat This alert detects Securi- • Approve • Approve No Yes 12

Login This alert detects Securi- • Approve • Approve Yes Yes 3

Man-in-the- This alert detects Securi- • Approve • Approve Yes Yes 3

Monitor or This alert detects Integri- • Approve • Approve Yes No 12

29-Mar-2023 CTD Version 4.8.0 Page 11 of 227

Alert Name Description Alert Resolution Resolution MI- Cap- Reten-

Online Edit This alert detects Integri- • Approve • Approve Yes No 12

Policy Rule This alert detects Integri- • Ignore • Ignore Yes No 12

Policy Viola- This alert detects Integri- Automati- • Approve Yes No 12

Settings This alert detects Integri- • Approve • Approve Yes Yes 12

2.4. Alert Resolution Options

29-Mar-2023 CTD Version 4.8.0 Page 12 of 227

2.4.4. APPROVE SELECTED

2.4.5. APPROVE ALL

2.4.7. APPROVE & UPDATE POLICY

29-Mar-2023 CTD Version 4.8.0 Page 13 of 227

2.5. Managing Integrity Alerts

2.5.1. ASSET INFORMATION CHANGE

Examples of information changes are:

2.5.1.1. Alert Significance

2.5.1.2. Analyzing the Alert

29-Mar-2023 CTD Version 4.8.0 Page 14 of 227

2.5.1.3. Resolution Options

2.5.2. BASELINE RULE

2.5.2.1. Alert Significance