It's basically looking at the weaknesses or bugs in a code that opens up the
ability for a cyber hacker to enter and attack your code. Welcome listeners to
the Industrial Security Podcast. My name is Nate Nelson. I'm here with Andrew
Ginter, the vice president of Industrial Security at water Fosscurity Solutions, who's going
to introduce the subject and guests of our show today. Andrew, how are
you. I'm very well, Thank you, Nate. Our guest today is
Susan Ferrell. She is a strategic advisor for ot and Industrial Cybersecurity and our
topic is more or less scanning for zero Days. She's going to be talking
about a micro repository. I wasn't aware of the common weakness enumeration repositors rather
than the common vulnerability repository that I was familiar with. So you know,
zero Day's weaknesses not vulnerabilities. That's our topic. Then, without further ado,
here's you with Susan. Hello Susan, and thank you for joining us.
Before we get started, can I ask you to say a few words
for our listeners about yourself, about your background, please absolutely. And Andrew,
thank you so much for inviting me to this podcast. The first twenty
years of my career I spent in oil and gas exploration and production or upstream
side of the business, working for the Halliburton Software division, Landmark Graphics work
for Silicon Graphics or SGI, and high performance visualization of hydrocarbon reservoirs as well
as Paradigm Geophysical. Then I shifted over to it cybersecurity, and because of
my oil and gas background, that migrated over to a focus in ot ICs
cybersecurity. So for the last ten years as what I've been very focused on.
Also last couple of years have been focused on taking otics cybersecurity that was
developed for defense purposes and commercializing that for protecting critical infrastructure and nuclear manufacturing,
oil and gas, chemical, et cetera. And our topic today is mapping
for zero days. I've never heard of this. What is mapping for zero
days? What problem are we solving here? So it's really interesting, Andrew.
So there's a lot of focus when you think about otics or industrial vulnerability
management is to look at cvees or common vulnerabilities, and those are the vulnerabilities
and software code or firmware code that sits in embedded devices that have actually been
published. There's also another layer of vulnerabilities known as keVs or known exploited vulnerabilities.
Again, those are the cvees that have been known to be exploited in
different environments and software. What cwes are are common weakness enumerations or it's a
category system that was developed by MITER and KPAK that identifies weakness and vulnerabilities in
software code, both at a hardware and software level. So when you're looking
at firmware for instance, So that is what a CWE is. It's basically
looking at the weaknesses or bugs in a code that opens up the vulnerability or
the ability for a cyber hacker to enter and attack your code. I'm familiar
with the the CVE system and database. I am aware of the non Exploited
Vulnerabilities list, but you know, probably don't consult it often enough, but
I know it's out there. CWE. I've never heard of weaknesses? Can
you? Can you talk about that a bit more? What is a CWE?
Sure? So, again, it represents a weakness in the code.
So one example is a buffer overflow, and buffer overflow is the ability for
a cyber attacker to over instruct code and be able to literally shut down the
production of a PLC for instance, or may overratchet the PLC and cause it
to explode, for instance. So there's even a cwe that represents malicious AI
code. It's called CWE ten thirty nine. There are cwees that represent cryptographic
problems in code or a dangerous function within the code. So basically it's just
outlining the different weaknesses that a code can have in it that can be exploited.
One of the great activities that I did over this past year is participated
in the cwe pep kpec ICs Working Group, where we mapped cwees to six
two four four three so that you can determine if there are any cwes that
might be resident in firmware on an otics device that puts you at risk of
unmet requirements from a compliance perspective. Andrew, I'm quite familiar with cvees,
but cwees are a new concept to me, and I'm not yet entirely clear
on the distinction. I mean a buffer overflow to me, sounds like of
vulnerability. Yeah, I wasn't familiar with cwe's either, but you know,
if you google it, miter or CWE, there's a whole repository there's hundreds
of these things. And you know, if if there's a buffer overflow in
a CVE, it says something like this PLC, if you send it that
command, it triggers a buffer overflow that can be exploited to blah blah blah.
You know, these seventeen models of PLCs run that same software, they
have this vulnerability. That's a CVE. That's that's a known vulnerability. In
CWE, there's an entry for buffer overflow that says a buffer overflow is when
somebody sends a message that you know is usually too long, and you know
it describes what is a buffer overflow, and that says that's it. It
does not say it's in this PLC or in that web browser or in CVE
is sort of specific, whereas CWE is sort of the idea saying, well,
if you're not checking the length of your buffers, you could have a
buffer overflow. If you're not careful about how you manage memory, you might
use memory after you free it. If you are not, you know,
careful about keeping track of your your web browsers, you could have cross site
request forgery. So CWE is describing types of vulnerabilities where a CVE is describing
one of those types is specific in these six products, and if you,
you know, get the patch, you fix it. So in a sense,
CWE is is a long list of stuff that could go wrong in software,
and you know, to me, it's I thought it would be primarily
useful to software developers saying, oh, I'm writing software. Here's you know,
literally hundreds of things I could do wrong. Let me go through them
and see if I've done any of them. Does that make more sense?
It does, so then if if I follow you correctly, it isn't that
we're applying these cwe's too specific software products. They're just a general list of
categories, sort of like miter attack, but for vulnerabilities. You know,
I hadn't thought of it that way, but yeah, minor attack is all
of the ways, you know, sort of types of ways that bad guys
could attack us, and you know, CWE is all of the you know,
kinds of vulnerabilities that could be latent in a particular product. So yeah,
in a sense, CWE is the miter attack of vulnerabilities. I haven't
thought of it that way. I think that's that's probably a good way to
think of it. Buffer overflow. I understand you said you mapped it to
six two four four three, though I mean, you know what, I'm
the standard I look at all the time in six two four fur three is
three dash three which talks about you know, you should put a firewall here,
you should do anti virul there. It talks about security controls. It
doesn't talk about vulnerabilities. What part of six two four fourth e did you
map these vulnerabilities into? So the three different parts that we as a group
focused on were parts three dash three, four dash one, and four dash
two in for example, we were assigned a specific CWE each subgroup. I
was my first CWE that we mapped as a group was CWE seven ninety eight,
which represents cryptographic issues in code, and it is was not a hard
exercise to map it to specific specifications within three dash, three, four dash
one and four dash. We just mapped the wording from the definition of CWE
seven ninety eight, for instance, to the specific parts within three three FORDSH
one and FORDSH two. And then as a result, what Miter did is
published the mapping of the CWE so that if you're looking at setting your compliance
requirements, you can do an analysis of the firmware to see if any of
those cwes exist, and then determine if by continuing to use that firmware in
its existing state, if it is causing compliance issues to six two four four
three. The same can be done for eight hundred fifty three or eight hundred
eighty two to map the compliance requirements to it. Could you give me an
example of that. I mean, you know, if you look at the
PLC and say, well, it appears to be written in C. That's
sort of the signature of the binary and the firmware, So it is probably,
you know, somewhere possibly susceptible to a buffer overflow. In what sense
you know? A? Have I got that example right? And B if
I've got it right, in what sense is that a compliance violation? There's
no, there's no. There's no requirement in six two four four three that
says your your code must be free of bugs. You're correct, But it
does say that you have to practice good uh uh cryptographic practice. Or it
does say that you cannot have any cross scripting weaknesses in your industry four point
zero web application for instance, or it will say that if you do have
a buffer overflow issue in your code, you are not meeting the compliance requirements
of certain parts of three dash three, fourd ASH one and four dash two.
So Nate Susan went through that real fast. Let me give you a
concrete example. You know, uh six two four four three three dash three
is the standard that applies to systems. If I have a a system that
I've designed in my power plant and I wanted to be compliant with the standard,
I would look at three dash three four dash one is a certified software
you know, secure software development process. So if I'm developing product and I
want to be certified as a developer of secure product, that's the standard I
my product development team is evaluated against. My processes are evaluated. Four dash
two is when you certify actual product. If my team has produced a product
and I want the product to be certified as compliant, it would be four
dash too that I'm compliant with. So you know, concrete example, cwe
is possible is what's you know, vulnerabilities that are possible, and what we're
mapping is, look, if you wind up with one of these vulnerabilities,
then you have a problem with this part of your compliance process. So concrete
example, you know three dash three has a rule number five dot seven that
you know, the language is complicated, but effectively it says, if you're
going to send a password across a network, then you have to encrypt it
so that people can't just read your password. Okay. And you know,
the example that Susan gave was a CWE saying well, there might be a
bug in your encryption process that you know, lets people see, you know,
decrypt and uh uh, you know, see the password. Okay.
So the mapping says, look, if you have this vulnerability in you know,
your products, in your system, and that's an if okay, CVE
is what's actually their CWE is what's possible if you wind up with this vulnerability,
then you would have potentially a problem with compliance with rule five dot seven
because the bad guys could use the vulnerability to steal the password. So that's
my understanding of how this this mapping against standards works. I've gone to the
to the website. I see, you know, micro dot org Common Weakness
Enumeration. You know, I see a long list of potential vulnerabilities, and
you know, I can see if I'm a vendor, I mean I've worked
for vendors all my career. If I'm a person developing the software in a
PLC and whatnot, you know, I'm staring at a CWE talking about I
don't know, cross site you know, cross eight scripting or cross site request
forgery. These are vulnerabilities that my software developers should be looking out for when
they're writing the code. But you know this list here, you've sort of
connected it a bit to compliance. Do end users use this list? What
good is this list to an end user? Is it? Is it primarily
a tool for developers to say we should be on the lookout for these seven
hundred different things in our source code. There are several different use cases for
cwees, and you're right, Andrew, it is a very valuable useful resource
for devsec ops as especially from a shift left perspective when they're looking at cyber
informed engineering or secure by design of the devices, being aware of the cwes
during the continuous integration and continuous development of otics device firmware code. But beyond
that, if you are an asset owner, and let's say that you have
just completed your asset inventory, it is typical that twenty to forty percent of
your assets may be end of life or legacy assets and it's no longer being
supported by an OEM, but it is still in production, it's still connected
to your network, and you will want to either a hire a threat hunter
threat modeler to look at the firmware of those end of life devices to see
if there are any of the cwees that are in the firmware. That can
be done through reverse engineering, it can be done through binary analysis scanning to
see a the cwees are present in your firmware. What actions you take after
determining if there are any potential zero days in your firmware is to either a
triage that end of life asset for replacement or work with your OEM provider to
see if there are any remediation steps to be taken. But the other way
of handling that is fencing the device, much like what Waterfall does with providing
directional communication to an end of life device to protect it from exposure to a
cyber attacker. So yes, there are many things that both an asset owner
and an OEM manufacturer can take in reducing risk if a cwe has been identified.
This sounds almost too good to be true. If I've got a list
of I don't know how many hundreds of potential weaknesses. And I've got scanners
available that can scan my firm where I mean, you know, let's say
I'm a vendor, can scan my my my stuff and come back and say,
here's all of your vulnerabilities, fix them all. You know, now
my code has none of you know, these these vulnerabilities. You know,
the only thing I'm exposed to is I don't know, misconfiguration someone puts a
week password in, or you know, new kinds of vulnerabilities being discovered.
It sounds really good? Is this? Is this how people use this?
Quite truthfully, Andrew, there are no silver bullets out there for doing binary
analysis and finding one hundred percent of potential zero days or cwees, And not
all cwees are even exploitable. So even after you find a CWE, could
a hacker get to it? Is there a path to it? So you
really have to use, uh the scanning as a part of your full stack.
When you're looking at your vulnerability management, you're using your s bombs,
you're using your hardware bill of materials. You're looking at endpoint protection, you're
looking at network monitoring, you're looking at the configuration of the assets. You're
making sure that there that your vulnerable assets are fenced properly, that the information
is being properly fed to your SIM or your SORE so that you can trigger
security policies too to keep an eye out on access to your more vulnerable or
end of life or legacy assets. You want to add threat intelligence to your
stack. You want to add you know, potential membership into an I sack
that is sector specific to what you're involved in. There's you know, also
the great capabilities that AI is adding to industrial automation looking for anomalies within the
code. So this is just a part of your full stack, but I'm
advocating not to miss the ability to proactively look for potential zero days in addition
to monitoring for bad behavior on your network, because often by the time that
you see the bad behavior on your network, it may be too late.
So add both proactive detection as well as responsive totec. An additional part of
that full stack is also digital twins. Digital twins are not only providing value
for mechanical asset integrity, but also from a cybersecurity standpoint, it's providing that
redundancy and resiliency for your critical infrastructure environment to then apply patches or to then
have discussions on remediation for these potential zero days, triaging your end of life
asset replacement strategy. So it, you know, I just want it to
be viewed and not be glossed over. There's a lot of value in knowing
whether or not there's potential zero days that are sitting in your firmware. Okay,
so you know you've covered a lot of ground in terms of where cwe's
might add value to a defense and depth posture. Can I give you a
concrete example? Can you walk me through, you know, assume let's say
that I am, I don't know a medium impact power plant. That's what
personally I'm most familiar with NIRKSIP. I've got to comply, means I've got
to do a risk assessment, a security assessment on my system. I don't
know what is it every eighteen months or something like that, whatever the rule
is. And let's say as part of that, I bring in, you
know, an outside assessor. They come in and you know, very carefully
run I don't know NESSUS or something, and you know, on all of
my one hundred PLCs and hmis and everything else, and it comes back and
says, you have three vulnerabilities you didn't know about. These three PLCs have
a vulnerability. It's in the cve it was added ten days ago. And
I go, what what not supposed to have any of these? Quick?
Put a plant and page in place, patch this figure out if I have
to report this to the regulator, you know, and another sort of a
month or six weeks later, when the patch has been tested, it's been
rolled out. You know, I'm done. I am aware of no vulnerabilities,
no cvees that are evident in my asset inventory. You know, I'm
clean again. But I've learned about cwees. Now go look at the CWE
database and it doesn't have the name of my PLC in it. If I
have that sort of let's say NRKSIP infrastructure in place already, how would I
use a CWE That is an absolutely fabulous question, Andrew, and I think
that's a lot of where companies they think that if they've handled all of their
cvees that they can call it a day, and it is, you know,
definitely a step forward. And saying that you've eliminated all of your uh
cvees, that's you know, a fabulous accomplishment. But again, the cve
is a published vulnerability, it is not going to recognize a potential zero day.
And if you know, you look at your ot threat report that you
did, your your twenty twenty three threat report, some of the attacks that
were reported were actually taking advantage of zero days and not published cvees. So
you're not finished. After you after you patch remediate all of your cvees,
it is important to do a deeper dive and do vulnerability scanning of your firm
where looking for cwes. That responsibility can be delegated to your third party vulnerability
management provider, your compliance provider. It can also open up dialogue with your
OEM manufacturer relationships that you have. But you know, the importance here is
that you don't stop just at the cvees or or the caves. Is that
you do continue down the path of being proactive and seeing if there are any
cwes that reside in your assets. Okay, so maybe another way of asking
the same question, let's take the other extreme. You know I have I
don't know, a shoe factory with hundreds of PLCs and other robots, and
I know I know that I have hundreds or even thousands of instances of vulnerabilities.
This, you know, this PLC that I have seventy three of,
has you know, nineteen vulnerabilities that I know about, and I just haven't
got around to patching it. So I've buried, you know, these these
vulnerable PLCs behind six layers of firewall and some encryption and some antivirus and some
intrusion detection. And you know, I already know that I have thousands of
cvees that I haven't patched. Does CWE do me any good? What sort
of what? How mature do you have to be before you can get some
benefit out of a CWE scanner or approach or whatever it is. Yeah,
I think just about any critical infrastructure can take advantage of it. I wouldn't
necessarily place a shoe manufacturer is being critical infrastructure. So you know, if
you look at the you know, the the digital grid, power generators,
electricity providers, you're looking at wastewater treatment plants, you're looking at nuclear power
generation or anything that could affect national security. You know, chemical refinery plants,
because you know, you're looking at highly targeted sectors for potential terrorism.
Those are the low hanging fruit of sectors that take the most advantage of what
we're talking about. So the more mature critical infrastructure providers so andrew in its
simplest form, cdwe's and cvees. They're both tackling ultimately the same sorts of
software bugs, but cvees from the after the fact perspective known vulnerabilities you deal
with them in turn. And cwe's, as she mentioned, are the more
proactive, the looking for the things that will one day be cvees if not
dealt with today. Indeed, But you know, to me, cwe's highlights
sort of a very common blind spot that I see in engineering teams. I
see way too many people, you know, often technicians sort of people hands
on lower down, you know, nose to the grindstone make this stuff happen,
focused on known vulnerabilities, and the you know, the calculus in their
mind sort of goes, well, you know, if I can pack all
of my vulnerabilities, if I can get rid of all of my vulnerabilities,
then I am invulnerable. And they work really hard to patch everything, and
you know, the whole system is sort of blind to the fact that,
well, that addresses the known vulnerabilities. But who knows what's out there on
the unknown side, and CWE is sort of a tool that you know,
once you have a glance at it, you go, there's hundreds of these
things. There's hundreds of potential problems going to bite me. If the bad
guys find these before I do, before the good guys do, before there's
a patch available, then we're in trouble. So to me, CWE sort
of is a powerful way of reminding people that it's not just about patching.
There's there's bigger fish to fry here. There's sort of more dangerous scenarios that
are possible. And this isn't to undermine the necessity and the difficulty in pat
everything, but it strikes me that maybe part of the problem is that it's
simply easier to conceive of all of the known vulnerabilities than to creatively address and
go through all the things that you don't know about. That's right, and
you know it's to me, part of the problem is that the term vulnerability
when CVE uses the term, you know most most of the vulnerabilities in the
CVE data based tens of thousands of them are bugs in the software that can
be patched. If you look at the definition of the term vulnerability in the
six two four four three standard. It's defined as any way that a system
can be compromised, many of which are you know, bugs in the software
that can be patched, but others are configuration mistakes, are stolen passwords,
our default passwords, are you know, any of the many ways that you
can attack a system without exploiting a software vulnerability. But the fact that they
use the same word for both of these is very confusing. You know,
we had Eric Cosman on like a year ago and he admitted, look,
this is you know, there's confusion in the industry. Vulnerabilities are bigger than
software bugs, and again cwe uh, you know, reminds us about software
bugs we haven't even seen about. But the bigger picture is, you know,
we need to be concerned about all of the ways that we can be
attacked, not just exploits of known vulnerabilities. We do need to address those
exploits, you know that that possibility. Uh yeah, I don't want to
belittle that. It's a it's a very hard problem to solve, but the
you know, security is is bigger than that is sort of the lesson and
c W is one of the ways of reminding us of that. And you've
been working with this concept with you know, end users like this for some
time. Can I ask you, you know, when you look at at
CW you said there's scanners available. If you run one of these scanners on
you know, a system that is you know, has a bunch of known
vulnerabilities and a plan to get rid of them, and you know has already
got rid of all of the other known vulnerabilities, and you run one of
these scanners and you come up with what do you come up with? You
know, how many instances do you come up with? How unhappy are these
these owners and operators to discover that you know there's more to do. Can
you talk about the experience of working with CWE fine in a CWE is not
the end of the world for the OEM or the asset owner, and it
provides a great collaborative opportunity. I was just included in just listened to a
podcast from Dragos for instance, that was using the use case of working with
Rockwell Automation where they discovered some cwees that then goes through the reporting exercise of
Actually CWE is a precursor to a c CVE. I didn't explain that earlier,
But you have to find a CWE, you have to determine it is
exploitable. You then discuss it through either CISSA as the route management of that
CWE for the o T I c S sector, and then once it's been
communicated to the OEM, they're given the opportunity to remediate and then it becomes
a named CVE and Dragos is a is A is a CVE naming Association ers
also referred to as a CNA. They went through the whole scenario of finding
h cwees associated with Rockwell automation devices or assets and found it to be a
very positive collaborative discussion where Rockwell was very proactive in coming up with remediation before
it was published. So it can be a very positive activity in finding a
CWE because it only reinforces our critical infrastructure cybersecurity position. I've led development teams
for much of my career. You know, we were responsible for products that
had hundreds of thousands, sometimes several million lines of code in them. And
you know, in spite of our best efforts of you know, me and
every one of my development teams, every piece of production product that we released
had bugs in it. There's a certain defect density depending on how vigorously you
test, vigorously, you inspect vigorously you design the code. In spite of
your best efforts, there's always defects residual in the code, more defects in
larger artifacts as a rule than in smaller artifacts. And some of those defects
are security vulnerabilities, just statistically, and you know, some of those those
vulnerabilities we've discovered or are going to be discovered by the good guys and are
going to be fixed by the good guys before the bad guys find them.
Some of them, potentially the bad guys are going to find and use against
us before we have a chance to patch them. You know, this is
sort of back of the envelope. This is my personal experience. This is
this is sort of of principles of you know, software development in practice.
You've been using you know, these scanners, you've been using c w E.
How you know if I scan a random h M I with two million
lines of code in it, do I find zero days? Typically, the
the older the the device or asset is, the more likely you are to
find cwe's in it. Because you know, chances are it wasn't included in
a cyber informed engineering program or secure by design program, So yes, you're
gonna you're going to find cwe's. The chances of those cwees being exploited is
then the next step that you take. So it's not a doomsday message that
every asset is going to include a CWE that's exploitable. So that's why the
importance is is to triage it based off of resiliency and how old the asset
is and if it's being connected to the network. So there's a lot of
different factors on whether or not you even want to do this scanning on it.
But you also need to prepare for how you would respond if these assets
or these zero days are actually hacked. So getting involved in incident response training
programs like the isa's ICs for ICs where teams can be focused on the forensics
of the zero day attack and how to respond to it, how to protect
yourself from that going forward, and most importantly, how to prevent it by
being proactive. And so there's a high connection between doing CWE scanning and awareness
of zero day vulnerabilities with your incident response training program. Andrew, how do
you prepare teams for scenarios where a zero day vulnerability is uncovered and now you
have to, you know, rush to patch everything. That's a good question.
I wish I'd asked Susan that question, but sort of off the top
of my head, there's a couple of things you have to do. You
know, the we talked about sort of the definition of vulnerabilities. It includes
zero days, includes other kinds of you know, misconfigurations or you know,
attack opportunities. Zero day specifically, you know, to me, there's a
couple of things. You've got to look at the big picture and anticipate the
possibility in in your designs and in your risk planning when a zero day is
announced. Let's say, even there's occasionally an announcement saying here's a cve A
zero day is being actively exploited and there's no patch available for it yet.
It's sort of an emergency announcement. So that's not really incident response, that
sort of emergency management in the entire program. You know, the intrusion detection
vendors will rapidly produce a signature for the vulnerability being exploited. You know,
what bites have to come across the network to exploit it. You can put
that in place to you know, see if you're being attacked. You might
add even a drop the connection rule to your firewall. It says, if
I see a packet comeby and match this signature, it's you know, called
virtual patching. Even before a patch is available, you can hopefully prevent the
attack propagating into the vulnerable system. You can take other mitigations. You can
say, you know, that subsystem that has the vulnerability is not vital to
operations. I'm going to disable it, you know, for a week and
live without it until a patch is available, and you know, sort of.
But more to your point, my guess is that if there's an incident
in progress, well you've got to deal with the incident no matter how it
got in. But at some point you want to find out how did they
get in? Because once we've you know, shut everything down, cleaned everything
out, we don't want to start it all up again until we know the
bad guys aren't going to get in five minutes later. And so the forensic
analysts, while we're cleaning things out, they are analyzing the data trying to
figure out how did they get in? And you know, we have to
design our systems so that these incident responders to forensic analysts have the information,
have enough information to be able to figure out how this happened. And that
means you know, detailed audit logs if we can on all of the devices,
especially the Windows and the Linux machines, so we can see what did
the user, uh you know, do on the compromised machine to bring about
these these undesirable results, escalation of privilege or whatever. Some sites keep you
know, networks, just keep packing, keep copies of packets on their networks,
or keep copies of packets on their networks that came in through let's say
the firewall interface, keep them for a long time. It means a huge
amount of storage. But it does mean that in an emergency, you're a
forensic team as a fighting chance of going back through those packets and trying to
figure out where did you know, when did the attack come through, and
you know, what did the attack look like, so that they can figure
out, you know, what kind of vulnerability has been exploited here, and
you know, report it to the authorities and put measures in place. So
long answer, it's you know, this is sort of what what it means
to be to have a security program and a response team aware of the possibility
of zero days and especially the zero days in the CWE catalog. Well,
Susan, this has been tremendous. I learned something, you know, I
didn't even know that cwe's existed. Thank you for this. Before we let
you go, can you sum up for us what is sort of the main
messages? What's you know, what's the one thing we should remember from from
this episode? Thank you Andrew. You know. The one takeaway that I'd
really like listeners to to have is to be proactive instead of just being responsive.
You know, if you look at the overall UHNST framework of being able
to you know, detect and respond, I think it's really important to be
proactive in in your overall cybersecurity program. Uh know your assets. I think
that a lot of times, uh if the the larger the critical infrastructure is,
the greater the chances that you don't know every single asset in your infrastructure.
And then even more so triaging the assets based off of resiliency and having
a focus on your end of life or legacy assets that are still in production,
still connected to your network and because their end of life. You may
not have had a patch even available to you or support of that asset available
to you for some time, and it represents the danger of a zero day
lurking within your infrastructure. And cwees give you that opportunity to really do a
deep dive into those triaged assets to see if you've crossed all your t's and
dotted all your eyes from a compliance perspective. Well, if any of the
listeners want to get involved with the Miter cwe ICs Working Group, I encourage
you to do that. It's a great group to get involved in. Also,
reach out to your compliance service providers when you're looking at your compliance alignment
and introduce this concept when you're looking at your vulnerability gap analysis and your asset
inventory management, and feel free to reach out to me. I'm on LinkedIn.
My LinkedIn is Susan Ferrell, so it's LinkedIn dot com for slash in
for a slash Susan Ferrell, and I look forward to discussing any of these
topics with you. Andrew. That concludes your interview with Susan. Do you
have any final thoughts to take us out today? Yeah, Well, you
know there's something new in my understanding the world. You know, cwe's common
weaknesses. You know, they strike me as as more useful for mature organizations
that are looking forward at what might come at them versus you know, less
mature organizations that are just getting started. Strikes me as very useful for developers,
you know, a long list of stuff to look for, to to
watch for, to avoid when we are developing industrial products, you know,
increasingly sort of as an aside. You know, a lot of modern developers
are you know, thinking about problems like this, and they're using tools like
you know, writing their their their products where possible in in you know,
Java or other languages that just you know, Java managers memory automatically, other
languages manage other kinds of things automatically takes entire sets of possible vulnerabilities off the
table. But you know, the CBLB repository strikes me as you know,
it reminds us of the potential for new vulnerabilities coming at us, especially in
older gear whose developers weren't looking at their code this way, weren't thinking about
all these kinds of things when they develop those products that a lot of us
are still using. So a useful resource, okay, well with that,
thanks to Susan Ferrell for speaking with you, Andrew, and Andrew, as
always, thank you for speaking with me. It's always a pleasure. Thank
you. This has been the Industrial Security podcast from Waterfall. Thanks to everybody
out there listening