welcome everyone to
leveraging sbom software build materials
for ics security
uh looking forward to sharing some of
this uh material and content with you
guys
i appreciate everyone taking some time
out of their day um during defcon and
this virtualized um
you know experience that we're all going
through together uh and i i just really
appreciate you guys
attending this so kind of jump into
things
first off just by way of introduction my
name is tom pace i'm the co-founder
and ceo of netris uh we are a startup
that is focused on providing visibility
to a
class of devices that has historically
not had
very good visibility within them so
things like
iot ics networking devices
embedded systems medical devices things
of that nature
so prior to that i was the global vice
president of enterprise solutions at
silence where
i traveled the world basically helping
clients uh solve problems related to
product services threat research
all manner of things um during that time
also i handled
a ton of incident response engagements
um specifically
uh a many regarding ransomware so
that that garnered me a bunch of
attention and i ended up getting uh
interviewed on 60 minutes for some of
the work that i did there which was a
really cool
and fun experience prior to that i
worked at the department of energy doing
industrial control system security
and other security engineering things um
and then uh before that i worked in a
bank and then prior to that i was in the
marine corps where i spent most of my
time in the middle east
doing uh not cyber security things
essentially
so i've also done a bunch of things at
rsa black hat um
other other conferences of the like
so uh speaking of uh my time in iraq
actually
um it's always fun to share a picture of
me and chuck norris over there in 2007
so uh it wasn't wasn't all so bad it's a
much
much younger and youthful looking
version of myself so
from an agenda perspective what is a
software build materials uh then we'll
go into
uh market trends that are driving uh
software build materials like why now uh
why is it important now
um what what things have happened that
are driving this adoption
in need device risks um associated with
not having a software bill materials or
risks that could be reduced by having
one
attacks that that have occurred and
attack types
and then we'll move into identifying and
discussing
the value proposition the use cases that
software bill materials can
uh can provide how do we generate and
consume an s bomb
uh the the the challenges associated
with such
and then what do i do once i have one so
to jump into it a software build
materials is basically a
complete formally structured list of
components libraries modules that
are required to build which essentially
would mean compile and link a given
piece of software
in the various supply chain uh
relationships between them
and so in the bottom left here you can
see the relationships
um of the acme application uh where you
basically have you know bingo buffer or
bob's browser
carol's compression engine things like
that this is an example
that is used by the ntia
which is a part of the department of
commerce that has really been
spearheading
the software bill of materials working
group of which uh i've been a member for
roughly
eight months or so they're doing amazing
work and it's a a really exciting thing
um that they that they've done there and
what they've done for the community in
general
so uh on the right-hand side here you
see
um basically a an adaptation of a um
an ingredients label uh for for food
that
that could could be modeled uh for
software
and so you know an example here would be
uh imagine a scenario where you have a
peanut allergy
as an example and you go into a bakery
and basically ask the baker hey
uh i have this severe peanut allergy
i need to know if any of this cake that
i want to buy or
cookies or whatever have been made
within the vicinity of peanuts or
something like that because you have
like a very intense allergy
and then basically not being able to
tell you so you have
you now have to basically make the
decision on whether or not you're going
to accept the risk
of purchasing this this baked good and
putting your
your health at risk well that's
essentially the state of affairs that we
are in
uh from a software perspective now all
companies aren't
don't have that uh problem to that
extent but
generally speaking uh software build
materials are not available for
uh or distributed to the great for the
great majority of software that is
that is created so uh and this provides
a bunch of problems which we'll kind of
dive into
so these are things that we do have a
bill of materials for
food obviously nutrition labels
ingredients
um you know various
sizes and dosages of different things uh
hardware
so this these are the this is the bill
of materials for a red wagon
um so it has all the components parts
required and then also
chemicals now this is this is less of a
specific list of ingredients for
chemicals but it is
a hey here are the things that you need
to be aware of
uh if you get if this happens to you
from a prevention
reporting storage disposal perspective
it has here are the hazards associated
with this
and so you these would basically uh you
could think about these as potentially
like
from a comparison perspective
vulnerabilities associated with the
software component
from the chemicals perspective so these
are all examples of things
that we have a list of ingredients a
list of risks a list of harms
potentially associated uh with different
things in our lives
so but what we don't have this for in
many cases
um are our software and even less so
for industrial control systems
operational technology
things like that so the things that are
driving and
providing critical functionality for
critical infrastructure
and oil and gas and power and utilities
and things like that
are are especially deficient in this
realm
so which one is more important having a
bill of materials for a red wagon
or having a bill of materials for a
programmable logic controller
uh it's obviously a you know facetious
question
but as you can see we do have a build
materials for a red wagon and we don't
for a programmable logic controller in
many cases
and that's a problem so diving into the
market drivers and trends why do s bombs
matter and why now
so the executive order that recently
came out um which was a huge
uh step in the right direction direction
from a software bill materials
perspective
uh has the has the phrase s bond
mentioned 11 times
uh operational technology is
specifically called out
it also highlights various use cases of
a software bill of materials
vulnerability and license analysis risk
management use cases
centralized storage and aggregation of
software bill materials
so that you can do things like a higher
level analysis and and have
all this data in one place uh 5g
deployment
in adoption is a huge driver here uh
we're talking about a significant
increase in overall telecommunications
infrastructure
that we're going to need visibility into
um and that we traditionally don't have
visibility into
so smart cities are are going to be
heavily reliant on this
and we know that there is a enormous
push for that kind of
technology in cities um the
infrastructure alone here is is
enormous to to to even just rolled out
5g
from a like cell phone perspective let
alone all of the other things that
people want to do
from a uh from a smart cities um
perspective
so uh the other problem here is the
adoption from 5g is going to be much
faster uh than than 4g because there's a
higher desire
to gain the additional technical
capabilities that 5g can provide
so uh that's going to increase a huge
attack surface
that then currently exists uh i already
kind of mentioned smart cities
but the idea here is right this is uh
um the problem you have here is there's
a
adoption and time to market are really
prob
are almost certainly going to supersede
security requirements
and that becomes less of an issue if we
have software bill materials and we have
all this data available to us
that can provide us insight into the
things that are going on um
so if we are gonna get things to market
really quick and ignore
security at least at the beginning at
least we have visibility into these
things
uh digitization of manufacturing like we
are here digital manufacturing exists
obviously uh the this combination of
cyber physical systems
is is a common trend that that's being
discussed very often
um but once again security is kind of
viewed as an afterthought here
uh even though we all know how important
it is um
and that's security is hard baking these
things into the
into the build pipeline is hard this
isn't a
discussion necessarily that all of these
things are like
the easiest things in the world but it
is important to highlight that these
things are incredibly important
um the manufacturing environment uh
impacts that that can potentially occur
are huge here
i mean you have something like the
colonial gas pipeline which was not
the ot infrastructure was not
compromised but the ot infrastructure
was made unavailable as a result
of uh a i.t compromise and that
dovetails into the last bullet there
around it and ot convergence
so um even though the ot environment was
not particularly we're not specifically
compromised in that attack
it was still made unavailable which
clearly violates the cia triad
specifically availability so these kind
of issues
are becoming more and more common and we
can't really
um you know allow these kind of things
to keep happening
otherwise uh not having the east coast
be able to
get gasoline and other oil-based
products is obviously a pretty big
problem
legal regulatory and compliance issues
so there's a huge push here
from a legal compliance perspective uh
you have the iot cyber security
improvement act that got signed into law
in december of 2020
um you have the fda um
using the underwriter's laboratory
standard 2900-1
which is a standard for medical devices
which can also be used for other
device types as well you have a handful
of nist
um special publications that um
that approach
the like either iot or firmware
specifically
or other kinds of device types and in
specific environments in which this is a
problem
and then you have international
standards standards as well like iso
iec and uh nissa as well
so from a device risk perspective
how are the market trends driving the
risk of maintaining our current approach
device security now we talked about this
a bit already in terms of like more
devices and things like that but let's
dive into a couple
specific examples so a real lack of
visibility here now if we're talking
about firmware specifically which
is i think fair to say the overwhelming
uh set of software that needs
that we need visibility and a software
build materials for especially related
to
uh ics and um operational technology
so the the firmware and the devices that
are being powered by firmware that are
running these devices are often treated
as a black box um
so does a device exist and where does it
exist or common use cases
um that's important obviously that's why
that's the critical security control
number one
uh but this ignores the the risk within
the device itself
so it's great if we know where a device
is and what it is
and all of that but we also need to
understand what's on the inside so we've
been approaching this problem from an
outside in and now we also need to
approach this problem from an inside out
also fully updated firmware that's
perfectly patched
does not always indicate it is without
risk whereas if you look at something
like windows
if you do have a fully patched windows
operating system
that does provide you a reasonable
like modicum of security like you you
can say hey
all of the vulnerabilities that are at
least known
have been patched on my windows
operating system now that doesn't
prevent you against zebra days and all
of those other things of course
but for for these kinds of devices
they're not even given that luxury
meaning there could be a litany of
vulnerabilities that are
very old um you know five ten years old
known as end days
um and those are not patched and
maintained in the same way as like a
windows operating system and there's
lots of reasons for that
but not having visibility into that is
is a big problem
uh obviously no building materials
passing the risk to the submit to the
manufacturer
i have i talked to a lot of people who
mentioned to me hey we're
we're uh passing the risk off to the
manufacturer
just to be totally frank no no you're
not um
if you buy a device and are using that
device if you buy anything
anything in the world you have just
chosen to accept that risk
uh to go back to the um the example
around going into the bakery
if i buy that cupcake and i have a
peanut allergy
and there's peanuts in it or whatever
and i eat it
like the bakery doesn't get sick i get
sick
i chose to accept the risk so this idea
that we're passing the risk off to the
manufacturer is just
totally false it's just it's not what's
happening and
we need to just stop saying that it is
uh and this to
compare again to microsoft um
no one says hey we're just relying on
microsoft to
make sure that nothing bad happens here
we spend
millions of dollars installing agent
after agent after agent on these
operating systems to provide visibility
provide telemetry and give us an idea of
the overall risk
posture of a given computer but we don't
do the same thing
for these kinds of devices now you can't
install agents on all these devices and
things like
that but there are things that you can
do and so
that's that's that's the important piece
so this just kind of highlights uh what
i kind of just mentioned around
traditional endpoints versus ics
endpoints this is not an exhaustive list
and not a column
but the point being you have a lot more
options to provide a lot more visibility
on a traditional endpoint than you do an
industrial control system endpoint
so like i mentioned most of the analysis
is done from a network layer perspective
outside in
you have limited options and technical
capabilities for endpoint telemetry
because
you a lot of these devices just can't
even support an agent
infrequent updates and patch cycles
whereas on traditional endpoints you
have
a million opportunities to to gain
visibility
as um as everybody you know as everybody
obviously knows
so uh here's another example that uh
something i experienced
uh while i was working at department of
energy
one of the things i was tasked with was
determining the impact of
vulnerabilities such as shell shaw
carplete others
we had no visibility into into our own
uh uh devices no proactive announcements
about what was happening
um i had to reach out to you know all of
the vendors that were
that were running various uh device
types
um with within the the environment and
it took a long time to even get answers
that were
somewhat confident uh not even perfectly
confident which was another problem
i uh i i've i had the opportunity to
talk with a handful of people who were
on the front lines of this from a
manufacturer perspective
and one anecdote i received was uh from
a very large
ot ics manufacturer that they had to
email
635 people internally
to ascertain you know where
specific versions of you know an open
ssl
binary was being utilized so needless to
say
that is a that is a not scalable
approach and
um makes makes dealing with this problem
even even more challenging
so an inability to answer are we
affected which piggybacks on that
so if if we determine a vulnerability
exists instead of credentials exist an
expired certificate
uh is there whatever it is we don't have
like a repeatable consistent process to
determine
if you're affected uh answering
questions can be hard
right companies acquired don't have an
inventory so this is something that we
can help solve
um manufacturers have the same problem
as the end user
they're not most manufacturers don't own
their entire supply chain
they are relying on other third-party
vendors for components and hardware and
software
and open source things just like other
people
so they actually have the same problem
as the end user in many cases
which is an important thing to note um
most organizations have 30 plus vendors
probably conservatively
so being able to manage all of this is
time consuming
not comprehensive and not done in in a
way that
that really scales so there's no
continuous monitoring or analysis
which which is is i suppose fairly
obvious
if we don't have visibility into things
uh we have no way to continuously
monitor and analyze them
so what you'll see is a lot of
organizations will do this via a
consulting engagement which is not
continuous not comprehensive
and only focus on really what's outlined
in a statement of work so
aspects that need to be continuously
monitored here
in no particular order vulnerability
identification
compliance risk tracking the ability to
just ask questions of this data
so here's a particular example with
related to a siemens
vulnerability that came out in april of
2020 that highlights that this
continuous monitoring and analysis is
not occurring
so the device notice date is
april of 2020. the vulnerability release
date
is from august of 2018. this is what i
mentioned as an end day like
this is not a zero day this is not a new
vulnerability this is an old
vulnerability
that is just identified and it was
related to
a kernel version so this is 609 days
that at-risk devices were running
critical functions so
this was not a difficult piece of
analysis that needed to be conducted
you you identify the kernel version and
you look
up that kernel version against the
national vulnerability database i mean
it couldn't be simpler
and something as simple as that just is
not occurring so
you can see how this provides a giant
problem
this is just a um uh you know as a
result of these risks that exist it's
like okay so we have risk
great what are are there actually
attacks happening as a result
and the answer is obviously yes uh so
pathway one is you have a targeted
supply chain
malware attack or not necessarily even
malware by putting in like a back door
which isn't necessarily a malicious
binary but could just be like hard-coded
credentials
in a configuration file or something
like that uh so solarwinds is a great
example of this recently
obviously um a targeted device
vulnerability attack
this is the most common i think uh based
on
what we've seen um you have like the
mirai botnet you have ripple 20
you have all of these various uh device
vulnerabilities
um from from code that is running on
these uh different kinds of devices
and then you have the infiltration of it
networks across the ot air gap
so you had you had the uh the municipal
water
um system where they were able to you
know compromise some things and
and and get access to like the chemicals
and whatnot
and then you also have as i mentioned
previously the colonial gas pipeline
issue
so how can software build materials help
so shining a light
on this device risk is really what we're
what we're after
so from a value proposition you know we
can reduce unplanned unscheduled work
reduce code bloat adequately understand
dependencies within broader
projects comply with license obligations
monitor components for vulnerabilities
obviously
end-of-life awareness make code easier
to review maintain a blacklist of banned
components which is super important
especially for things like high
assurance environments
provide software bill materials to
consult customers for that transparency
third-party risk identification you can
build this software build materials
into your third-party risk so now
instead of relying on like a paper-based
questionnaire that's always like
questionable and the amount of value
that's providing um
we can now actually have the data-driven
approach to
to doing third-party risk management for
the software that we're procuring from
these vendors
um and then compliance adherence and so
i love this um
i don't even know what to call it like
s-bomb flower on the right-hand side
that highlights different um uh use
cases around supply chain software
development
uh software vulnerabilities compliance
uh all these different pieces of parts
so there's a lot of
a lot of good use cases here for this
data once we have it
so it's it's the it's kind of age-old
tail
once we get the visibility once we get
the data we can
we can extrapolate that and solve a ton
of problems downstream
so that's what we're trying to do so
s-bomb generation and consumption
uh there's a lot of software development
tools that can create s-bumps for you
easily
as you're building code going back and
creating an s-bomb for something that's
already been done
is just a much more challenging
proposition most of the time so
you know the standards that exist for uh
s-bom
you know adherence cyclone dx suid
and spdx are all well documented you can
go find them online
and if you go look at like cyclone dx as
an example they have an entire page
dedicated to tools that can be used to
generate
software build materials that can be
used to generate them from cyclone dx to
spdx format
there's a tons of opportunities here to
to make this much easier on yourself on
the right hand side you see
this is a set of the use cases that uh
can be that are basically uh part of the
cyclone dx
um standard so and whatever ones you can
fill in great whatever ones you can't
you know uh prioritize them based on the
needs of
what your customers are asking for so
this is similar to like the food label
piece i talked about earlier
where it's like here's the contents but
not necessarily like the rest
recipe or a proprietary blend which
would be a problem
so from a challenges perspective here
you know a software bill of materials is
not
is not a panacea it's we're not solving
all the problems
um it's it's another set of data
that we can leverage to help identify
risk provide visibility and
and reduce the likelihood of a problem
happening and and it allows us to be
more proactive
in in terms of identifying risk and and
mitigating or eliminating it as best we
can so this is not a preventative
security control
right um
all security controls don't need to be
preventative so
if you don't have visibility into
something you definitely aren't going to
be able to prevent it
so it's important to get this visibility
first and then
hopefully something from the data that
we can gather here can be integrated
with or tied into something else that
can help prevent
uh you know some malicious activity from
occurring
and it's important to realize right you
know security logs or logs in general
aren't preventative vulnerability scans
are not preventative
data lakes are not preventative sims are
not preventative but
but we all have them we all spend a ton
of money on them and so
all we're trying all that is we're
really mentioning here is
getting the data for these kind of
devices is probably more important
in most cases than some of the other
devices that we're getting data for so
let's do it
um legacy equipment's a challenge right
you might only have compiled code
so access to source might not be
possible for
a million different reasons um and so
component identification
and things like that can be really
challenging when it comes to
uh generating a software bill of
materials here but
it doesn't need to be perfect right
perfect is the enemy of good
and so it's important to make steps or
take steps
iterate iterate iterate make things
better over time
and uh if if something can't be perfect
that doesn't mean we shouldn't do it
you know imagine if you're
a person who has has been blind or uh
is is colorblind right we've all seen
those amazing videos of somebody being
given
a pair of those glasses and they can
finally see colors for the first time
and then
we all cry uh that's what we want to do
here
is basically give visibility give people
a set of glasses
that allows them to see what's going on
within these devices serving critical
functions in their environment
and so it's possible we can do it
so some misconceptions about a software
bill and materials i think are worth
highlighting here
am i providing a roadmap to the attacker
so
operating under the assumption that
attackers can't acquire this data on
their own is just
just i mean just totally inaccurate uh
in reality what we're doing here is not
providing a roadmap for the defender
so we're making we're putting roadblocks
in front of the defender
whereas the attacker can go get this
data so it's actually the opposite of
this
uh s bombs level this playing field to
some extent um
is this intellectual property disclosure
the answer this is no
we're not providing proprietary source
code or anything like that
these software components are just a
piece of the puzzle that that allow
you know organizations to identify risk
and and
understand what they need to defend and
what they have will this increase my
licensing costs
so this awareness allows manufacturers
to address unknown licensing commitments
it allows them to address these issues
in a proactive manner not reactive
gives them the visibility to make good
decisions ahead of time through fees or
more favorable terms
it also helps the end users and clients
ensure that they have compliant things
so it's kind of a win-win-win for
everybody from that perspective
so i have a software build materials now
what
so a bunch of things we can do here as i
mentioned once we have this data the use
cases for it
are pretty infinite enrichment of the
data with other sources
third-party sources uh vulnerability
data threat intelligence data
things like showdan like uh what you
name it um
operationalize the data we can send this
data to a sim
uh for triaging we can we can make it
part of our vulnerability management
process
we can integrate this data with a sore
platform we can integrate this data
for the manufacturer into like our ci cd
pipeline
uh you know if a critical vulnerability
is identified then
open jira issue whatever i mean the
logic we can think of and build out is
you know uh uh you know a lot so
make decisions based on visibility that
was previously impossible
or incredibly difficult to ascertain is
is is the biggest one
so adding additional monitoring to this
device due to a vulnerability
push back on manufacturer for lack of
license compliance
enhance third-party risk management
data-driven insights for life cycle
management segment a device or a class
of devices
you now have data to to drive better
decision-making
regarding these kinds of devices and
that's what we're really after
um so this is what you can do once this
is done
so i appreciate everybody taking uh some
time to
to attend this talk i hope it was
helpful and informative um
i will be on the discord server
answering questions
as this goes live so please reach out if
you have any questions
um i will uh i guess i should put my
contact information here
but you can reach out to me at
thomas.pacethomas.gov
p-a-c-e at netris.io
n-e-t-r-i-s-e dot io once again thank
you very much i appreciate it and i look
forward to
uh speaking with you during the uh
discord conversation thanks