Continuous Threat

Detection (CTD) Alert

Behavior
Confidential & Proprietary | Copyright © 2023 Claroty Ltd. All rights reserved
18-May-2023
 CTD Alert Behavior

TABLE OF CONTENTS

1. Alert Creation and Resolution Process .............................................................................. 6

2. Alerts Table ....................................................................................................................... 8
2.1. ............................................................................................................................... 8
2.2. Asset Information Change .................................................................................... 10
2.2.1. Alert Significance ....................................................................................... 10
2.2.2. Analyzing the Alert .................................................................................... 11
2.2.3. Resolution Options .................................................................................... 11
2.2.4. Resolution Logic ........................................................................................ 11
2.2.5. MITRE ATT&CK Technique Mapping ........................................................... 12
2.3. Baseline Rule ....................................................................................................... 12
2.3.1. Alert Significance ....................................................................................... 12
2.3.2. Analyzing the Alert .................................................................................... 12
2.3.3. Resolution Options .................................................................................... 12
2.3.4. Resolution Logic ........................................................................................ 13
2.4. Configuration Download ...................................................................................... 13
2.4.1. Alert Significance ....................................................................................... 13
2.4.2. Analyzing the Alert .................................................................................... 13
2.4.3. Resolution Options .................................................................................... 14
2.4.4. Resolution Logic ........................................................................................ 14
2.4.5. MITRE ATT&CK Technique Mapping ........................................................... 14
2.5. Configuration Upload ........................................................................................... 14
2.5.1. Alert Significance ....................................................................................... 15
2.5.2. Analyzing the Alert .................................................................................... 15
2.5.3. Resolution Options .................................................................................... 15
2.5.4. Resolution Logic ........................................................................................ 15
2.5.5. MITRE ATT&CK Technique Mapping ........................................................... 16
2.6. DCS Configuration Change Alert ........................................................................... 16
2.6.1. Alert Significance ....................................................................................... 16
2.6.2. Analysis ..................................................................................................... 16
2.6.3. Resolution Options .................................................................................... 17
2.6.4. Resolution Logic ........................................................................................ 17
2.6.5. MITRE ATT&CK Technique Mapping ........................................................... 17
2.7. Denial of Service .................................................................................................. 17
2.7.1. Alert Significance ....................................................................................... 18
2.7.2. Analyzing the Alert .................................................................................... 18
2.7.3. Resolution Options .................................................................................... 18
2.7.4. Resolution Logic ........................................................................................ 18
2.7.5. MITRE ATT&CK Technique Mapping ........................................................... 18
2.8. Failed Login .......................................................................................................... 18
2.8.1. Alert Significance ....................................................................................... 19
2.8.2. Analyzing the Alert .................................................................................... 19
2.8.3. Resolution Options .................................................................................... 19
2.8.4. Resolution Logic ........................................................................................ 19
2.8.5. MITRE ATT&CK Technique Mapping ........................................................... 19
2.9. File System Change .............................................................................................. 20

18-May-2023 Page 2 of 46
 CTD Alert Behavior

2.9.1. Alert Significance ....................................................................................... 20

2.9.2. Analyzing the Alert .................................................................................... 20
2.9.3. Resolution Options .................................................................................... 20
2.9.4. Resolution Logic ........................................................................................ 21
2.9.5. MITRE ATT&CK Technique Mapping ........................................................... 21
2.10. Firmware Download ........................................................................................... 21
2.10.1. Alert Significance ..................................................................................... 21
2.10.2. Analyzing the Alert ................................................................................... 22
2.10.3. Resolution Options .................................................................................. 22
2.10.4. Resolution Logic ...................................................................................... 22
2.10.5. MITRE ATT&CK Technique Mapping ......................................................... 23
2.10.6. Alert Significance ..................................................................................... 23
2.10.7. Analyzing the Alert ................................................................................... 23
2.10.8. Resolution Options .................................................................................. 24
2.11. Host Scan ........................................................................................................... 24
2.11.1. Alert Significance ..................................................................................... 24
2.11.2. Analyzing the Alert ................................................................................... 24
2.11.3. Resolution Options .................................................................................. 25
2.11.4. Resolution Logic ...................................................................................... 25
2.11.5. MITRE ATT&CK Technique Mapping ......................................................... 25
2.12. Known Threat Alerts ........................................................................................... 25
2.12.1. Alert Significance ..................................................................................... 26
2.12.2. Analyzing the Alert ................................................................................... 26
2.12.3. Resolution Options .................................................................................. 26
2.12.4. Resolution Logic ...................................................................................... 26
2.13. Man-in-the-Middle Attack ................................................................................... 27
2.13.1. Alert Significance ..................................................................................... 27
2.13.2. Analyzing the Alert ................................................................................... 27
2.13.3. Resolution Options .................................................................................. 27
2.13.4. Resolution Logic ...................................................................................... 27
2.13.5. MITRE ATT&CK Technique Mapping ......................................................... 27
2.14. Memory Reset .................................................................................................... 28
2.14.1. Alert Significance ..................................................................................... 28
2.14.2. Analyzing the Alert ................................................................................... 28
2.14.3. Resolution Options .................................................................................. 28
2.14.4. Resolution Logic ...................................................................................... 28
2.14.5. MITRE ATT&CK Technique Mapping ......................................................... 29
2.15. Mode Change ..................................................................................................... 29
2.15.1. Alert Significance ..................................................................................... 29
2.15.2. Analyzing the Alert ................................................................................... 29
2.15.3. Resolution Options .................................................................................. 30
2.15.4. Resolution Logic ...................................................................................... 30
2.15.5. MITRE ATT&CK Technique Mapping ......................................................... 30
2.16. Monitor/Debug Mode ......................................................................................... 30
2.16.1. Alert Significance ..................................................................................... 31
2.16.2. Analyzing the Alert ................................................................................... 31

18-May-2023 Page 3 of 46
 CTD Alert Behavior

2.16.3. Resolution Options .................................................................................. 31

2.16.4. Resolution Logic ...................................................................................... 31
2.16.5. MITRE ATT&CK Technique Mapping ......................................................... 32
2.17. New Asset .......................................................................................................... 32
2.17.1. Alert Significance ..................................................................................... 32
2.17.2. Analyzing the Alert ................................................................................... 32
2.17.3. Resolution Options .................................................................................. 33
2.17.4. Resolution Logic ...................................................................................... 33
2.17.5. MITRE ATT&CK Technique Mapping ......................................................... 34
2.17.6. Alert Significance ..................................................................................... 34
2.17.7. Analyzing the Alert ................................................................................... 34
2.17.8. Resolution Options .................................................................................. 35
2.18. New Conflict Asset .............................................................................................. 35
2.18.1. Alert Significance ..................................................................................... 35
2.18.2. Analyzing the Alert ................................................................................... 35
2.18.3. Resolution Options .................................................................................. 35
2.18.4. Resolution Logic ...................................................................................... 36
2.18.5. MITRE ATT&CK Technique Mapping ......................................................... 36
2.19. Online Edit ......................................................................................................... 36
2.19.1. Alert Significance ..................................................................................... 36
2.19.2. Analyzing the Alert ................................................................................... 37
2.19.3. Resolution Options .................................................................................. 37
2.19.4. Resolution Logic ...................................................................................... 37
2.19.5. MITRE ATT&CK Technique Mapping ......................................................... 37
2.20. Policy Rule Match ............................................................................................... 37
2.20.1. Alert Significance ..................................................................................... 38
2.20.2. Analyzing the Alert ................................................................................... 38
2.20.3. Resolution Options .................................................................................. 38
2.20.4. Resolution Logic ...................................................................................... 38
2.20.5. MITRE ATT&CK Technique Mapping ......................................................... 38
2.21. Policy Violation ................................................................................................... 39
2.21.1. Alert Significance ..................................................................................... 39
2.21.2. Analyzing the Alert ................................................................................... 39
2.21.3. Resolution Options .................................................................................. 40
2.21.4. Resolution Logic ...................................................................................... 40
2.21.5. MITRE ATT&CK Technique Mapping ......................................................... 40
2.22. Port Scan ............................................................................................................ 41
2.22.1. Alert Significance ..................................................................................... 41
2.22.2. Analyzing the Alert ................................................................................... 41
2.22.3. Resolution Options .................................................................................. 42
2.22.4. Resolution Logic ...................................................................................... 42
2.22.5. MITRE ATT&CK Technique Mapping ......................................................... 42
2.23. Settings Change ................................................................................................. 42
2.23.1. Alert Significance ..................................................................................... 42
2.23.2. Analyzing the Alert ................................................................................... 43
2.23.3. Resolution Options .................................................................................. 43

18-May-2023 Page 4 of 46
 CTD Alert Behavior

2.23.4. Resolution Logic ...................................................................................... 43

2.23.5. MITRE ATT&CK Technique Mapping ......................................................... 43
2.24. Suspicious Activity .............................................................................................. 43
2.24.1. Alert Significance ..................................................................................... 44
2.24.2. Analyzing the Alert ................................................................................... 44
2.24.3. Resolution Options .................................................................................. 44
2.24.4. Resolution Logic ...................................................................................... 44
2.24.5. MITRE ATT&CK Technique Mapping ......................................................... 44
2.25. Suspicious File Transfer ...................................................................................... 45
2.25.1. Alert Significance ..................................................................................... 45
2.25.2. Analyzing the Alert ................................................................................... 45
2.25.3. Resolution Options .................................................................................. 45
2.25.4. Resolution Logic ...................................................................................... 45
2.25.5. MITRE ATT&CK Technique Mapping ......................................................... 46

18-May-2023 Page 5 of 46
 CTD Alert Behavior Alert Creation and Resolution Proc-
ess

1. Alert Creation and Resolution Process

The following is a high-level explanation of the Alert creation and resolution process:

1. An Event is created.
2. The Event receives a score from the Scoring Mechanism.
• If the score is below 80, the Event becomes a Master Event.
a. Until resolved, CTD can add new Events to the Master Event or Alert. Each addition
returns the Alert to the scoring mechanism.
b. If, after 24 hours, additional events are not added to the Master Event, it is Resolved by
CTD as Unqualified.
• If the score is above 80, the Event becomes an Alert. What happens next depends on
whether CTD is in Training Mode or Operational Mode.
• In Training Mode
• CTD immediately resolves four alert types (New Asset, Asset Information Change, New
Conflict Asset, and Policy Violation) to prevent alert flooding since CTD cannot score
them optimally when in training mode.
• The Baseline Rule alert type is not created.
• All other alerts behave as in Operational Mode.
• In Operational Mode
• The Alert can be resolved manually.
For further information, see https://docs.claroty.com/ctd/en/continuous-threat-detec-
tion--ctd--reference-guide/threat-detection/alert-resolution-options.html
• The Alert can be resolved using Auto Resolve Rules.
For further information, see https://docs.claroty.com/ctd/en/continuous-threat-detec-
tion--ctd--user-guide/threat-detection/alert-rules/auto-resolve.html

NOTE
The score of 80 as the threshold for Alert creation
can be controlled by using the Alert Sensitivity setting.
See https://docs.claroty.com/ctd/en/continuous-threat-detection--ctd--adminis-
tration-guide/configuration/configuring-alert-settings/alert-sensitivity.html.

18-May-2023 Page 6 of 46
 CTD Alert Behavior Alert Creation and Resolution Proc-
ess

Figure 1. Alert Creation and Resolution

18-May-2023 Page 7 of 46
 CTD Alert Behavior Alerts Table

2. Alerts Table

This table summarizes all the alerts currently available in CTD, including the following:

• A description of the alert

• CTD Alert type
• Resolution options in Training Mode and Operational mode.
• 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 Reten- Cap- MI-

Type Options in Options in tion Pe- sav- TRE
Training Operation- riod er Info
Mode al Mode

Asset Infor- This alert detects Integri- Automati- • Approve Forever No Yes
mation changes to asset- ty cally ap- All
Change related informa- proved by • Approve
(page 10) tion (such as Firm- CTD Selected
ware, OS, Host- • Archive
name, and Slot
Cards)

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

(page 12) baseline-related ty ated • Archive months
activity based on
custom configura-
tion

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

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

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

Upload Configuration Up- ty • Archive • Archive months
(page 14) load events

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

ration Change events related to ty • Archive • Archive months
(page 16) changes to the
DCS Configuration

Denial of Serv- This alert detects Securi- • Approve • Approve 12 Yes Yes
ice (page 17) DoS attacks ty • Archive • Archive months

File System This alert detects Integri- • Approve • Approve 12 Yes Yes
Change events related to ty • Archive • Archive months
(page 20) changes to the File
System

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

Download Firmware Down- ty • Archive • Archive months
(page 21) load events

18-May-2023 Page 8 of 46
 CTD Alert Behavior Alerts Table

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

Type Options in Options in tion Pe- sav- TRE
Training Operation- riod er Info
Mode al Mode

Host Scan This alert detects Securi- • Approve • Approve 3 Yes Yes
(page 24) 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 12 Yes No

Alerts suspicious events ty • Archive • Archive months
(page 25) based on Network
Signature match-
ing

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

(page 18) Failed Login events ty • Archive • Archive months

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

Middle Attack Man-in-the-Middle ty • Archive • Archive months
(page 27) (MiTM) attacks

Memory Reset This alert detects Securi- • Approve • Approve 12 Yes Yes
(page 28) Memory Reset ty • Archive • Archive months
events

Mode Change This alert detects Integri- • Approve • Approve 12 Yes Yes
(page 29) events related to ty • Archive • Archive months
changes to the de-
vice Mode (Run,
Stop, Program)

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

Debug Mode when a device ty • Archive • Archive months
(page 30) mode is set on
Monitor or Debug

New Asset This alert detects Integri- Automati- • Approve Forever No Yes
(page 32) new assets in the ty cally ap- and Up-
environment proved by date Poli-
CTD cy
• Ignore
• Acknowl-
edge

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

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

(page 36) Online Edit at- ty • Archive • Archive months
tempts to a device
program

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

Match policy related ac- ty • Acknowl- • Acknowl- months
(page 37) tivity based on edge edge
custom configura-
tion

18-May-2023 Page 9 of 46
 CTD Alert Behavior Asset Information Change

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

Type Options in Options in tion Pe- sav- TRE
Training Operation- riod er Info
Mode al Mode

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

tion Alert anomalies in the ty cally ap- and Up- months
(page 39) network communi- proved by date Poli-
cations based on CTD cy
Zone policies • Ignore
• Acknowl-
edge

Port Scan This alert detects Securi- • Approve • Approve 3 Yes Yes
(page 41) 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 12 Yes Yes

Change events related to ty • Archive • Archive months
(page 42) changes to the De-
vice Settings

Suspicious Ac- This alert detects Securi- • Approve • Approve 3 Yes Yes
tivity suspicious events ty • Archive • Archive months
(page 43) based on OT pro-
tocol anomalies

Suspicious File This alert detects Securi- • Approve • Approve 12 Yes Yes
Transfer suspicious events ty • Archive • Archive months
(page 45) based on Yara
Rule matching

2.2. Asset Information Change

An Information Change alert occurs when information about an asset is changed. Every asset
information change must be verified and approved. When a software version changes, the system
also reports that change.

Examples of information changes are:

• Firmware
• OS
• Hostname
• Slot Cards

2.2.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.

18-May-2023 Page 10 of 46
 CTD Alert Behavior Asset Information Change

2.2.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.2.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve All
• Approve Selected
• Archive

2.2.4. RESOLUTION LOGIC

• Approve All - Approves all information about the changes to the Asset that triggered this
alert. Because this alert is linked to network changes, it is generated again whenever there are
network changes related to the relevant Asset.
When approving in Bulk Action or Auto Resolve Rule, it will Approve All.
• Approve Selected - Approves selected information about the changes that occurred in the Asset
and triggered this alert. Since this Alert is linked to network changes, it will be generated again
whenever there are network changes related to the relevant Asset.
• Archive - Rejects all the information about the changes in the Asset. Since this Alert is linked
to network changes, it will be generated again whenever network changes are related to the
relevant Asset.

18-May-2023 Page 11 of 46
 CTD Alert Behavior Baseline Rule

NOTE
This alert is only generated if the New Asset Alert linked to the relevant Asset is
unresolved. In that case, all Asset Information Changes will appear in the relevant
New Asset Alert.

2.2.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0864: Transient Cyber Asset

• T0839: Module Firmware - If firmware changes are to Module/Nested Devices
• T0857: System Firmware - If firmware changes are to Parent Devices/Assets directly mounted on
Rack Slots
• T0860: Wireless Compromise - If Asset changes are to Wireless LAN Controllers

2.3. 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

2.3.1. ALERT SIGNIFICANCE

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.

2.3.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:

• 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.

2.3.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

18-May-2023 Page 12 of 46
 CTD Alert Behavior Configuration Download

• Approve
• Archive

2.3.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. Since this is a custom alert (based on
parameters you specify in Baseline Rules), alerts of the same type will always be generated
again.
• Archive - Rejects the action that triggered the alert. Since this is a custom alert (based on
parameters you specify in Baseline Rules), alerts of the same type will always be generated
again.

2.4. 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

2.4.1. ALERT SIGNIFICANCE

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.

2.4.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:

• 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

18-May-2023 Page 13 of 46
 CTD Alert Behavior Configuration Upload

• 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.

2.4.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.4.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.4.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0843: Program Download

• T0873: Project File Infection
• T0821: Modify Controller Tasking

2.5. 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.

18-May-2023 Page 14 of 46
 CTD Alert Behavior Configuration Upload

Alert Example:

A configuration has been uploaded from controller 10.39.68.55 by XKYLL1135

2.5.1. ALERT SIGNIFICANCE

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.

2.5.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:

• 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 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.
• 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.

2.5.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.5.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

18-May-2023 Page 15 of 46
 CTD Alert Behavior DCS Configuration Change Alert

2.5.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0845: Program Upload

• T0873: Project File Infection
• T0821: Modify Controller Tasking

2.6. 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.

2.6.1. ALERT SIGNIFICANCE

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.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:

• 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 the system
• 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 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.

18-May-2023 Page 16 of 46
 CTD Alert Behavior Denial of Service

• 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.

2.6.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.6.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.6.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0831: Manipulation of Control

• T0836: Modify Parameter

2.7. 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

18-May-2023 Page 17 of 46
 CTD Alert Behavior Failed Login

2.7.1. ALERT SIGNIFICANCE

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.

2.7.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:

• 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.

2.7.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.7.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.7.5. MITRE ATT&CK TECHNIQUE MAPPING

T0814: Denial of Service

2.8. 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

18-May-2023 Page 18 of 46
 CTD Alert Behavior Failed Login

2.8.1. ALERT SIGNIFICANCE

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.

2.8.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:

• 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.

2.8.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.8.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.8.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0886: Remote Services - If the source Asset is in an internal network

• T0822: External Remote Services - If the source Asset is in an external network with an applica-
tion layer

18-May-2023 Page 19 of 46
 CTD Alert Behavior File System Change

• T0883: Internet Accessible Device - if the source Asset is in an external network with Non-RFC
1918 IP address
• T0859: Default Credentials - If the source has a default username
• T0812: Valid Accounts - If the source has Valid Accounts

2.9. 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.

2.9.1. ALERT SIGNIFICANCE

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.

2.9.2. ANALYZING THE ALERT

You can use the Alerts page to find the necessary information when analyzing the alert. While on
the Alert page, use the following list of checks for analysis:

• 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 file was was added/edited /deleted
• 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.
• Identify changes performed as part of this activity.
• 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. Providing them with file
changes will help to understand the impact that the change could have on the process or OT
operations.

2.9.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve

18-May-2023 Page 20 of 46
 CTD Alert Behavior Firmware Download

• Archive

2.9.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.9.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0831: Manipulation of Control

• T0809: Data Destruction (v4.8.x and above)
• T0849: Masquerading (v4.8.x and above)
• T0867: Lateral Tool Transfer (v4.8.x and above)
• T0873: Project File Infection (v4.8.x and above)
• T0851: Rootkit (v4.8.x and above)

2.10. 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

2.10.1. ALERT SIGNIFICANCE

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.

18-May-2023 Page 21 of 46
 CTD Alert Behavior Firmware Download

• 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.

2.10.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:

• 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 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.
• Confirm if this could be related to any ongoing, planned or emergency maintenance, deploy-
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.
• 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 the impact that the change can have on process or OT operations.

2.10.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.10.4. RESOLUTION LOGIC

• Approve - Approves the action that caused the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.

18-May-2023 Page 22 of 46
 CTD Alert Behavior Firmware Download

• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.10.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0889: Modify Program

• T0820: Exploitation for Evasion
• T0839: Module Firmware - If Firmware Downloaded to Module/Nested Devices
• T0857: System Firmware - If Firmware Downloaded to Parent Devices

2.10.6. ALERT SIGNIFICANCE

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.

2.10.7. 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:

• 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 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.

18-May-2023 Page 23 of 46
 CTD Alert Behavior Host Scan

• Confirm if this could be related to any ongoing, planned or emergency maintenance, deploy-
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.
• 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 the impact that the change can have on process or OT operations.

2.10.8. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.11. 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

2.11.1. ALERT SIGNIFICANCE

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.

2.11.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:

18-May-2023 Page 24 of 46
 CTD Alert Behavior Known Threat Alerts

• 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?

2.11.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.11.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. To prevent Alert flooding, even though
this is a Security Alert, if an identical scan is performed among the same group of Assets, an
Alert with identical characteristics will not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.11.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0846: Remote System Discovery

• T0840: Network Connection Enumeration
• T0846: Remote System Discovery - for ICMP Scan
• T0855: Commonly Used Port - For Scanning in ports: 21, 22, 23, 25, 53, 69, 80, 88, 102, 110, 135,
137, 138, 139, 143, 161, 162, 389, 443, 445, 502, 44818, 20000

2.12. 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.

18-May-2023 Page 25 of 46
 CTD Alert Behavior Known Threat Alerts

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

2.12.1. ALERT SIGNIFICANCE

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.

2.12.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:

• 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.

2.12.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.12.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert.

To prevent alert flooding, and even though this is a Security Alert, if an identical action (Identical
signature) is performed among the same group of Assets, an Alert with identical characteristics
will not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

18-May-2023 Page 26 of 46
 CTD Alert Behavior Man-in-the-Middle Attack

2.13. 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.

2.13.1. ALERT SIGNIFICANCE

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.

2.13.2. ANALYZING THE ALERT

You can use the Alerts page to find the necessary information when analyzing the alert. While on
the Alert page, use the following list of checks for analysis:

• Check the Title and Indicators showing, for instance:

• Whether this activity has been seen for the first time in last 30 days
• Whether this asset was previously involved in IT/OT operations
• Whether the event is related to previous alerts in the system
• 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 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 to understand the impact
on IT/OT operations.

2.13.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.13.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.13.5. MITRE ATT&CK TECHNIQUE MAPPING

T0830: Man in the Middle (v4.8.x and above)

18-May-2023 Page 27 of 46
 CTD Alert Behavior Memory Reset

2.14. 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

2.14.1. ALERT SIGNIFICANCE

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.

2.14.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:

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

• Check whether the source alert was seen performing this operation earlier.
• 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.
• 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.
• 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 activity.
• In case of doubt or suspicion, work with process and/or OT engineers, provide them with code
changes and understand the impact that the change can have on process or OT operations.

2.14.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.14.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.

18-May-2023 Page 28 of 46
 CTD Alert Behavior Mode Change

• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.14.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0809: Data Destruction

• T0816: Device Restart/Shutdown

2.15. 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

2.15.1. ALERT SIGNIFICANCE

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.

2.15.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:

• 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.

18-May-2023 Page 29 of 46
 CTD Alert Behavior Monitor/Debug Mode

• Confirm if this could be related to any ongoing, planned, or emergency maintenance, deploy-
ment project or activity.
• 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.
• In case of doubt or suspicion, work with process and/or OT engineers, provide them with code
changes and understand the impact that the change can have on process or OT operations.

2.15.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.15.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.15.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0858: Change Operating Mode

• T0821: Modify Controller Tasking
• T0800: Activate Firmware Mode - If the mode changed to program mode
• T0816: Device Restart/Shutdown - If the Asset restarted or shut down

2.16. Monitor/Debug Mode

This 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.

18-May-2023 Page 30 of 46
 CTD Alert Behavior Monitor/Debug Mode

Alert Example:

Controller STHNJENA83 is monitored/debugged by XLCUL0010

2.16.1. ALERT SIGNIFICANCE

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.

2.16.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:

• Check the Title and Indicators showing, for instance:

• 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-
ment project or activity.
• If it was a scheduled/planned activity, verify that the actual change that was done is the planned
change.
• 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 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 the impact that the change can have on process or OT operations.

2.16.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.16.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

18-May-2023 Page 31 of 46
 CTD Alert Behavior New Asset

2.16.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0801: Monitor Process State

• T0838: Modify Alarm Settings

2.17. 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

2.17.1. ALERT SIGNIFICANCE

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.

2.17.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:

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

18-May-2023 Page 32 of 46
 CTD Alert Behavior New Asset

• 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.

2.17.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve & Update Policy

• Ignore
• Acknowledge

2.17.4. RESOLUTION LOGIC

• Approve & Update Policy - Approves the Asset and add this information to CTD Baseline and
Assets List.
• When approving from the Alerts page, the system allows the option to choose which Zone
Rules (Policies) are linked to the Asset to approve.
• When approving in Bulk Action or Auto Resolve Rule (Approve), all Zone Rules (Policies) are
approved. Once approved, the Alert is not recreated for the same Asset.

NOTE
Until a New Asset Alert is approved, Asset Information Changes and new Zone
Rules (Policies) are added to this alert and will not generate new alerts. (All other
Alerts will be generated regardless of the approval). Until this Alert is approved,
the Asset will not appear in the Asset List.

• Ignore/Acknowledge/Archive (Bulk Action or Auto Resolve Rule) - Rejects the asset that trig-
gered the alert, and delete the Asset from the CTD Network. Since this Alert is linked to network
changes, it is generated again whenever there are network changes related to this asset (in oth-
er words, if the asset does exist in the network, the alert is created again). The only difference
between the three actions is how they are logged to help with auditing.
Example: An asset is deleted from the CTD Baseline and is the Primary Asset or the only
Non-Primary Asset of an Alert. In this case, the alert becomes irrelevant and is deleted within
24 hours, with no exceptions, to avoid a situation of an Alert without content. Accordingly,

18-May-2023 Page 33 of 46
 CTD Alert Behavior New Asset

we recommend Ignoring/Acknowledging/Archiving only Assets that are not online and for
which you want to receive an Alert when they connect again, such as laptops or mobile
phones.

2.17.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0866: Exploitation of Remote Services

• T0864: Transient Cyber Asset - Based on complex CTD calculation. For Internal Primary Asset
with non-remote protocols (RDP, SMB, SSH, VNC ,TELNET)
• T0848: Rogue Master - For non-IT Internal Primary Asset
• T0860: Wireless Compromise - For External Primary Asset of type Wireless LAN Controller
• T0822: External Remote Services - For External Primary Assets with non-OT protocols
• T0883: Internet Accessible Device - For External Primary Assets with Non-RFC 1918 IP address
• T0847: Replication Through Removable Media - For Assets with USB (based on USB Devices
Connected to Assets Insight)
• T0886: Remote Services - For Assets with protocols of type RDP, SMB, SSH, VNC ,TELNET

2.17.6. ALERT SIGNIFICANCE

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.

2.17.7. 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:

• 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.

18-May-2023 Page 34 of 46
 CTD Alert Behavior New Conflict Asset

2.17.8. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve & Update Policy

• Ignore
• Acknowledge

2.18. 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.

2.18.1. ALERT SIGNIFICANCE

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.

2.18.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:

• 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.

2.18.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve & Update Policy

18-May-2023 Page 35 of 46
 CTD Alert Behavior Online Edit

• Ignore
• Acknowledge

2.18.4. RESOLUTION LOGIC

• Approve & Update Policy - Approves the Asset merge and adds the information that triggered
the alert.
• When approving from the Alert page, the system also provides the option to choose which
Zone Rules (Policies) to approve.
• When approving in Bulk Action or by Auto Resolve Rule (Approve), it will approve all Zone
Rules (Policies). Since this Alert is linked to network changes, it will be generated again when-
ever there are network changes related to the relevant Assets.

• Ignore/Acknowledge/Archive (Bulk Action or Auto Resolve Rule) - Rejects the Asset merge and
adds this information to CTD Baseline. Since this Alert is linked to network changes, it will be
generated again whenever there are network changes related to the relevant Assets.
The only difference between the three actions is how they are logged to help with auditing.

2.18.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0848: Rogue Master

• T0830: Man in the Middle
• T0860: Wireless Compromise - If the Asset is Wireless LAN controller
• T0864: Transient Cyber Asset - If the Asset is non-IT Asset

2.19. 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

2.19.1. ALERT SIGNIFICANCE

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.

18-May-2023 Page 36 of 46
 CTD Alert Behavior Policy Rule Match

2.19.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:

• 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.
• 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.
• Identify changes performed as part of this activity.
• 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
• 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 the impact that the change can have on process or OT operations.

2.19.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.19.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.19.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0821: Modify Controller Tasking

• T0836: Modify Parameter
• T0838: Modify Alarm Settings

2.20. 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:

18-May-2023 Page 37 of 46
 CTD Alert Behavior Policy Rule Match

Communication matching policy rule ID 182 was detected from 10.234.125.254 to 10.121.70.151

2.20.1. ALERT SIGNIFICANCE

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.

2.20.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:

• 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.

2.20.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Ignore
• Acknowledge

2.20.4. RESOLUTION LOGIC

• Ignore - Rejects the action that triggered the alert. Since this is a custom alert (based on
parameters you specify in Zone Rules), alerts of the same type will always be generated again.
• Acknowledge - Rejects the action that triggered the alert. Since this is a custom alert (based on
parameters you specify in Zone Rules), alerts of the same type will always be generated again.
The only difference between the two actions is how they are logged to help with auditing.

2.20.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0800: Activate Firmware Update Mode – For relevant conversation type.

• T0801: Monitor Process State – For relevant conversation type.
• T0811: Data from Information Repositories – For relevant conversation type.
• T0821: Modify Controller Tasking – For relevant conversation type.
• T0822: External Remote Services – For a conversation between Assets in a network with an
application layer
• T0831: Manipulation of Control – For relevant conversation type.
• T0839: Module Firmware – For relevant conversation type.
• T0840: Network Connection Enumeration – For relevant conversation type.
• T0842: Network Sniffing – For relevant conversation type.

18-May-2023 Page 38 of 46
 CTD Alert Behavior Policy Violation

• T0844: Modify Program – For relevant conversation type.

• T0846: Remote System Discovery
• T0857: System Firmware – For relevant conversation type.
• T0858: Change Operating Mode – For relevant conversation type.
• T0859: Valid Account – For relevant conversation type.
• T0866: Exploitation of Remote Services – For relevant conversation type.
• T0867: Lateral Tool Transfer – For relevant conversation type.
• T0878: Alarm Suppression – For relevant conversation type.
• T0884: Connection Proxy – For relevant conversation type.
• T0886: Remote Services – For relevant conversation type.
• T0888: Remote System Information Discovery – For relevant conversation type.

2.21. 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

2.21.1. ALERT SIGNIFICANCE

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.

2.21.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:

• 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.

18-May-2023 Page 39 of 46
 CTD Alert Behavior Policy Violation

• 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.

2.21.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve & Update Policy

• Ignore
• Acknowledge

2.21.4. RESOLUTION LOGIC

• Ignore - Rejects the action that triggered the alert. Since this is a custom alert (based on
parameters you specify in Zone Rules), alerts of the same type will always be generated again.
• Acknowledge - Rejects the action that triggered the alert. Since this is a custom alert (based
on parameters you specify in Baseline Rules), alerts of the same type will always be generated
again.
The only difference between the two actions is how they are logged to help with auditing.

2.21.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0800: Activate Firmware Update Mode – For relevant conversation type.

• T0801: Monitor Process State – For relevant conversation type.
• T0811: Data from Information Repositories – For relevant conversation type.
• T0821: Modify Controller Tasking – For relevant conversation type.
• T0822: External Remote Services – For a conversation between Assets in a network with an
application layer
• T0831: Manipulation of Control – For relevant conversation type.
• T0839: Module Firmware – For relevant conversation type.
• T0840: Network Connection Enumeration – For relevant conversation type.
• T0842: Network Sniffing – For relevant conversation type.
• T0844: Modify Program – For relevant conversation type.

18-May-2023 Page 40 of 46
 CTD Alert Behavior Port Scan

• T0846: Remote System Discovery

• T0857: System Firmware – For relevant conversation type.
• T0858: Change Operating Mode – For relevant conversation type.
• T0859: Valid Account – For relevant conversation type.
• T0866: Exploitation of Remote Services – For relevant conversation type.
• T0867: Lateral Tool Transfer – For relevant conversation type.
• T0878: Alarm Suppression – For relevant conversation type.
• T0884: Connection Proxy – For relevant conversation type.
• T0886: Remote Services – For relevant conversation type.
• T0888: Remote System Information Discovery – For relevant conversation type.

2.22. 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.

2.22.1. ALERT SIGNIFICANCE

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.

2.22.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:

• 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.

18-May-2023 Page 41 of 46
 CTD Alert Behavior Settings Change

• 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.

2.22.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.22.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert.

To prevent Alert flooding, and even though it is a Security Alert, if an identical scan is performed
among the same group of Assets, an Alert with identical characteristics will not be generated for
30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.22.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0846: Remote System Discovery

• T0840: Network Connection Enumeration
• T0855: Commonly Used Port - For Scanning in ports 21, 22, 23, 25, 53, 69, 80, 88, 102,110, 135,
137, 138, 139, 143, 161, 162, 389, 443, 445, 502, 44818, 20000

2.23. 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

2.23.1. ALERT SIGNIFICANCE

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.

18-May-2023 Page 42 of 46
 CTD Alert Behavior Suspicious Activity

2.23.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:

• Check the Title and Indicators showing, for instance:

• Whether this activity is seen in the last 30 days
• Whether a code section was changed, added or removed.
• Whether the source asset was previously involved in OT operations
• 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.

2.23.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.23.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. If an identical action or communication is
performed among the same group of Assets or Zones, an Alert with identical characteristics will
not be generated for 30 days.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.23.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0840: Network Connection Enumeration

• T0805: Block Serial COM - Only for relevant events

2.24. 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

18-May-2023 Page 43 of 46
 CTD Alert Behavior Suspicious Activity

• Invalid Sessions
• Unknown Object
• Protocol DDoS

2.24.1. ALERT SIGNIFICANCE

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.

2.24.2. ANALYZING THE ALERT

• 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.

2.24.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.24.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

2.24.5. MITRE ATT&CK TECHNIQUE MAPPING

• T0855: Unauthorized Command Message

• T0856: Spoof Reporting Message
• T0806: Brute Force I/O - For I/O's activity
• T0835: Manipulate I/O Image - For I/O's activity
• T0836: Modify Parameter - For a writing activity
• T0821: Modify Controller Tasking - For a writing activity
• T0801: Monitor Process State - For a reading activity

18-May-2023 Page 44 of 46
 CTD Alert Behavior Suspicious File Transfer

2.25. 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

2.25.1. ALERT SIGNIFICANCE

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.

2.25.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:

• 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.

2.25.3. RESOLUTION OPTIONS

The following resolution options are available for this alert:

• Approve
• Archive

2.25.4. RESOLUTION LOGIC

• Approve - Approves the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.
• Archive - Rejects the action that triggered the alert. Since this is a Security Alert, alerts of the
same type will always be generated again.

18-May-2023 Page 45 of 46
 CTD Alert Behavior Suspicious File Transfer

2.25.5. MITRE ATT&CK TECHNIQUE MAPPING

T0867: Lateral Tool Transfer

18-May-2023 Page 46 of 46