Cyber tool Framework is the ot or ICs version of CIS Top eighteen. Welcome
everyone to the Industrial Security Podcast. My name is Nate Nelson. I'm here
with Andrew Ginter, the vice president of Industrial security at Waterfall Security Solutions,
who's going to introduce the subject and guest of our show today. Andrew,
how are you? I'm very well, Thank you, Nate. Our guest
today is Jack Bliss. He is an industrial cybersecurity consultant at eighteen ninety eight
and Coal, and he's just published a cyber tool framework. This is an
adaptation of the CIS, the Center for Internet Securities. They have a well
known Top eighteen critical scity control So he's adapted the CIS Top eight team to
the needs of ot and industrial sites based on his field notes of working in
the space for a number of years, you know, capturing his best practices.
So this is what we're going to be discussing his contribution to the field
here. All right, then let's get into it. Hello Jack, and
welcome to the podcast. Before we get started, can I ask you to
say a few words about yourself and about your background and about the good work
that you're doing at eighteen ninety eight and Co. Yeah, thanks for having
me, Andrew. My name is Jack Bliss and I'm an industrial cybersecurity consultant
with a teny eight CO. My cybersecurity career started in twenty sixteen junior year
of high school when I joined a competition called Cyberpatriots, which is a nationwide
computer networking and system hardening competition. In that year, we actually won nationals,
making us the first team in Missouri to do so. In college,
I worked as a computer networking consultant for IT organization, and finally, for
the past five years, I've been at at on yat and Co working as
an industrial cybersecurity consultant, which has been an interesting journey. I think my
mom had a certain sense of security that I would be typing away in a
cubicle. But after just a couple of years in the job, I was
off to get underwater helicopter safety training, which is required to go out to
oil rigs. But yeah, when I started, we were a team of
eight and now we're a team of eighty. So going like crazy, and
I couldn't be more grateful to work for such an amazing organization in such an
impactful role. The experience I've gained during this time. Learning from some really
great mentors and colleagues has been invaluable. Nate. We don't usually comment this
early in the episode, but Jack mentioned the offshore training and sort of the
difference between the desk job and what you do on the ot side. I've
never done the training, but I've heard about it, and it's something else.
If you physically want to travel out to an offshore platform and let's say
the Gulf of Mexico or you know, the North Sea. I've never done
it, but I'm told that, Yeah, there's a bunch of classroom training,
and then the test is they put you in your life jacket and your
whatever into a dummy helicopter, you know, a helicopter cabin. They put
physically a dummy beside you, set up the same way you are, and
they have a crane drop you into a swimming pool full of ice cold water.
Your job is to get out of the helicopter and get back to the
surface with your partner dummy who has been rendered unconscious by the fall. If
you do it, you pass and you can go out to the platform.
If they have to send the divers after you to save your life, you
fail. Go do the training again. So yeah, you know, people
imagine cybersecurity is a desk job. Sometimes it's not. And our topic today
is the cybertool framework. This is something that you put together. It's available
at cybertoolframework dot com. Can you tell us what is it? Where did
it come from? Sort of what's what's the genesis of this thing? Yeah?
So in one sentence, cyber tool Framework is the ot or ICs version
of CIS Top eighteen. So it takes the CIS Top eighteen, which is
an IT focused framework but is easily digestible compared to other frameworks and standards such
as NIST ISO or six two four four three, and aligns those eighteen controls
or really requirements to OT cyber tools and practical insights, being more digestible.
This better speaks to small or medium sized critical infrastructure organizations. So the structure
is as follows, with with the top eighteen requirements in column one, matched
to cybersecurity tools in column two, including OT specific options where applicable and complemented
by field modes and best practices in column three. Throughout, I emphasize meeting
these controls across three levels people, processes, and technology, while reflecting real
world scenarios. There is maturity referenced in some of the recommended controls, So
if you're a small organization, start with X. If you're a more mature
organization, you should aim to hit this threshold, etc. Free tools are
also provided for each requirement, catering to organizations looking to bootstrap their cybersecurity efforts.
The idea for cyber tool Framework came from the fulfillment in consulting and consulting
we get to work with a broad range of clients in different maturity stages and
help them be successful, and so cyber tool Framework is really an extension of
that. It's a resource that can reach a bigger audience and make a bigger
impact than myself individually. So cyber tool Framework helps to address the growing need
for ot cybersecurity education and enablement, particularly among organizations in the early stages of
developing their cybersecurity programs. It aims to empower these organizations and practitioners to make
informed decisions and cut through the noise of shiny marketing white papers. I strongly
believe that education and enablement outside of furthering regulation or mandating secure cyber design,
education and enablement is one of the big pushes that can improve our overall cyber
resilience across critical infrastructure, helping organizations and people make the right decisions at the
right time, utilizing what they already have, i e. Working smarter,
not harder. And at the core of this is knowing what you have,
knowing how it functions or communicates, Understanding what systems or risk cause the worst
case scenario, and then going through a risk reduction process like six two four
four three three TOASH two PHA or CCE that reduces risk to an acceptable level
as you select these mitigated controls to get to an acceptable level. Cyber tool
Framework could be one of these many resources to help organizations or practitioners navigate that
landscape. I don't have outstanding statistics on who listens to this podcast other than
you know, we get about three thousand downloads per episode, but anecdotally,
just talking to people at events and whatnot, the sense I get is that,
you know, maybe one third, give or take of our audience here
is engineers who are coming into cybersecurity responsibilities and have to come up to speed
on cybersecurity issues and approach you know, again, roughly one third give or
take is it people who have become responsible or are becoming or are interested in
becoming responsible for OT security and have to come up to speed on OT issues
and you know, OT mitigations and one third is other. But to those
two audiences someone coming from it, someone coming from engineering, let me ask
you, can you explain for the people coming from the engineering side of thing
who may not have heard of the CIS top eighteen, what is the CIS
top eighteen, you know, before we talk about how you adapted it,
what is it? And you know, for the other sort of third who
are coming from it, who might know the CIS top eighteen cold. You
know, first tell us what is the CIS top eighteen? And then can
I ask you why does it need to be adapted for OT? Yeah,
that's a that's an amazing question. So in security, there are different types
of security frameworks. There are control based frameworks such as COBIT ISO twenty seven
thousand and two CIS. There are risk based frameworks like NIST CSF or standards
such as six two, four, four three three TOSH two. There are
threat intelligence based frameworks like MITER, etc. CIS Top eighteen is a control
based framework created by the Center for Internet security. The same organization that maintains
the CIS benchmarks, which are very popular for system hardening control based frameworks,
give it to you straight. There's no high level process flow chart or models
or hundreds of pages of reading material to follow. They are fairly prescriptive,
requirement based frameworks that list out the what and roughly the how. And the
case of CIS top eighteen, it lists out the top eighteen things organizations should
accomplish from a cybersecurity perspective, again straight to the point. It's one PDF
that's fifty four pages, so it's really digestible. Now, as I mentioned
and as as you know sort of alluded to there, it's tailored to IT
environments, so OT specific controls and guidance are missed. But the CIS top
e te creates a great foundation for OT cybersecurity and tools as well as guidance
to be aligned to. So so that makes sense sort of from the engineering
perspective, what is the c I s A teen? Why is it important?
You know? How does it differ from from other documents in the space.
Can you can you address the engine or sorry, the the the I
audience, you know it people coming into the o T space. You know,
in my experience, often the first question they ask is is, uh,
you know, why not just use everything I know already? I already
know the CIS top eighteen apply it. Why do they need in a sense
application notes for O T Why not just apply it? Yeah, So there's
you know, there's a different methodology in how the CIS top eighteen or cyber
tool framework in this example, would be applied in IT. It may be
reasonably feasible to blanketly apply these these eighteen controls, and you know you would
do so in a risk based approach. However, in OT there are different
tools that it doesn't have. There are many different IDs solutions, such as
Clarity and Drego's, but there's also a different risk based approach in OT that
doesn't exist in IT. We're talking about systems that have different security capabilities,
and we're talking about systems and environments that have different goals, and those goals
are safety and availability first and security second. So you can't just take the
top eighteen and start to address them sequentially one through eighteen. You have to
go first through a thorough risk based process and address them in that sort of
methodology. And so all those lessons learned, all those lessons learned, the
risk based methodology as well as how you can apply these eighteen controls in an
OT environment for OT organizations are outlined on the Cybertol framework website. Andrew,
everything that Jack is talking about thus far makes perfect sense to me, But
it strikes me that this top eighteen and his specific cybertool framework is yet another
framework. In years of doing this podcast, we've discussed so many. He
mentioned a few of them in his answer there, I need a framework for
frameworks here? When should I be focusing on? What? And how do
these all fit in together? Good question, So let's pick it apart.
What is a framework? A framework is a fancy word for a checklist.
Okay. A framework is not a standard that says you must do X,
you must do why you can do Z. A framework is not a regulation
that says you must do X, Y and Z or you'll be fined.
A framework is a checklist saying, have you thought about your wireless? Have
you thought about anti virus? And so when you look at the frameworks out
there, the checklists out there, which of them should you use? Well,
you're going to use most of them eventually. The question in my mind
is where do you start. Do you start with the cybersecurity framework? Well,
you read the framework, and what I got the first time I read
NYST Cybersecurity Framework was the five pillars now six pillars six sort of things,
big picture things you have to think about, and then when you get into
the individual specifics, they refer you to other standards. Oh so it really
is very high level, very abstract, and you know it's it's a bit
hard to use because you have to keep flipping to these other standards. You
know the beauty of So let me let me say as well, you know
i C six two four four three is a standard, not a framework.
You can think you can use it as a framework if you want. You
can go through every security control that six two four four three recommends, and
let's say the three dash three standard. You can go through every one of
them and say should I use this? Where would I use this? But
it's a lot to go through. The value that the CIA Top eighteen brings
is they give you what you know, the experto who develop the framework.
They give you the eighteen security controls to consider. They don't say you have
to use them, they say you should think about them. That's why it's
a framework, not a standard. And they say, these are the ones
that, in our experience tend to be the most valuable. If you're just
getting started, what's the first thing you should do once you start thinking about
security controls? Hit the top eighteen, go through the and you know,
once you kind of wrapped your head around them and sort of the high value
stuff you've got to do, you can take the next step and become more
comprehensive. So this is this is it. You know, framework's a checklist,
and here's a checklist to get you started. You'll keep it in your
pocket as you become more experienced, as your system becomes more mature. But
if you know, if you're a consultant, going into one side after another,
starting from zero, you might wind up using it more often than not.
Okay, so you've taken this sort of very popular almost standard document in
the IT space. You've applied it to the OT space. One of the
things you did was you added a whole column on tools. And I'm not
you know, I've looked through the document. You know, for for anyone
who hasn't looked at it yet, each row, each column of tools is
not one or two tools. You've got dozens listed for each of these security
controls in some of these these rows. On the other hand, if I
look at the next column over sort of the industry application, you almost don't
mention the tools in the industry applications. That seems to be a different topic.
The title of the document is you know, cybersecurity tools. Can you
talk about tools? What's what's important about tools? What you know? How
do we use that that column of tools there? Yeah, so the tools
in version one or the the you know, the m v P Minimal viable
product stage of cyber tool framework. It just has the tools listed in alphabetical
order, and that's to get rid of any any any bias and so later
in a in a version two, we could potentially start to organize those tools
based on certain common criteria. But you'll notice there's paid tools as well as
free tools for each of the controls, and so you know the difference looking
at O T versus I T tools, you can really be seen looking at
something like networking monitoring and defense and network monitoring. In defense, data diodes
are really prevalent and a strong remediation mitigating control on the network side. You
also have, of course, just like IT, you have next gen firewalls
like Cisco Firepower, Fortigate, Palo Alto. But in the third column there
the field notes and best practices considerations. I reference that Fortigate is oftentimes a
really popular firewall in the OT space because of the number of OT protocols that
it understands in its IPS, and so there's nuance to some of these controls
and tools that are referenced that are specific to OT and not to IT.
Continuous vulnerability management is another one, and that's sort of synergistic to asset inventory
where tools like Clarity Drego's Industrial Defender for SCALT, these are tools that help
with asset management, vulnerability management and also act as an idea IDs in these
critical infrastructure organizations. Again, tools entirely unique to the OT space and and
their implementation is unique as well. So there's there's some examples there of the
different tooling that exists in the platform and how that differs from from IT to
OT, the tools call them. I was struck by what you added there.
I was also struck by what you did not add. I mean you
mentioned in your introduction you mentioned, you know, safety and protecting equipment and
you know, environmental safety as as priorities for physical processes that are are being
automated automated by control systems. But you know, you did not mention that
in the the UH in the document, I don't see a row a section
on safety in the document. On the other hand, in the CISA teen,
there's a whole section on UH, you know, protecting web browsers and
protecting email systems and you know, teaching people not to click on links,
which seems irrelevant to the OT space because in OT networks, nobody can route
packets to their email servers. So I'm you know, it seems to me
that there's still something missing here, right, agreed. So you know Version
one was strictly tied to the CIS top eighteen to make it recognizable. As
you mentioned, there's certainly room to add requirements to make it more OT centric.
Safety would certainly be something added to a version two. Supply chain security,
even secure control network and system design. Legacy system security, which is
a huge pain point, comes up in almost every assessment all of these organizations
due to the system life cycle time and the cost to replace a system under
OEM support contract is insanely expensive, so replacing legacy systems aren't always an option.
How do we live with these legacy systems? Maybe even assessment methodology.
Some of the assessment methodology is described under Control eighteen, which is penetration testing,
where I describe how an OT the approach is different than a penetration test
in it. But it's really important that organizations looking to higher third parties know
what criteria to look for so that they get their expectations met. And even
the other controls like physical security could be one that's added. So there's certainly
room to grow these out. And I'm sure you're well aware that there is
a top twenty secure POC Coding Practices resource or standard out there. We actually
have consultants on our team that contributed to that. So maybe down the road
cyber tool framework more and is something similar its own standalone resource or standard.
Can you give us a couple of examples, you know, in a sense,
what are sort of the the the most striking examples in your mind of
of sort of it versus OT differences in applying the cis a team what you
know, what are some of the the uh the key takeaways for you know,
one or two year rows. Can you give us some examples as to
as to the value people get from looking up the document and reading through it.
Absolutely? Yeah. So, taking vulnerability management as an example, there
seems to be a big push or emphasis on cve based vulnerability management in OT
without any additional context. This is evident in the branding of tools that are
sold, the marketing white papers you see floating around on LinkedIn, and and
as we go about our day to day consulting buyer tool and go chase your
tail trying to remediate p cvs. The cvees sentiment is that we mirror the
approach. We loosely mirror the approach of it. However, in IT everything
that is tied to tenable, everything is kept up to date using WSUS and
system refreshes that occur every three to five years. That's a different landscape and
OT and that approach just won't work. This is due to several reasons.
The extended life cycle fifteen twenty year life cycle means that many OT environments operate
with outdated hardware and software that can't easily be patched upgraded, so naturally,
version based cvees can't be widely addressed and security measures must therefore be tailored to
these constraints. You'd probably be better off focusing on other minigating controls such as
network segmentation or allow listing as an example. However, getting back to cvees,
even running agent based scans like tenable and combination with other solutions like AD
and w SUS could in some cases introduce additional cyber fragility into the environment that
could affect the overall availability of the process. So there's a balance to this.
The systems may not be able to support tenable, a D or w
SUS you know, think obsolete operating systems, Windows, CE, or industrial
control systems. And finally, frequently our security teams double as engineers, you
know, take a small utility. We've worked with plenty where network or system
admins who are wearing the cybersecurity hat. They have limited time, knowledge,
and resource, and so all of these real world reality scenarios shapes why are
approach to CBEs has to be different. To fix version based cvees. Patching
will help in some cases, but another is a system refresh is required as
a system itself is too old and so both of which patching or replacing the
system could require OEM approval, and when approved by the OEM, upgrades can
be prohibitively expensive. Miny OT organizations upon analyzing their cyber al, which is
analyzed lost expectancy i e. How much cyber risk they're exposed to on an
annual basis, this cost isn't justified. You wouldn't want to spend more than
your AL on cyber to address that risk, and so you could spend several
hundreds of thousands, if not millions of dollars conducting widespread patching and system refreshes.
Just one of your mini system vendors alone could charge a couple hundred thousand
dollars to upgrade a few of their systems when your organizational cyber al could be
less than that as a whole. Therefore, the cost just doesn't make sense.
A lot of the time you're spending more than your cyber risk warrants,
so you could see the vast difference between IT and OT. So what's one
approach to effective vulnerability management and OT. First we focus on security measures that
reduces our risk, and these oftentimes may not be related to CVS, but
they're important to point out. These are related to reducing catastrophic risk scenarios,
safety system segmentation, secure network design, application whitelisting, et cetera. But
you know, getting back to cvees, we can prioritize high risk, high
risk systems where we may get a great ROI for replacing these legacy systems,
because sometimes replacing these legacy systems isn't just about security, it's the added benefit
of increased availability. And so naturally by doing this we will then greatly improve
our cve tick or so to speak. And then next organizations need to prioritize
cvees that are being exploited in the wild, starting with high risk system high
risk systems. Working their way down. These could be version based or configuration
based cvs. But now we've sort of narrowed down the cvees to a number
that is more approachable by the organization and remeding remediating cvees that will address real
risk, hopefully without spending more than the organization's alite so vulnerability tools vendors they
won't provide this context. It's about addressing cvees within the organizational constraints and within
our OT restraints that exists in the real world. But all of that type
of context or guidance is offered by cyber tool framework. So let me add
something here, Nate. You know, as someone who's worked in the field
for god, it's forty years now and pretty much all of my career representing
vendors, you know, let me let me speak up sort of in defensive
vendors. Jack has indicated that yes, and he's right, patching sort of
what he calls the common vulnerability explosure, the CVE approach. Hatching security updates
can be very expensive. Having you know, industrial vendors approve these updates,
or even you know, test and deploy these updates is very expensive. In
my experience, it's not because you know, the vendors are gouging the owners
and operators. It's because of the different way that you evaluate risk in industrial
networks. And Jack mentioned this that the buzzword he did not mention is engineering
change control. Here's the thing. Every change to a safety critical system,
every change to a critical infrastructure, risks messing something up. You risk making
a mistake. If you make a mistake in a safety system, it's possible
that people die. If you make a mistake in a reliability critical system,
it's possible that you have unplanned shutdowns of your critical infrastructure. And so before
engineers, and we've discussed as many times, before engineers patch anything, before
they make any change in a system, they study the change, they test
the change, and this study, this engineering study, and this engineering testing
is a very expensive process. It doesn't matter if the people at site do
it or the vendors do it, and you buy the test and components from
the vendors. Someone has to do it. It's a very expensive process because
the consequences of making a mistake are unacceptable. And so this is why patching
is expensive. This is why you have to do it differently. This is
why all these compensating measures are so much more important in the OT space,
in the IT space. His framework got it right. He's got the compensating
measures in there that you have to evaluate. He, you know, maybe
was a little bit soft on the why, but you know that's feedback for
Jack that we can provide for future versions. Can we talk about I don't
know, applicability. A small shoe factory is a very different animal to secure
than you know, a high speed passenger rail switching system. Do you mention
this in this version of the document is sort of the the the difference between
the different sort of consequentialities, if that's a word, is that sort of
taken into account? Yeah, great question. The and this really ties back
to al which we we just discussed. These these organizations, depending on you
know, their sector or or their size, they have different anulyzed lost expectancy
and so you don't want to spend more on cybersecurity to remediate risk that that
would cost more than your your al E and you know in a in a
version two, I think it would be interesting to sort of create a baseline
of of controls for different size of organizations. So if you're a small if
you're a small organization, you should aim to do these three things. If
you're a medium sized organization, you should aim to do these five things.
I think something like that would make cyber tool Framework that much more actionable.
But no matter what size of organization now you are or what sector that you're
in, when you're using a tool like cybertool Framework, the first step should
be conducting a thorough risk assessment to identify the most effective mitigating controls. So
let's suppose this risk assessment determines network monitoring and defends as a priority the organization
already knows what they have. They documented data flows, they determine that there's
too much bleedover from it to OT. Maybe a DMZ makes sense. The
network infrastructure itself isn't hardened, we aren't using centralized authentication like radius we're missing,
or we're using S and m P version one, etc. So the
organization would then reference cyber tool Framework to understand and how to implement this requirement
comprehensively. Addressing this requirement from a people, processes and technology standpoint, the
governance driven by the people defines the organization's risk, appetite, standards, and
budget, which then in turn influences the selection of technology, and then these
processes then guide how the chosen technology is implemented and maintained. So this integrated
approach is how cyber tool Framework is used effectively, not a rigid checklist,
but a flexible resource reference to help organizations identify specific risks. The cybertool Framework
preface emphasizes that the eighteen requirements aren't meant to be addressed sequentially from one to
eighteen. Instead, it should be based on risk, so risk really answers
how these controls are ranked or applied however, risk aside. You know,
yes, there is a sort of natural ranking in my and I would follow
the nest CSF identify, protect, detect, respond, recover functions in order.
Requirements like inventory and control of hardware and software assets would likely be first.
Knowing what you have leads a good foundation for you to now address other
requirements like secure configuration of enterprise assets and software, which would fall under the
protect function, and then of course under each of these requirements. I do
discuss maturity loosely, but again I think this could be further built out.
For example, looking at network monitoring and defense, a small organization may aim
to establish it and OT segmentation best practices like a DMZ BEMN segmentation have their
configurations and rules audited by a third party your SaaS where medium to large organizations
that may have a higher risk profile should aim a little bit higher, such
as sending firewall logs to a SIM or using something like a data diode,
Analysts or an MSS analyze these logs continually deploying an IDs and the DMZ and
then subsequently other network zones, and then you know, using things like active
defense measures like honeypots. Maybe something like finist canary. So future enhancements Decyber
tool Framework will include, like like I mentioned, more detailed baselines that tie
to organizational size size to these reference controls. But this is still a work
in progress. If I might switch gears, let me ask you a hard
marketing question. You know, it's it's great, it's tremendous that you're out
there creating this knowledge, But bluntly, you know, those of us who
write things down create knowledge that's of limited use if nobody ever reads it.
How do you get the word out? How do you tell you know?
How do you how do you let people know that this resource exists? Another
great point, you know, right now we have analytics on side vibertool framework.
So last month around one hundred people we're using the platform. So there's
a natural progression and growth there. But down the road, Cybertol framework,
the aim is to have it be integrated with other solutions that I believe could
add a lot equally add a lot of value to the community, again,
particularly in the education enablement of OT security. This will enhance the overall impact
of these resources being unified and give it more weight if you will. But
you know at NY eight keeps me pretty busy, so I don't plan to
embark on a major marketing tour for the time being. However, there is
that old marketing saying that a great product is free marketing, and so as
I enjoy putting these resources together, I truly hope that they help other people
and organizations navigate the OT security landscape. And you know, right now I'm
content with that. Can I ask you looking forward? You've talked about a
version two a couple of times, and what might be in there. You
know, we've talked about about getting the word out. I mean there's other
I don't know, there's other podcasts you could consider. I would I would
recommend you when any any of the listeners go on your cell phone to the
Beer I Sack podcast. It's not really a podcast, it's a list of
other podcasts. Every industrial security podcast that I've produced is in that list.
But it's a list of other you know, useful content out there in the
in the podcast space and who puts it out. So can you talk about
the future, What is the gleam in your eye for version two and how
you're going to get the word out for it. I definitely feel cyber tool
Framework deserves a version two where we first introduce ICs specific controls as you mentioned,
safety safety system segmentation, secure control, network and system design, legacy
systems, curious assessment methodology, etc. Second, we could loosely rank the
requirements on a maturity scale, and then within each requirement we could create baseline
or sub requirements that align to organizational size. And we discussed this earlier,
but I think this would make this resource more actionable and tailored. So if
you're a small organization, you should be able to meet this threshold. If
you're a medium sized organization, there's a higher threshold for you, and so
on and so forth. Finally, maybe there's a methodology for ranking the cyber
tools themselves. Right now, all the tools are alphabetical to keep any bias
out, But down the road, it would be interesting to rank them based
upon some sort of common criteria. But before or maybe after version two,
as I mentioned, I want to look to implement other resource ideas and sort
of combine them and do a rebranding to control Shield, which I think is
a sexier name than cyber Framework. But for now, I'm just having fun.
I'm you know, I'm learning and organizing my thoughts as I put these
resources together, growing as a consultant and hopefully giving back. Andrew, I
think I know even less about marketing than about industrial cybersecurity. So where do
you start when you're thinking about how to get the word out. It's a
good question, you know. I get questions like this on a regular basis.
We do a lot of face to face events. People come up.
You know, I'm very active in this space. I write a lot of
articles. I've written three books. I didn't start by writing a book.
I started by writing a blog. I started by writing little articles. Today,
what I recommend is put the articles on LinkedIn. Do an article on
OT security every couple of weeks. Get your buddies to comment on the article
that raises the profile of the article. You know, develop a following.
Use that following when you produce your first big piece like fifty page framework and
post it somewhere. You know, get your buddies to diligently, you know,
amplify the comment on and like your your big announcements. That sort of.
If you're on your own, if you're working for somebody, do a
couple of articles and show them to your marketing team. It's their job to
do marketing. You know, more than half the time, they're likely to
come back to you and say, this is this is good stuff. We
want to promote this stuff, and they will work with you to put it
on the corporate blog or amplify it on LinkedIn or whatnot. More fundamentally,
you know, the question is what do you write about? Jack? Here
is someone who came from it, so had some background and has spent five
years in the OT space. And what's he writing about? Well, you
know, he doesn't have thirty years in the OT space like I do,
and he's writing textbooks. He's writing about what he's learned. He's you know,
he's developed a checklist of knowledge and tips and tools that he uses in
his everyday work. This is information he's assembled because he needed it. Well,
frankly, if he needed it, other people are going to need it
too, especially other people coming through the same sort of learning chain as he
did coming from it into OT. And so whatever learning chain you're coming from,
your learning stuff, as you learn stuff, whatever you find interesting in
you know, stuff that you learned that week or two weeks, that's worth
writing about because if it was useful to you, it's going to be useful
to someone else. That's how you get started. And then once you've got
sort of a history of writing and a theme that you've developed, you can
think about next steps and larger assets. But by all means, do get
started. Thank you Jack for joining us. Before we let you go,
can you sum up from us? You know, what are the main points
that we should take away from your cyber tool framework? Yeah, in relation
to cyber tool Framework, it's really in its MVP or minimal viable product stage.
It's currently about forty pages of total content and there's certainly more detailed ad
I have some of this documented for twenty twenty four edits and other version two
edits that we talked about Andrew in this episode. I hope that in its
current form it helps those trying to navigate this nuanced space that is OT security.
You know, those IT folks that are familiar with CIS top eighteen will
be very familiar, and there'll be OT centric guidance for how you adopt CIS
top eighteen for OT and for OT engineers or practitioners that are aiming to digest
more of the IT centric information. CIS Top eighteen is a very digestible framework.
So again, I hope that a resource like this helps to navigate the
OT security landscape. If I may, I'll give a quick overall elevator pitch
to organizations out there. Keep it simple, document your assets and parallel,
and more importantly, document the connectivity both physical and logical. You can manually
cable trace. You could use protocols like CDP, l dp S and m
P. You know, even Mac address tables to help run packet captures at
various segments of your network. To start to develop this high level diagram,
it doesn't have to show every device and a color coordinated visio, but get
a good understanding of your environment. If you can achieve these things, you're
ahead of seventy five percent of organizations at your level. Now look at this
documented environment and break it down into zones. One for IT, one for
IT O, T D MC if you have one one for the OT your
process network, one for each Wi Fi zone and each system zone. Start
there, and now begin a risk assessment approach to identify what can cause a
catastrophe in each of these zones. Focus on those risks, and finally break
down your mitigating controls into two categories. Cyber based and non cyber based.
What barriers can you put in place to prevent this catastrophe from both pools?
Now we get to this level, you deserve a trophy, but finally a
shameless plug for atany eightenco at A Tiny eight and COO. We help organizations
throughout the security life cycle, from governance to technology. We assist clients in
starting and improving their cybersecurity programs from the inception of materializing funding, writing policies
and procedures, implementing technology, and conducting continuous assessments vulnerability, risk and pen
testing. We also, of course do advising and recently finished our MSS or
SoC based in Houston. So if you'd like to learn more or have feedback
from me on cyber tool framework that's cybertolframework dot com. You can leave feedback
directly on the site where you can find me on LinkedIn at jack Blitz.
So that just about does it. Andrew for your interview with Jack Bliss,
Do you have any final thoughts that you might want to take us out with
today? Yeah, I mean the resource here is a great resource if you
want to find it. It is on the web. Cyber tool Framework No
spaces, no dashes, cybertolframework dot com. You know the framework. It's
it's short, it's sweet, it's usable, it connects the worlds of it
and OT. It's a great place to get started with concepts you know that
lead into more advanced risk management and other advanced OT topics. And I think
it's great that Jack is doing this. I wish more people would write down
what they're learning, write down, you know, the knowledge that they use
every day for other people to come up to speed and take advantage of.
Well, thanks to Jack for sharing his knowledge with us. And Andrew,
thank you as always for speaking with me. It's always a pleasure. Thank
you name. This has been the Industrial Security podcast from Waterfall. Thank you
to everybody out there listening.