00:00:05
to scan or not to
00:00:07
scan that is the
00:00:09
question whether to snower in the mind
00:00:12
of an asset owner to suffer the slings
00:00:15
and arrows of incomplete asset
00:00:18
inventories or to take arms against a
00:00:21
sea of OT monitoring vendors and by
00:00:25
opposing active scanning end
00:00:28
them I believe believe this is a quote
00:00:31
from William Shakespeare if Hamlet were
00:00:34
an asset owner who's contemplating
00:00:36
active scanning using OT monitoring
00:00:40
tools but in plain English I guess the
00:00:43
point I'm trying to make is yes asset
00:00:46
owners understand that active detection
00:00:48
is important but unfortunately they
00:00:52
don't trust it enough to use it and it's
00:00:56
understandable for instance between 2013
00:01:00
and 2018 when passive detection was the
00:01:04
method of OT monitoring vendors were
00:01:07
saying that the active detection of OT
00:01:09
devices is dangerous and should be
00:01:12
avoided over the years to compensate for
00:01:15
the limitations of the passive approach
00:01:17
many of those vendors slowly started to
00:01:19
add active to their products and the
00:01:21
messaging started to shift today these
00:01:24
same vendors claim that the active
00:01:26
approach is in fact safe reliable and
00:01:30
highly
00:01:32
recommended but how can we now trust
00:01:34
those claims especially when there are
00:01:37
no indepth studies or reports to back
00:01:40
them
00:01:41
up to address this Gap and provide the
00:01:44
IC security Community with a possible
00:01:47
answer I decided to investigate this
00:01:50
myself some of the findings you may find
00:01:55
surprising before we get into that we
00:01:57
have to cover another short history
00:01:59
lesson not related to Shakespeare to
00:02:02
clarify some key
00:02:04
terminology when OT monitoring vendors
00:02:06
first decided to utilize active they had
00:02:09
to distinguish it from the active
00:02:11
scanning traditionally used by it in
00:02:14
vulnerability scanners and other tools
00:02:16
so they designed their active detection
00:02:19
to mimic the communication between
00:02:21
engineering workstation software or
00:02:23
diagnostic tools and OT devices this was
00:02:27
actually a very smart move because
00:02:29
vendors were basically replicating
00:02:31
well-known Communications that already
00:02:34
exist in OT networks it also allowed
00:02:37
them to move away from the traditional
00:02:39
scanning of the broad range of ports and
00:02:42
services which when conducted on OT
00:02:45
devices could have negative
00:02:47
consequences but in this shift I believe
00:02:50
vendors got a bit carried away and
00:02:53
decided not to use the words active and
00:02:55
scanning to describe their approach
00:02:58
instead they use many different terms
00:03:01
including safe queries polling smart
00:03:04
polling selective probing safe probing
00:03:08
and so
00:03:09
on I would argue that instead of these
00:03:11
vendors could have simply used the term
00:03:14
targeted active scanning because
00:03:16
ultimately this detection is an active
00:03:19
communication it is a scan since OT
00:03:21
devices are scanned for responses but
00:03:24
it's targeted to match the communication
00:03:26
that an OT device expects from its
00:03:29
native tool or protocol but we get it
00:03:32
product marketing teams get to dictate
00:03:35
the terms in this study though I get to
00:03:38
call it the way I choose so to summarize
00:03:42
this lesson I differentiate between
00:03:45
traditional active scanning commonly
00:03:47
used by it tools and targeted active
00:03:49
scanning which is used by OT monitoring
00:03:52
tools and in terms of scope I decided to
00:03:55
investigate
00:03:57
both I focused spe specifically on plc's
00:04:01
because they are the most critical OT
00:04:03
end points that need to be fully
00:04:05
inventoried but can also be the riskiest
00:04:07
to scan I aimed to share my testing
00:04:10
methodology in detail to encourage
00:04:13
vendors to adopt similar testing
00:04:15
procedures so they can share their
00:04:16
results with the community as well the
00:04:19
other aspect I wanted to understand in
00:04:21
this study was the difference in
00:04:23
targeted active scanning across various
00:04:25
OT monitoring products in other words
00:04:28
can certain products be safer for plc's
00:04:31
compared to others I also wanted to
00:04:33
investigate the claim that targeted
00:04:36
active scanning mimic diagnostic tools
00:04:39
specifically in terms of impact and
00:04:42
finally I was curious to see the results
00:04:44
of traditional active scanning when
00:04:46
using this same testing
00:04:49
methodology so the basis of my study was
00:04:53
the following setup I had a small
00:04:55
Network created using an Alan Bradley
00:04:57
stratic switch on which I had three
00:04:58
plc's each from a different make and
00:05:01
model an Allan Bradley compact Logics
00:05:03
5370 a Phoenix contact PLC next and a
00:05:07
seaman s
00:05:08
71200 the idea was each PLC would run
00:05:11
its program while data logging was
00:05:13
enabled through the edge gateway then
00:05:16
the Cyber laptop which had high specs
00:05:18
would run multiple cyber security
00:05:19
scanning tools and each tool would take
00:05:22
its turn to scan a PLC while packets are
00:05:25
being monitored using wire shark finally
00:05:28
The Collection laptop was to view the
00:05:30
collected data and to serve as a control
00:05:33
so before scanning each PLC I would
00:05:35
first scan the collection laptop which
00:05:38
also had wire shark to create a baseline
00:05:40
of packets for
00:05:43
comparison more details regarding this
00:05:45
setup each PLC was configured to have an
00:05:48
identical running program which was the
00:05:50
mixing of feeds from two hypothetical
00:05:52
tanks into a third one based on specific
00:05:54
constraints in the tank levels and
00:05:56
draining rates the scan rate of each plc
00:05:59
or how frequently it Cycles through its
00:06:01
program was set at 10 milliseconds the
00:06:04
two PLC parameters that I decided to
00:06:07
investigate in this study in terms of
00:06:08
impact where the scan time and memory
00:06:12
utilization both of which are
00:06:14
recommended for monitoring or logging by
00:06:16
the top 20 secure PLC coding practices
00:06:20
for the s7200 unfortunately memory
00:06:22
utilization couldn't be tracked so only
00:06:25
the scan time was logged on that
00:06:27
PLC the last point I'll mention here is
00:06:30
that no external Communications took
00:06:32
place to and from a PLC during a test
00:06:36
other than with the Gateway for data
00:06:37
logging and with the ntp source for time
00:06:40
synchronization which in this case was
00:06:42
the Cyber
00:06:44
laptop next I'm going to talk about the
00:06:46
measurement Pro process that I utilized
00:06:49
in this study it was actually adopted
00:06:51
and modified from another study
00:06:53
conducted at the University of osberg
00:06:55
which mostly focused on traditional
00:06:57
active scanning the measurement process
00:07:00
consisted of three parts the first part
00:07:02
referred to as the pre-scan involved the
00:07:05
PLC running its program for a defined
00:07:08
period of 3 minutes while data logging
00:07:10
was enabled the scan period was a
00:07:13
continuation of the previous part but
00:07:15
the key difference here is that a tool
00:07:17
had started to scan the
00:07:19
PLC this period was actually not defined
00:07:23
and varied depending on the tool as well
00:07:25
as its interaction with the PLC ranging
00:07:27
from a few milliseconds to a few few
00:07:29
minutes once a tool had completed its
00:07:32
scan the measurement process entered the
00:07:35
post scan period which again was a
00:07:38
defined period of 3 minutes where the
00:07:40
PLC ran while data logging took place so
00:07:43
the pre and post scan periods basically
00:07:46
acted as controls or baselines to
00:07:49
understand the impact of the tool when
00:07:51
it conducted its scan on the PLC finally
00:07:55
every scan by a specific tool on a PLC
00:07:58
was condu conducted in triplicate or
00:08:01
three times to ensure enough data
00:08:03
collection and to demonstrate
00:08:06
repeatability in terms of the tools that
00:08:08
I used in this study as well as their
00:08:10
variations there were nine in total OT
00:08:13
monitoring tools A and B are two vendors
00:08:17
which I chose to keep somewhat
00:08:20
Anonymous somewhat because I'll mention
00:08:23
that OT moning tool a is a vendor in the
00:08:26
tier 2 category of Dale's 2023 OT
00:08:29
detection market analysis while OT
00:08:32
monitoring tool B is a vendor in his
00:08:34
tier one category so the ordering is
00:08:37
flipped I selected both of these tools
00:08:40
to conduct targeted active scanning
00:08:41
which means I would load the appropriate
00:08:43
scanning profile before conducting a
00:08:46
scan the third tool on this list is nmap
00:08:49
but configured to conduct targeted
00:08:51
active scanning as well which means I
00:08:54
would uh run a script that is specific
00:08:57
to a plc's protocol for the compact
00:09:00
Logics that would be the ethernet IP
00:09:01
infos script for the PLC next that would
00:09:04
be the modbus Discover script and with
00:09:06
the S7 it would be the S7 infos script I
00:09:09
wanted to understand how an open- Source
00:09:11
tool performs compared to the two vendor
00:09:14
products which I just mentioned to
00:09:16
investigate the impact of diagnostic
00:09:19
tools on plc's I used Factory talk links
00:09:22
for the compact Logics CODIS for the PLC
00:09:25
next and tia portal for the S7 for all
00:09:28
three Diagnostics tools I basically
00:09:30
simulated some of the day-to-day
00:09:32
activities that an operator conducts
00:09:35
using an engineering
00:09:37
workstation the last three tools on this
00:09:39
list were selected to conduct
00:09:40
traditional active scanning it scanner
00:09:43
is a popular vulnerability scanner which
00:09:45
I chose to keep Anonymous and for this
00:09:47
tool I basically ran an OS
00:09:49
identification scan using its outof thee
00:09:52
boox
00:09:52
configuration here again I wanted to
00:09:55
understand how an open source tool
00:09:56
performs so I used nmap under two
00:09:59
different settings the first was an
00:10:01
aggressive scan using the default sin
00:10:04
scan method while the second was also an
00:10:06
aggressive scan but under the TCP
00:10:09
connect
00:10:11
method so as we're getting into the
00:10:13
results uh there's one more important
00:10:15
topic that I need to cover any
00:10:18
quantitative study that is conducted
00:10:20
without statistical analysis is
00:10:22
typically not worth taking seriously so
00:10:25
for this study it was important for me
00:10:27
to use descriptive and inferential
00:10:29
statistics to make meaningful
00:10:31
conclusions about the results
00:10:33
descriptive statistics as the name
00:10:36
points out allows us to describe the
00:10:38
characteristics of the data set while
00:10:40
inferential statistics takes us a step
00:10:42
further it allows us to make conclusions
00:10:45
or infer predictions about a broader
00:10:47
population using the data set of the
00:10:50
study in this table I've listed the
00:10:53
various tools vertically and the three
00:10:54
plcs horizontally and what I'm showing
00:10:57
is the type of statistical analysis
00:10:59
that was used for each combination for
00:11:02
OT monitoring tools A and B scanning the
00:11:05
compact Logics the duration of the scan
00:11:08
was so short that there weren't enough
00:11:10
data points to conduct inferential
00:11:12
statistics but for all other experiments
00:11:15
both types of analysis were used so
00:11:18
here's an example of how I use
00:11:19
descriptive statistics this is for the U
00:11:23
results of CODIS being used on the PLC
00:11:27
next uh on the y axis I plotted one of
00:11:29
the locked parameters which in this case
00:11:31
is the PLC scan time in micros seconds
00:11:35
you'll notice that the data is
00:11:37
categorized based on the measurement
00:11:39
period so the Box on the far left
00:11:41
represents the distribution of every
00:11:44
data point that was logged During the
00:11:46
prescan period the box next to it is for
00:11:48
the scan period and the one on the right
00:11:50
is for the postscan period this would
00:11:53
then have to be repeated for the second
00:11:55
locked parameter which is memory
00:11:57
utilization to understand understand the
00:11:59
impact of the tool on this PLC we have
00:12:02
to compare the characteristics of these
00:12:04
boxes paying special attention to the
00:12:07
box in the middle so we can compare the
00:12:10
size and the position of the boxes the
00:12:12
position of the median represented by
00:12:14
the middle line the positions of the
00:12:16
upper and lower quartiles of the
00:12:18
distributions represented by the top and
00:12:20
bottom lines of the boxes the length of
00:12:22
the whiskers the outliers and so on when
00:12:25
we do a quick visual inspection of this
00:12:27
diagram we can see that the character
00:12:29
istics of these boxes are very similar
00:12:32
so this diagram indicates no evidence of
00:12:35
an impact on the scan time of the
00:12:39
PLC here's another example of a box plot
00:12:42
but this time the results are quite
00:12:45
different this is for the s7200 when it
00:12:48
was scanned by OT monitoring tool a here
00:12:51
we can see that the middle box has
00:12:53
experienced a major upward shift in
00:12:56
terms of its characteristics the me Ian
00:12:59
has shifted the cor tiles have shifted
00:13:02
the variability is smaller and the plot
00:13:05
as a whole does not overlap with the two
00:13:07
other boxes so this diagram on the other
00:13:10
hand shows strong Visual Evidence of a
00:13:14
negative impact on the scan time of the
00:13:16
PLC when the scan time increases during
00:13:20
the scan period or in other words it
00:13:21
takes the PLC a longer duration to
00:13:24
complete a single cycle we can say that
00:13:27
it experienced a lag or slowdown when it
00:13:30
was scanned by the
00:13:31
tool so these two diagrams were just
00:13:34
examples to illustrate the descriptive
00:13:36
analysis that was conducted to get to
00:13:38
the overview of results which I'm going
00:13:40
to show in a couple of
00:13:43
slides in terms of inferential
00:13:45
statistics I won't cover that in detail
00:13:46
but I'll mention that it was used to
00:13:48
conduct hypothesis testing which means I
00:13:50
analyze the results to determine if the
00:13:53
observations under a specific assumption
00:13:55
were due to random chance or were
00:13:57
statistically significant
00:13:59
in this study I use two types of
00:14:01
hypothesis testing the first is called
00:14:04
The W coxen rank sum test and is used to
00:14:06
detect a shift in one sampled population
00:14:09
compared to the other the second test is
00:14:12
the Bronner munzel test which is
00:14:14
typically used as an alternative to the
00:14:15
previous one and is seen as a bit more
00:14:20
robust Okay so we've arrived at the
00:14:23
overview of results this table here
00:14:26
summarizes the impact of each tool
00:14:29
on the mean scan time of the various
00:14:32
plcs we're focusing only on the scan
00:14:35
time because the experiments of this
00:14:37
study indicated no evidence of an impact
00:14:41
on the memory utilization of any
00:14:44
PLC we'll cover this table uh starting
00:14:48
by each column and we'll go uh we'll
00:14:51
start with the compact Logics for this
00:14:53
PLC regardless of the tool used or the
00:14:56
type of scanning conducted there was no
00:14:58
evidence evidence of an impact on the
00:15:00
scan time for some of the experiments
00:15:03
such as with nmap targeted uh the
00:15:06
diagnostic tool and nmap default there
00:15:09
was a slight shift in the scan time
00:15:12
during the scan period statistically
00:15:15
speaking but using a real world and
00:15:17
conservative lens I concluded that this
00:15:19
impact wasn't
00:15:21
meaningful this actually happened with
00:15:23
the other plcs as well under different
00:15:25
or other tools and I've highlighted all
00:15:27
of those separately using an asteris
00:15:30
for the PLC next the only tool that
00:15:32
showed a negative impact was the nmap
00:15:36
targeted which increased the mean scan
00:15:39
time during the scan period by
00:15:42
5.7% compared to the pre and post scan
00:15:45
periods obviously this is a small jump
00:15:48
but it's worth considering for time
00:15:49
sensitive
00:15:51
applications the biggest surprise was
00:15:53
with the
00:15:54
s7200 under OT monitoring tool a the
00:15:57
mean scan time increased by
00:16:01
55% now this impact might have not
00:16:05
brought down the PLC or crashed it but
00:16:08
it's a major concern for introducing lag
00:16:11
or disruptions in the processes that
00:16:14
would have been dependent on this
00:16:16
device the only other tool that showed a
00:16:18
negative impact on this PLC was the it
00:16:21
scanner which increased the mean scan
00:16:23
Time by
00:16:25
6.1% so
00:16:27
overall it it's probably the deviations
00:16:30
that we're seeing here is not attributed
00:16:33
to a single contributing factor
00:16:35
especially when both traditional and
00:16:38
targeted active scanning seem to have a
00:16:40
negative influence on some of the
00:16:43
plc's in my perspective there's at least
00:16:46
uh a combination of two factors first
00:16:50
the content of the packets sent by a
00:16:52
tool and second how a specific PLC
00:16:55
responds or interacts with those packets
00:16:59
uh unfortunately I can't dive into the
00:17:01
results of each experiment but I'm going
00:17:03
to take the case of the s7200 under OT
00:17:07
monitoring tool a as an example or a
00:17:10
case study for us to
00:17:13
analyze before we do that we first have
00:17:15
to understand how data transfer
00:17:17
typically happens with an s7200 that's
00:17:20
operating under firmware version
00:17:22
2.2 if we had a hypothetical HMI
00:17:25
connecting with this PLC the general s
00:17:29
communication structure has to be
00:17:31
followed so a connection is first
00:17:33
established using a three-way TCP
00:17:35
handshake on Port 102 followed by a cotp
00:17:39
request to establish a connection on the
00:17:41
transport or isol layer once that step
00:17:44
is completed successfully the third step
00:17:47
can kick in which is to request a
00:17:50
connection on the s7c layer or it could
00:17:53
be on the s7c plus layer once that step
00:17:56
is completed the HMI can Pro proceed to
00:17:59
send requests or commands for functions
00:18:03
to the PLC using a Master Slave
00:18:05
communication model now for targeted
00:18:09
active scanning which is using an s7c
00:18:13
scanning profile the relevant request
00:18:16
would be to read the szl of the PLC or
00:18:19
the system status list which basically
00:18:21
contains all the system related
00:18:23
parameters about the PLC including its
00:18:27
module configuration diagnostic
00:18:29
configuration and other
00:18:30
parameters once all the requests have
00:18:33
been sent and the responses have been
00:18:35
received then the connection can be
00:18:37
terminated using a three-way TCP
00:18:41
handshake before we look at OT
00:18:43
monitoring tool a let's examine the
00:18:45
packets from OT monitoring tool B which
00:18:48
we know did not have an impact uh on
00:18:51
this
00:18:52
PLC so tool B follows the first two
00:18:56
steps of the general S7 com structure
00:18:59
successfully I'm not showing that here
00:19:02
because the first packet highlighted in
00:19:04
here in green represents the Third Step
00:19:06
the request to establish a connection on
00:19:09
the s7c layer this step is also
00:19:12
completed successfully and Tool B sends
00:19:15
its first szl read request highlighted
00:19:19
by the first purple
00:19:21
packet if we zoom in on the packet info
00:19:24
hopefully it's readable you can see that
00:19:27
this request has a unique identifier of
00:19:30
001c which is a request typically used
00:19:33
to read all the system components of for
00:19:36
Relevant S7 model in this case the PLC
00:19:39
determines that this request is not
00:19:41
applicable to it and returns an error
00:19:44
code highlighted by the second purple
00:19:47
packet when this happens tool B sends a
00:19:51
new read request with a different unique
00:19:54
ID of
00:19:56
0011 which the PLC respond to
00:19:59
successfully and is highlighted by the
00:20:01
last purple
00:20:02
packet from this point tool B will send
00:20:06
other sdl read requests before it
00:20:08
terminates the connection using a
00:20:10
three-way atcp
00:20:12
handshake so overall what we're seeing
00:20:15
here is that tool B follows the general
00:20:18
S7 Comm structure or the ideal Behavior
00:20:22
very
00:20:24
closely when we look at OT monitoring
00:20:26
tool a however we see a different
00:20:29
story similar to the previous case the
00:20:32
first two steps are followed
00:20:34
successfully again the first packet I'm
00:20:37
highlighting here in green represents
00:20:39
that third step the request to connect
00:20:42
on the s7c layer this again is completed
00:20:45
successfully and Tool a sends its first
00:20:48
szl read request highlighted by the
00:20:50
first purple
00:20:51
packet this time the request has a
00:20:54
different unique ID of 0
00:20:56
d91 which is a request typically used to
00:21:00
read the status information of all the
00:21:02
modules of a relevant S7 model similar
00:21:06
to the previous case the PLC determines
00:21:09
that this request is not applicable to
00:21:11
it and Returns the exact same error code
00:21:15
which we saw in the previous
00:21:18
case but it's really at this point that
00:21:21
we start to see a major difference in
00:21:23
this Tool's Behavior instead of sending
00:21:26
a new read request with a different
00:21:29
unique ID tool a sends a finac packet to
00:21:33
terminate the connection with the PLC
00:21:36
after a few retransmissions the PLC is
00:21:38
overwhelmed and abruptly resets the
00:21:41
connection as highlighted by the red
00:21:43
packet here when this happens tool a
00:21:48
repeats its entire steps from the
00:21:50
beginning but still ends up with the
00:21:53
same
00:21:54
situation interestingly enough in its
00:21:57
third attempt to tool a starts with a
00:22:00
new read request of a different unique
00:22:03
ID and is able to follow the same steps
00:22:06
that we saw with tool
00:22:09
B now I can't explain why this happened
00:22:14
in the first place and I would love to
00:22:17
get the opinion and input from other
00:22:19
people but I believe that this Behavior
00:22:22
we're seeing here can explain the lag or
00:22:25
slowdown that this PLC experienced when
00:22:28
it was scanned by Tool
00:22:32
a so before we get to the
00:22:35
recommendations of this study based on
00:22:37
this case study and uh our results I
00:22:40
have to make a couple of uh important
00:22:42
disclaimers first and foremost although
00:22:45
my messaging might have been a bit
00:22:48
critical um I want to make it clear I
00:22:52
believe targeted active scanning is
00:22:54
extremely important and many
00:22:57
organizations need it because passive
00:22:59
detection alone is not
00:23:03
enough and the second point is this
00:23:06
study obviously belt dealt with just a
00:23:09
tiny fraction of all the PLC models that
00:23:12
are out there and the testing conditions
00:23:15
couldn't capture the complexities of a
00:23:17
production
00:23:18
environment regardless I think there are
00:23:21
some key takeaways here for both asset
00:23:24
owners and OT monitoring vendors we'll
00:23:27
start off with the asset
00:23:30
owners typically the only type of
00:23:33
scanning that will make sense for your
00:23:34
OT devices is going to be targeted
00:23:36
active scanning in terms of added
00:23:39
visibility if we extrapolate the results
00:23:43
of this study we can assume that some of
00:23:46
your PLC models are going to experience
00:23:49
a lag or a Slowdown when scanned by some
00:23:51
tools although I don't have a magic
00:23:54
formula or predictor that can determine
00:23:57
the extent of it it but other plcs might
00:24:01
not be affected at all to take a
00:24:04
conservative approach I would recommend
00:24:06
that Legacy plc's and plcs being used
00:24:10
for time sensitive applications should
00:24:12
not be scanned during production unless
00:24:15
they have been previously and thoroughly
00:24:17
tested the safe path would be to scan
00:24:20
those devices during your downtime
00:24:22
window other plcs that don't fit in that
00:24:26
category can and probably should be
00:24:29
scanned at regular intervals although I
00:24:32
would still highly recommend to monitor
00:24:35
their parameters and look for Network
00:24:38
abnormalities finally I encourage you to
00:24:40
work with OT monitoring vendors to
00:24:43
validate the impact of their scanning
00:24:45
technology on your specific plc's and
00:24:48
this is something that you can do while
00:24:50
selecting a tool implementing a tool or
00:24:53
even after
00:24:56
that and now for our OT monitoring
00:24:59
vendors as we saw today it's extremely
00:25:03
important to have testing methodologies
00:25:05
that validate the impact of scanning on
00:25:09
plc's this is something you can
00:25:10
Implement when you're developing a new
00:25:12
scanning profile or testing an existing
00:25:16
profile for
00:25:18
compatibilities the other idea I was
00:25:20
recently thinking about I'm not sure if
00:25:22
it's Mak sense or maybe it's already out
00:25:25
there but why not have some sort of a
00:25:27
mechanism in the tool so when these
00:25:29
error codes are received instead of the
00:25:32
tool continuing with the scan it
00:25:35
terminates it to not induce further
00:25:37
negative impact and I believe that sort
00:25:40
of mechanism may have helped or would
00:25:43
have helped the case study that we saw
00:25:45
as well as the uh other experiments that
00:25:47
we didn't dive
00:25:49
into and finally if you already have
00:25:53
similar testing methodologies or you
00:25:55
plan on adopting these in the future
00:25:58
here I would encourage you once again to
00:26:01
please share the results with the
00:26:02
community because by working with each
00:26:04
other we can advance the adoption of
00:26:06
this technology but we can also provide
00:26:09
asset owners with the data and the means
00:26:12
to make informed
00:26:15
decisions so with that thank you for
00:26:18
your attention and the floor is open for
00:26:20
questions great presentation thank you
00:26:23
um I'm just curious if if you have any
00:26:24
hypothesis on that impact scan time on
00:26:27
the 1200
00:26:29
whether you know that was a result of an
00:26:31
error and it took extra processing time
00:26:33
to handle it or if maybe that was
00:26:35
related like what would happen if for
00:26:37
example an the PLC next had an error
00:26:39
would you see a particular scan time
00:26:41
increase I'm just just curious if any
00:26:43
hypothesis in that uh so if I understand
00:26:47
corre correctly Sean you're saying if
00:26:49
the um the improper handling was were
00:26:53
you asking if it's on the PLC side or on
00:26:55
the tool side on the on the PLC side
00:26:59
right uh so from my perspective I don't
00:27:02
think it's from the PLC side uh the
00:27:07
error code itself was similar obviously
00:27:11
it could be when you're um targeting a
00:27:15
specific uh configuration or ID it might
00:27:18
cause uh other changes uh to the PLC but
00:27:22
I believe it's uh improper handling on
00:27:24
the on the on the tool side itself uh
00:27:27
when it um especially since it repeated
00:27:31
its entire steps uh and terminated the
00:27:34
connection for whatever reason uh that's
00:27:37
that's what I would sus suspect okay
00:27:39
thank you I have another question on the
00:27:42
left side on the
00:27:44
other go on hey Ralph thank you so much
00:27:47
for taking the time to put all that
00:27:48
together couple simple questions how
00:27:50
long did it take to do all the study and
00:27:51
the research and to put all the metrics
00:27:53
together in the data uh I I started
00:27:56
thinking about this about a year year
00:27:58
ago uh like putting the thought or
00:28:02
design behind it uh but the actual
00:28:06
execution I would say around six months
00:28:09
uh yeah so yeah that seems like a lot of
00:28:13
work um the I love how you check the
00:28:15
three minutes before the scanning and
00:28:16
the three minutes after did any of the
00:28:18
after or any validation or checks go to
00:28:21
functionality I've scanned some devices
00:28:22
in the past and I've I've scanned a
00:28:24
device I've gotten good results back I
00:28:26
think everything's okay in an hour or
00:28:27
two later I'll have an operator ask hey
00:28:30
this device isn't responding or it's not
00:28:32
functioning properly it looks like it's
00:28:33
functioning prop when you start to
00:28:34
interact with it that's when you notice
00:28:36
something isn't functioning was there
00:28:37
any validation of controls or
00:28:39
functionality or did you see any of that
00:28:40
in the packets afterwards I think that's
00:28:43
a good uh question and idea in terms of
00:28:46
functionality itself I I didn't do any
00:28:50
validations I guess my indicator uh was
00:28:54
looking at the scan time I can uh tell
00:28:57
you
00:28:58
um well and memory utilization but
00:29:00
that's not that relevant uh in this case
00:29:03
based on what we saw uh but uh I can
00:29:05
tell you during the post scan there was
00:29:09
no statistically speaking and even when
00:29:11
you look at it from a real world lens
00:29:13
there was no difference between the
00:29:15
prescan and the post scan so they both
00:29:18
of those acted as baselines and most of
00:29:20
the validation was more from a network
00:29:22
perspective but it's it's worth looking
00:29:24
at the no that sounds fair the last
00:29:26
question for you would be is so we scan
00:29:28
a device with like an nmap for example
00:29:30
when we scan that we're we are scanning
00:29:32
it we're interrogating we're saying like
00:29:34
hey is this port open we're expecting it
00:29:35
to respond to us the one asking the
00:29:38
question right and we do that
00:29:40
65,535 times right over and over again
00:29:42
when we're scanning an OT device or we
00:29:44
say an OT scan with some of those
00:29:45
vendors that you mentioned we're not
00:29:47
typically doing the same thing right
00:29:48
we're we're sending like a mod bus
00:29:50
packet that says like what is your name
00:29:52
or what is your firmware and the device
00:29:54
is responding with that information in
00:29:57
the wire and then the vendor is
00:29:58
typically listening to the wire is a
00:30:00
different approach right to the end Maps
00:30:02
or the it or are they the same or have
00:30:04
you seen similar actions with your
00:30:05
testing in synopsis like when you scan
00:30:07
with nmap we're telling the device is
00:30:10
the port open and we're we're expecting
00:30:12
a response to us when we typically use
00:30:14
like an OT vendor tool at least in my
00:30:16
experience we're we're not asking it a
00:30:18
question and expecting a response to us
00:30:19
we're asking it hey what's your firmware
00:30:21
and it and it publishes that it
00:30:23
broadcasts that information inside the
00:30:26
packets and then the OT vendor is
00:30:28
sniffing or looking at that so slightly
00:30:30
different than than I what I understood
00:30:31
would be an N map did did you see
00:30:33
similar or or was that scanning the same
00:30:35
for you uh between nmap targeted and the
00:30:38
OT monitoring V vendors the uh packet
00:30:42
structures were comparable were're very
00:30:44
similar but yeah with like an nmap
00:30:46
aggressive or the it scanner then those
00:30:49
are substantially different uh and even
00:30:51
the diagnostic tools like the
00:30:53
interactions that I was doing was also
00:30:56
um not really compared arble uh in terms
00:30:59
of the what the OT monitoring tools send
00:31:04
uh but I suspect if I would capture that
00:31:06
traffic and feed it to a tool uh it
00:31:09
would uh potentially provide visibility
00:31:12
that may be similar to targeted Act of
00:31:15
scanning not sure if that answers your
00:31:17
question very well thank you so much
00:31:19
Rafael thank you we still have um one
00:31:22
last question that we want to to ask on
00:31:25
yeah hi R uh thank you for a good
00:31:29
presentation I like that um the question
00:31:31
is uh when you're talking about the S7
00:31:34
1200 and the new top type off uh down to
00:31:39
the part of the low end from seens uh
00:31:42
have you looked into to compare with
00:31:45
with the larger stacks and and devices
00:31:48
from cement and how that will uh the
00:31:50
same results you got here and compare it
00:31:53
with uh plcs and with larger processing
00:31:58
capacities and yeah uh are you asking me
00:32:02
if I've I've looked at larger capacity
00:32:05
yeah have I looked at it and also
00:32:06
testing it have you oh
00:32:08
no the scope of this study based on like
00:32:12
the plcs I was able to obtain we limited
00:32:15
to these three uh but it would be
00:32:17
interesting to look at something like
00:32:19
the
00:32:20
s7500 um and maybe see different
00:32:23
Behavior or maybe more comparable with
00:32:26
the compact Logics um this 5370 at least
00:32:30
but yeah okay um I I'll stop there I'll
00:32:33
stop there it's all the time okay thank
00:32:36
you so much talk to you afterwards thank
00:32:39
you so much Rafael thank you
![How to Shoot Day for Night in Camera [BMPCC 6K]](https://ruhnrawpgxrzdrgaohnf.supabase.co/storage/v1/object/public/images/video/26x1KvkQdB8/thumbnail.jpg)
