so hello everyone i'm sarah and i'm one
of the
co-organizers of the top 20 secure plc
coding practices project
and vivek ponata my co-organizer and i
will give you an introduction
to our project today and why it's
important and
to why we did it and how we did it
well the secure coding practice project
project is about
writing secure coding practices for
plc's
so for programmable logic logic
controllers
and it actually was sparked or inspired
by
jake brodsky who gave a presentation at
s4
in 2020 in miami and the presentation
was on secure plc programming
obviously and on a few hints and tips
and tricks
how someone who's been working in the
field for a lot of years uh
programs of pse to be more reliable more
um and and more secure in the end
the video is available on youtube and
it's become a classic by now
and after this talk um
a couple of people came together and
said well we need to make something out
of it
because one of jake's main statements
was
secure plc programming really no one
knows this at school and what he meant
was that the engineers
who program plc's do not learn anything
about security at school
first but then also they don't learn
anything about
how to securely program a psc at school
and the simple reason for this is was
that
there is nothing to teach because unlike
for normal i.t software where we have a
lot of
secure practices coding principles
secure coding practices
published by microsoft published by
universities
that are normal to learn for programmers
for prc there is nothing you could teach
there are no
secure prc program practice programming
practices
and after that talk a couple of people
said okay let's change that different by
dave peterson who's organizing s4
we said okay let's create something from
a community
from engineers for engineers
and let's try to define how to securely
program
a plc and the reason why it was
important
was pretty obvious because we all knew
for at least a decade
maybe even longer that plc's
are vulnerable there was a a project at
a sport called project base camp
uh about a decade ago showing plc
vulnerabilities and a lot of things have
followed
for virtually all plc vendors their
plc's are are insecure by design and
that's
not always used to be a bad thing
because somehow
some parts of these psc vulnerabilities
are actually plc
features they just haven't been uh built
and programmed with security in mind so
it's no
no surprise that they're vulnerable and
all these
um advisories and all these news that
there are new variables found in plcs
keep coming
leaving engineers more or less
in despair or at least with nowhere to
start because
all these vulnerabilities keep coming
but we don't really
develop things a a so what so we develop
ideas how to fix certain vulnerability
we don't really develop something
to make plcs more secure in general
so there are so many problems we all
know prcs are somehow
the hills here of a plant one of the
most vulnerable part of a plant
and we don't really have anything in our
hands that can hand over to engineers
and say well
if you do it like this it even gets it
gets better at least it doesn't get
worse
and you don't build in all these
vulnerabilities
so and there's one big argument
um or one big understanding in the
industry saying
well pcs and security that just
doesn't fit you know plc's they
they are just not made for security
they're insecure by design
and so many of these standard well-known
secure coding practices that we know for
other software
that's not even applicable to psc's we
don't know how to do that for plc's
and there's very much truth in it
because it doesn't really doesn't make
sense to simply take the secure
programming practices
you see from it and try to
try to implement them on on a pse the
same way that that won't work
uh it's the same way if you able to ask
ask a fish
to climb a tree the same way that the
monkey does just not made for it
it doesn't make much sense for it to
climb a tree at all
but that doesn't really mean that plc's
are not made for security after all
they just need to um you just need to
rethink uh
how to achieve security for plc's using
its characteristics
because a plc um you would even say
or some people would say many it people
would say well plc is just too dumb
for security and i can understand where
that comes from because in a way a plc
is dumb
um in a way you could describe
everything that a pc does with well
you have one job or to be
a bit more fair you had four jobs but
that's it so a plc has a recurring scan
cycle
that it does over and over again so it
reads inputs
from a sensor so in this example here
we've got a fluid level sensor so it
reads
where the fluid is maybe water or oil or
anything
and it reads that input from an input
through an input interface
processes it and it's in the cpu and
stores its memory and then it loads
a program from memory and executes the
logic it loads and the logic looks way
different than it would look in a normal
computer program and then it maybe
communicates with some kind of external
component like an
hmi or a programming laptop and then
it writes output so if the level uh the
fluid level here is too low it might say
well start the pump and pop some fluid
in there
and all these four steps it repeats
endlessly that's the scan cycle
and does it always the same way and
always in the same time
and that's it so a plc has certain
characteristics
um it's a process expert it really
communicates directly to the process
directly with process
it knows what the process is about it
doesn't have to do
a lot of fancy anomaly analysis because
it's own job it's it's very job and its
only job is to know about the process
and to
keep track of certain process values and
keep them
keep them on track and yes it's true a
plc mostly has limited resources
because it has a very designated task
and that doesn't change much
and you don't need all the resources in
the world for it
but instead it's very important that
it's reliable
so that you know if you if you give it a
value
and after a certain time there is an
output
and you you can it can absolutely
guarantee
that that output comes within a certain
time that that's what we call
uh real it's real time capable so the
pump
absolutely relies on the pse giving it
the output it needs to be deterministic
so
when you put something in an input in it
always returns the same
output and all i see people know that
that's totally not normal
in for normal devices and for ethernet
networks
so a psc really is not dump it's just
different
it has one job four jobs and is really
really well at doing these jobs
and this is the setup that we need to
live with and that we need to
accept and that we need to look for
strength
that we can use for security benefits
so what we wondered at the beginning of
our project was
what does it mean after all to securely
program a plc
we all know security is important and we
all know that plc's are vulnerable and
we want to make them more secure
but what does a securely program
program plc mean and what is a secure
plc
so these were the two leading questions
that we tried to answer
with the top 20 secure coding practices
list or at least
we try to give a first basis for
discussion
for these questions um i'll give you a
short introduction of
how this list looks and what how it's
structured and what our assumptions were
and then we will give you a deep dive
into a couple of practices
to give you a better feeling so the top
20 list
if you download it you can go to the
project website we show that at the end
um you can download it for free it has
the most permissive license so you can
virtually do
anything with it we want it to spread we
want to spread to engineers
anyway if you download
and they all have a title they all have
a short description and they have a
number and that's it
and the number that's important to note
is not a ranking
so a practice with number one is not
more important
or or anything than the practice with
number 20.
and then if you keep on reading there's
about 40 more pages with details on all
the secure coding practices
so here is a an example um on what the
details look like and the example
practice we're taking here is validate
inputs based on physical plausibility
which is one of my favorite practices to
explain because it
really is a practice that uses the
characteristics
the superpowers that naturally come to a
psc that appears he's really good at
like fishes at swimming and
that's of course because the plc as we
said as a process expert it's really
good at knowing
what values what process values are
normal
and are good and are acceptable
so if you for example have a gate
and the gate takes a certain time to
open physically it always takes five
seconds until it's open because it
physically can't be done more quickly
and the plc gets a value from a sensor
which says where gate is closed but it's
only half a second
since since it asked just since the gate
starts to close then the plc knows
something is wrong or at least can know
something is wrong you can ask a poc
about that
so that is something that you can use
to validate uh plc inputs and that's
something
very unusual because it's not something
how it could validate an input for a
normal software because normal software
usually doesn't have physical
inputs or physical outputs but the plc
does
so there are things where you really
don't need a fancy security monitoring
tool
and you don't need a ki by
ai based anomaly detection or anything
but you just need
a plc whose job it is to know the
process
and for this practice we've got the
title we've got the short description
that basically summarizes what i just
said
and then for each practice we have a
security objective
and that summarizes in a quickly in a
quick way
as a tag if you so well
what the main security objective is that
practice fulfills and that could be
either integrity
a lot of times it's integrity for pse of
psc logic
of i o values or of pse variables in
this case it's integrity of i o values
but it could also be something hardening
or resilience or monitoring
look at that at a minute and then
we also define target group because not
all practices
can be implemented by the same tag group
we use
the isa 62 443 tag groups you may know
them it's product suppliers
it's integration and maintenance service
providers and its asset owners
and truth is that a lot of practices
always depending on who programs the
plcs of course but
a lot of practices cannot really be
integrated be implemented by asset
owners because a lot of
um especially low level programming
happens at
product suppliers in the integration of
maintenance service providers side
and then we've got a section called
guidance where really
everything goes into that helps
implementing the practices
b is screenshots um be it cooking
recipes for
for different makes or models of pfcs be
it background information that you need
to know in order to implement the
practice
whatever goes into the guidance
and then we've got a section called
examples which
can be implementation scenarios or it
can be scenario examples for certain
industries or products
or it can also be examples of what could
happen if
a practice is not implemented which is
important to understand the security
benefit
talking of security benefit that's
another very important sections we have
in our for each of
our plc programming practices um
and these sections involve the y section
so why is this programming practice
important
and of course it's secure pse
programming practices
so it's actually
all of these practices are beneficial
for security obviously
but then also many of these practices
and that's a very important point to
make so let that sink in
a lot of these practices also have
benefits for reliability
and they also have practice benefits for
maintenance for example
if you take this example here so
um validating inputs based on physical
plausibility of course that's good
because it can validate
um if an attica has uh manipulated value
tempered with a sensor or anything so
that's that's that's good you can give
an alert
but you can also use that validation for
reliability purposes so
if something doesn't work if some
something may be broken mechanically
um the same the same feature can
can give you a hint that something like
this is wrong so that is
things where um that statement that we
often read
that there's always trade-off between
security and comfort between security
and operability
uh between security and usability
between security and operations
that there's always a trade-off that's
actually
not always true at least for the secure
prc coding practices
that's actually not the case for every
single practice that we have here
we've got not only a security benefit
but also
a benefit unfortunate realm of
operations
and that's very important point to make
because
that's often the case in in ot because
security uh with having processes and
having
pse characteristics in mind is often
about
reducing complexity it's often about
better monitoring it's often about
better structuring of code it's often
about
better documentation and all these
things are actually things
that mostly do not stand in the way
of usability like long passwords would
do
but they really help operations
last we also have references uh we have
references to existing standards and
frameworks and that could be for two
courses
so first we we reference attacks or
weaknesses or vulnerabilities
that a certain practice could prevent
that would be
mitre attack or mitral cwe in these
cases here
and we could we do we also reference
security requirements
that the practice under consideration
could help to fulfill
and these are in these cases here isa 62
for three requirements
and that could be extended of course
small look at the security objective um
what can we expect from a security
program plc and what can't we expect
looking at the objectives we see a
pretty clear
structure here so we see that most of
our 20
secure programming practices have
integrity benefits
and that's actually not a surprise
because what a plc does is
making sure that values process values
io values
stay on track and the most important
thing that you could
imagine the most important threat
scenario you could imagine doing to a
psc of course is
tampering with its integrity and then
the other part would be monitoring
because as we said before
a big issue with prcs and the big
benefit of prcs is
that they are process experts they know
about the process so much better than
all your fancy security tools can learn
in a long time so for some cases for
some monitoring purposes
pfcs can actually do a kind of work and
also they can help with resilience and
hardening
if you have a few practices for these
one very important point to make is uh
securely programming a prc
is most likely not the first step you
would take
in a security program it's not the most
important
and of course no these practices would
not have prevented stuxnet at least not
alone
um but it's simply and that's the the
whole goal of all this turning a pse
which or which has always been one of
the most vulnerable components in a
plant
the the oculus here in a plant turn
these
vulnerable components at least to one
more layer of security to a last line of
defense
that stands like bodyguard in front of
your
most important processes in a plant
last two questions that we often hear
when we talk about prc secure coding
practices
is why is a certain practice
not on the list and the most important
answer the most popular
answer is probably because it's not in
scope because
uh we got a this was a humidity
community project we had about 900
people
registered on a discourse platform who
collaborated
on on this and who
submitted potential plc coding practices
and we had to limit the scope at some
point we had to make sure
that our top 20 sql plc coding practices
actually kept the coding practices
so we have the scope that's that's lined
out here
everything is the scope anything that
includes changes to the prc itself
so this one here what's not in scope is
and that's a potential second scope that
we could be doing
um as top 20 secure plc environment
practices as a working title so
everything that involves architecture
that involves hmi
programming and device or io
requirements or documentation
could be on a second list second
question
that we get a lot of times is why is
this practice on the list at all it's so
basic but there are actually three cases
why someone would say it's so basic
first is a security person says that
the prc super practice is really too
basic for security people everyone knows
about that
but a simple answer why it's on the list
anyway is because security people don't
program plc's it doesn't help if
security people know about it
plc programmers need to know about it
and that's the target group of our list
and also security people may know about
this practice but do they know about how
about its implementation on a plc the
quiet requirement may be basic but not
its implementation
and then we also wanted to do something
against the myth
that security practices are simple
but plcs are simply to dump to implement
them
that is true for some practices but it's
not true for others and we want to put
the practices explicitly
explicitly on the list that can be
implemented on a pc
so that's the first one the second is
pse programmers say
well that's so basic it's that
this i've been doing that for years
every plc programmer knows about that
and that may be true they maybe
they they maybe know that it's a good
practice but they they may not know
it in fact has a security benefit and
then they also should do it because for
security reasons
and that becomes important first when
you want to talk about what a secure plc
is of course
but also it becomes important because it
adds one more reason
why you should do a certain practice so
if you decide not to do it because
it's just for efficiency reasons and
efficiency is not as important
it's important that plc programmers know
that this practice they may be leaving
out
also has security benefits and they
on the other hand on the other way
around they also have a
security problem if they don't implement
them
and then lastly there are practices
just say well it's it's basic because
everyone knows and everyone has been
doing this for years anyway
well if anyone everyone has been doing a
certain practice in order to securely
program plc's
for years i hope we can
we can agree that it absolutely belongs
on a top 20 secure psc coding list so
that's why it's on there
and also there's always rookies there's
always newbies there's always new people
that do not fall under everyone and they
don't do not know
and i want to remind you of our
true leading questions that i mentioned
in the beginning
which were we want to answer we want to
put up a list which which defines
what it means to secure the program plc
and we want to have a list
that answers the questions what is
secure psc so we want to be basic be
basic is really one of our lists
purposes
so now that we've answered most of your
questions hopefully that arise that
could arise while looking at that list
and you have a small i have an idea of
what it's all about i hope you're ready
i'm hoping you're ready for
the deep dive into a couple of questions
practices
that we've actually introduced to you
now be backstage is yours
hey ics village folks at defcon hope you
are enjoying the conference so far
i'm here with sarah flutes to talk about
secure coding practices for plc's
a little bit about me viveknada
after 23 plus years experience in
industrial control systems
i've been doing ics ot cyber security
for the past eight plus years
my background is electronics and
communications engineering
i have an mba in finance and the gicsp
search from sans
i started off as a controls and
instrumentation technician
calibrated valves transmitters
configuring plcs
i became a field engineer commissioned
gas turbines and steam turbines control
systems
around the world for utilities and oil
and gas customers
then went back to business school after
that became a sales and business
development manager
and currently i serve as a service
manager for canada fleet
my company covering all utility and oil
and gas customers
within canada and i've worked in several
countries
my contact information is below or
linkedin and twitter
all right now that sarah's giving you
the background
let's take a deep dive into a few
practices to learn more
let's pick something straightforward for
our first one
practice 13 says disable unneeded
unused communication force and protocols
so the controllers that we are used to
generally support
multiple communication protocols because
they are used in various applications
now most of these protocols are
unfortunately
enabled by default even if you're not
using them
as an example telnet or ftp you have to
actively go disable them
if you're not using them now the best
practice recommendation
is to develop a data flow diagram that
clearly shows all the required
communications
what ports are required to be open and
how the logical network segmentation is
what protocols are used so that it's
clear
as to why certain ports and protocols
are in use and why the others aren't
now every additional port every
additional protocol that's enabled
adds to the plc's attack surface and
the attackers can't use if a certain
port is disabled or a protocol is
disabled
and you can typically alert for
something that's being enabled
or perhaps you need to download to the
controller to re-enable the port
or the enable that particular protocol
so that gives you
ways to find out that something is going
on right
in addition perhaps you have a network
sensor or firewall
that can detect if a particular protocol
is in use
and if you have previously disabled that
you can
get a sensor that way but even natively
there are ways to find out if a certain
disabled protocol or report is enabled
now following this practice of disabling
unused
force and protocols you can also reduce
the potential for
malformed traffic to affect the plc
so most plc's don't
really do well when there is a
malfunction
and if a particular protocol is not in
use any malformed
traffic from a malicious actor
for on that protocol is not going to
affect the plc
now following the practice also reduces
the overall complexity because
what's not there what's not enabled is
not necessary to be maintained and
mastered updated
these days you hear a lot about s-bombs
software with the materials
the idea being vulnerability is found in
the network stack
from your vendor go investigate and find
out
if it's a relevant threat for your
application
and then follow the mitigation path
however
if those force of protocols are not in
use
that just reduces the attack surface and
you are at a lower risk
next step is practice five again another
pretty straightforward one
using cryptographic checks or check some
integrity checks for the plc code
now some plcs have a built-in mechanism
for a checksum feature
and if that's available by all means
write that to register
log it asterize it alarm or alert it
when it's changed
so you can verify the integrity of the
code in the plc
pretty much pretty much straightforward
manner now
most plcs do not have the processing
capacity to generate or check hashes
in that case you can use ews the
engineering workstation
to generate the hash or checksum of the
compile software
and then you upload the binary back from
the plc you can compare that with that
in the ews
that way verify the integrity
now knowing if the plc code was tampered
with is essential for
a few things so number one it will help
you notice
the compromise so if the integrity of
the code
is suspect compare and find out that
what's in the plc is not what you
expected to be that you know you've been
compromised
also after compromise
the file that you have the environment
that you have that you verify
uh with this cross check can then help
you understand
if plc safe to operate after a potential
compromise because you can download that
binary that you know is good
and then done with it and then finally
it's also a means to verify the plc
still running the code approved by the
integrator or the manufacturer
because sometimes that's necessary for
warranty purposes
or perhaps for compliance where you have
to run a particular version of code
and you can confirm by using this
integrity check
going a little bit deeper into some of
the more
interesting ones leave operational logic
in the plc
wherever feasible practice three so
on the right side you see the hmi here
plc here this practice says you know
don't put a lot of code in the hdmi here
but put all the operational code in the
plc
so the operator visualization software
in the hdmi
these days has a lot of coding
capability
initially it was to add a few alarms ad
hoc
maybe change some limits for those
alarms or
give some lower level access to an
operator
to get some kind of code in there
without necessarily touching the plc or
download the controller
however over time some programmers
started
utilizing hmi code because it's just
easy to work with sometimes
however calculating values like
totalizers
if you do that in the hmi versus doing
the plc
uh it's going to be a lot more accurate
than the plc because
uh plc is much closer to the field the i
o is connected to dlc
the latency in communication between the
hmi and the plc
that's a big deal because the hmi is
typically pulling once per second
or every other second or as needed so
if the hmi is not getting enough updates
it's not in a good position to do a
totalizer or a timer
uh based on you know what the plc can do
versus hmi
and then the hdmi usually
deputing in hmi shouldn't cause any
process
upset shouldn't affect the plc operation
however if you use the hdmi for these
datas or updates or values or totalizers
and that's a problem because if you
remove the hmi those gets reset
similarly uh if you're doing a windows
patch or if you're taking a backup
that periods of availability or
unavailability of the hmi
might affect those values which you do
not want
so anything safety or protection layered
is better off
being held by the plc as an example
enable or disable actions i've seen
rare operator clicks on enable button
and that click is shown visualized
to the operator as if the action is
being performed and then the
command is sent to the plc however
what if the plc cannot execute that
command
what if the plc has some force items
that is stopping it from executing it
those are not visible to the operator
because this code is
in the hui similarly uh
if you have a time delay for a motor
restart and you should put that in the
hmi code
what if because of coms issues or any
other problems
uh the hmi cannot calculate the timer
properly that
it's not a safe situation for the order
to restart or not to
start when you wanted to
four signals they're typically visible
only in the plc and not in the hdmi
so you can't really put some safeguards
in the hmi code
as much as you can in the plc
similarly inconsistent visualization or
status
when the hmi values are not populated
back to the plc
so if you configure something new some
new points
some new alarms but they're not
represented in the plc
then you have some inconsistency and
also the plc doesn't know that these
other things exist
and then finally consistency in code
maintenance
audit and change management because you
split the code into two different places
these become difficult furthermore
if you unify your code in the plc you're
reducing the attack surface
you all can imagine more scenarios where
the hmi
is uh open to more public facing maybe
internet and someone is able to access
and move the mouse around
we've seen that for example in the
florida
water situation where they were able to
even
enter some values um much higher than
what the water should contain
those kind of attack scenarios you all
can imagine
in the hmi level however if the code is
in the plc then there's a lot less risk
because
the third actor needs to be a lot more
sophisticated a lot more focused on
preceding the attack versus randomly
moving the mouse around
and enabling disabling anything that
they can see
next up is practice 11 which is
instrument for possibility checks
now i've given an example here for you
all to kind of imagine
some of the examples i'm going to talk
about we have a couple of tanks
some pumps and some instruments here
so this practice is about comparing
integrated and time independent
measurements
to confirm if the measurement that
you're seeing
is accurate for example a meter pump and
tank level
the volumetric change in the time should
equal
or be proportional to the integrated
flow
if it's not then you raise an alert
similarly burner in a boiler
the added caloric heat from the fuel
should
equal or be proportional to the
temperature increase
and if it's not you raise an alert
the idea being compare different
measurement sources
so measuring for example the same
phenomena different ways
another example a compressor stall is
typically
visualized by a reversal of flow however
it will also have increased vibration
so those two are measuring the same
phenomenon in different ways
and also not necessarily different
sensors but maybe the same value coming
from two different communication
channels
maybe that plc has a back brain
communication and the markers out
to the dcs and then also 40 20 milliamps
to uh the dcs or some other equipment
where you can compare
and if it so happens that whoever is
manipulated
one did not leave the other you will get
an alert that something is wrong
so the idea behind this practice is to
facilitate monitoring for
manipulative values as long as not all
sensors are needed at the same time
just another level a layer of protection
uh
in a plc with existed before
now it also prevents acceptance or
identifies wrong measurements like we
talked about before
uh the tank level suddenly shows much
higher than
what it should be in correlation with
the volumetric or the
flow coming from the flow meter then you
can identify that some measurement is
wrong
also able to rule out the physical
causes for failures more quickly if you
do believe that tank level for example
you might think that
this particular valve has failed uh
however if you're comparing that with
flow you kind of know that the value is
okay because
you know based on that flow you could
not have have this level
for example
all right next up is practice seven
which is validate an alert for paired
inputs
and outputs now paired inputs and
outputs of those that are physically
not able to happen at the same time for
example a motor could be
running or not running so it could be
started it could be stopped but
not both at the same time similarly a
conveyor belt could be
forward or reverse not both at the same
time
and of course the valve could be open or
closed
but not both at the same time so the
pair signals cannot be asserted at the
same time
unless there is a failure for example
uh there's open limits which is working
fine but the close limits each field
also shows close uh so that's an
instrument failure
or a malicious activity where someone is
trying to force a bunch of things
and they also have to force both the
open and close
uh or also the clones when those
actually open
now some additional recommendations as
part of this practice
is to configure start and stop has
distinct outputs
as long as the mcc is capable of
receiving
receiving those outputs instead of a
single output that can be toggled on and
off
because it's way more complicated to
rapidly toggle
two distinct outputs especially if
they're pretty set a certain way
it's very difficult in the plc versus
just one out
that you can switch on and off
and then also consider adding a timer or
restart after
stop is issued this again helps in
avoiding rapid targeting of the start
stop signals
whether due to errors or bad intent
and finally uh let's take a look at
practice 16
which is summarize plc cycle times and
turn them on the hmi
so cycle time is the time it takes to
compute each iteration of the logic from
plc and these cycle times should be
fairly constant in the plc
unless there are changes to that
environment or the plc logic
or the process as an example here
you see um the time over here and then
the cycle times
so the expected fluctuation
a little bit here but then every so
often you get the spike which
could be malicious code now unusual
cycle time changes can be an indicator
that the plc logic has changed has been
added
visualizing these values over time draws
attention to these anomalies
because let's say you have a threshold
somewhere here none of these
trigger of it but visualizing it this
way
this manner can help you understand that
something is going on
so many plcs have this maximum cycle
time monitoring at the hardware level
so in this graph the number of cycles at
the time for the cycle
so if it exceeds a maximum value
usually the cpu issues a stop so at this
tmax
is number five uh the cpu would stop
so attackers will know this so they
typically don't add code that much they
typically keep their code so that you
never reach that threshold
however if you happen to create these
boundaries have
these acceptable thresholds so one and
three would be okay
but anything about would be alerted uh
this would be based on the application
the process engineers
understanding of the process and the plc
controls engineer
working with the process engineer
defined these thresholds
but the idea being about these
thresholds uh if you have some
uh alerts then if and when some
malicious traffic
once you scroll and plc uh cycle time is
higher
than what it should be you get over it
all right now i headed over to sarah to
talk further
about what the expectations are on the
project
so yeah that's me again and
actually um my last words are about
the outlook what what do we have to
what what do we do we do with this
project in the future because obviously
we're not done yet uh we've worked on
this for about a year
um we put our first document out and we
don't have got a lot of things that we
that we need to do and the important
thing to know is
there's a core team um that meets every
couple of weeks um and that has a few
things on its to-do list
so one is we are thinking about doing
top 20 secure plc environment practices
for example we're thinking about
building a playground so building
virtual
prc's where you can try out practices
virtually
where there are demonstrators that could
download or try out online
of course we're thinking about improving
the practices
or publishing a version 2.0 based on
comments that come in if you go to our
website that i'll show you in a minute
you can download the comment form and
leave us any comment you want and
they're really all welcome
and we want to improve these practices
comments can be
this practice doesn't make sense it can
be i implemented this and this could be
a good example
it can be i don't understand this uh we
could explain that better this way
or it can be i've got a completely new
practice that needs to be on that list
that i want to propose we've got a
template for that
we're also working on translations to
other languages because
obviously we want engineers to adopt
that list
and the easiest way to adopt something
that is
in your languages in your language it's
just just way easier
and we're also thinking about training
template for
prc coding practices how to involve them
in purchasing specifications because
that's one
easy application that could be a lot of
use for
for users for asset owners
and that's the core team we've got
commenters so
i said that before uh everyone is is
really invited to comment it's not a lot
of work and we're looking forward to
talking about your comments um we've got
supporters who build trainings
who write articles and podcasts and uh
we're thinking about collaborations
which is a an important part so we are
collaborating with mitre cwe in order to
maybe
um put a module for plc's
in cwe because it doesn't have something
like this not
yet but we really really really and
that's one of the most important points
that i want to make in the end
we we want to get this list seen by
engineers
used by engineers trained for
engineers we want to get this list out
there
and we're really looking into
how to best reach engineers because
security bubble knows about this
but we need engineers to know about this
so we're looking for engineers
associations we're really interested
in what plc vendors says say we're
really interested into plc user groups
um if you have contact in there contact
us
we can get these slides there we can get
a presentation organized we can get
trainings organized we can we can get
you in there
we collaborate with you in order to
bring these
knowledge into your communities locally
regionally we have people all around the
world in the project that are happy to
do that
and lastly what's very important
important in this slide is the green
bubbles
so this is not a close club it's a
community project and we really
want and need everyone who is interested
uh
and passionate about making plcs more
secure you don't have to be as
a pse programmer you don't have to be a
security expert
if you're passionate enough you can
totally
um use your knowledge and your
engagement and it really in each of
these groups
there's not a lot of space for for
taking up new people and we welcome you
with open arms
lastly here's the project website
and here's our are all our contact
details if you want to
contribute if you want to become part of
any of the teams
of the core team shoot an email to plc
security at
nurizia.de uh we've got a twitter
account you can follow
both vivec and io on twitter and on
linkedin
and there's also
a comment form on that website here you
can download and send to that email
address
you would be very very happy to hear
from you i hope you learned something
about secure plcs today
and i hope you continue enjoying defcon
thank you