Ep. 184 - ICS Cybersecurity Explained Challenges, Best Practices, and Future Trends with Jason Waits

In this in-depth conversation, Jason Waits, Chief Information Security Officer (CISO) at Inductive Automation, provides a comprehensive exploration of Industrial Control System (ICS) cybersecurity. With decades of experience securing critical infrastructure and navigating the complexities of Operational Technology (OT) environments, Jason offers actionable insights into the current state and future of cybersecurity in industrial sectors like manufacturing, energy, and water treatment.

The discussion begins with an overview of what makes ICS cybersecurity distinct from traditional IT security. Jason explains how OT systems prioritize availability and safety, presenting unique challenges compared to the confidentiality-driven focus of IT. The conversation highlights key vulnerabilities in ICS environments, such as legacy systems that lack modern security features, poorly designed protocols without encryption, and the risks posed by IT/OT convergence.

Jason dives into common attack vectors, including social engineering (phishing), lateral movement from IT to OT networks, and physical access breaches. He explores real-world case studies like the Colonial Pipeline ransomware attack, the Oldsmar water treatment plant hack, and the Stuxnet worm, illustrating how these vulnerabilities have been exploited and the lessons they offer for building stronger defenses.

The video also emphasizes the critical role of compliance and standards, such as ISA/IEC 62443, the NIST Cybersecurity Framework, and CIS Controls. Jason underscores the difference between compliance and real security, advocating for a "security first, compliance second" philosophy to ensure that organizations focus on mitigating actual risks rather than merely checking regulatory boxes.

As the conversation unfolds, Jason discusses the role of vendors and OEMs in securing ICS environments, detailing how Inductive Automation uses proactive measures like Pwn2Own competitions, bug bounty programs, and detailed security hardening guides to improve the security of their products. He highlights the importance of collaboration between vendors and customers to address challenges like long equipment lifecycles and the growing adoption of cloud services.

Emerging technologies also take center stage, with Jason exploring how artificial intelligence (AI) is transforming threat detection and response, while also enabling more sophisticated attacks like personalized phishing and adaptive malware. He addresses the implications of IT/OT convergence, emphasizing the need for collaboration between traditionally siloed teams and the importance of building shared security frameworks.

For organizations looking to strengthen their cybersecurity posture, Jason offers practical steps, starting with foundational measures like asset management and configuration baselines. He explains how leveraging free resources, such as CIS Benchmarks, and creating a roadmap for cybersecurity maturity can help organizations of all sizes navigate these challenges, even with limited budgets.


Timestamps
0:00 – Introduction and Overview of ICS Cybersecurity
3:15 – Meet Jason Waits: Background and Journey to CISO
6:45 – What Is ICS Cybersecurity? Key Differences Between IT and OT
10:30 – The Importance of Availability and Safety in OT Systems
13:50 – Challenges of Legacy Systems and Long Equipment Lifecycles
17:20 – Attack Vectors: Social Engineering, Lateral Movement, and Physical Access
20:10 – Case Studies: Colonial Pipeline, Oldsmar Water Treatment Plant, and Stuxnet
25:35 – Compliance vs. Security: Jason’s “Security First, Compliance Second” Philosophy
30:00 – The Role of Vendors and OEMs in Cybersecurity
34:45 – Inductive Automation’s Approach: Pwn2Own, Bug Bounties, and Security Hardening Guides
40:00 – Emerging Technologies: AI in Threat Detection and the Risks of Sophisticated Phishing
45:10 – The Growing Adoption of Cloud in ICS and Its Implications
50:00 – IT/OT Convergence: Opportunities and Challenges
55:15 – Practical Steps for Organizations: Asset Management and Roadmaps
1:00:10 – Building a Security Culture: Collaboration Between IT and OT Teams
1:05:30 – Future Outlook: Increasing Regulations, Ransomware Risks, and Innovation
1:10:00 – Using Cybersecurity as a Competitive Advantage
1:15:00 – Closing Thoughts: The Need for Continuous Learning and Proactive Action

About Manufacturing Hub:
Manufacturing Hub Network is an educational show hosted by two longtime industrial practitioners Dave Griffith and Vladimir Romanov. Together they try to answer big questions in the industry while having fun conversations with other interesting people. Come join us weekly!

******
Connect with Us

• Vlad Romanov
• Dave Griffith
• Manufacturing Hub
• SolisPLC
• Joltek

Creators & Guests

Host

Dave Griffith

Dave helps Industrial companies go through digital transformations that pay for themselves.

Host

Vladimir Romanov

B. Eng / MBA - Technical Business Leader With Experience Across Manufacturing & Software Industries

What is Manufacturing Hub?

We bring you manufacturing news, insights, discuss opportunities, and cutting edge technologies. Our goal is to inform, educate, and inspire leaders and workers in manufacturing, automation, and related fields.

  Hi, I'm Birthday To So What is From Everyone, welcome to Manufacturing Hub. Happy ICS Cybersecurity Month today. We've got Jason on who we'll introduce in just a moment. We're going to talk all about ICS cybersecurity. As I was joking backstage live in person, it is the day before Halloween and I feel every time we have an ICS cybersecurity conversation, they're always a bit scary.

So very appropriate for Halloween Eve as we are. Live here. Having said that we want to thank inductive automation for sponsoring this episode If you guys were at ICC with vlad and I guess almost six weeks ago You would have seen us walking around having a bunch of interesting conversations We have the first two of those four episodes live and we'll have the upcoming Other two of them live over the month of November, which we're really excited to go get out.

We've had a bunch of fun, interesting conversations about the community, about 8. 3 and about a whole bunch of other topics that we are excited to get into. With you guys, but everyone without further ado, welcome to manufacturing hub. My name is Dave. This guy up here is Vlad. Our guest today on episode 185 is Jason weights.

Jason will go introduce himself in just a moment, but he's the CISO of inductive automation. And we are super excited to have him on, to go get a slightly different ICS cybersecurity perspective this week. Jason, welcome to the show. Thanks for being here. Yeah. Thank you to have me. Awesome. Thank you so much for taking the time again, Jason.

I think it's going to be a very interesting conversation. I mentioned a little bit off stream that I do have some interesting conversations around cybersecurity with some clients. I know that the amount of those conversations continues to increase. So it is extremely important now. So more than ever, that being said, before we go into that conversation, Jason, could you give us an introduction of yourself, your background?

How did you get into cybersecurity and ultimately What you're doing today at Inductive Automation. Sure. I'm Jason Waits. I'm currently serving as a CISO here. Before that I came up through the IT ranks of a bachelor's in IT doing traditional stuff like systems administration, network engineering worked at a grocery store for a while modernizing their point of sale system, databases, PCI compliance, their network stack.

When I outgrew that, I ended up applying and getting the job at Inductive. Back in 2016. So I've been here about 8. 5 years now. I got moved to a dedicated cyber security role with within my about 15 months. I think I initially came on board helping with network engineering windows and Linux systems administration and running some security tools for pivoting to a dedicated security role.

For the better part of the last. Seven years I've been building out the security program. At this point, we've got a full fledged cybersecurity team. I also run it. We've cloud engineering, systems engineering, network engineering, increasingly large tech presence. Jason, if I can ask you a followup, or maybe a fundamental question, because depending on whom you talk to cybersecurity is. A fairly umbrella term, right? So anything from plugging in a malicious USB key into a laptop, to social engineering, to protecting maybe users or giving proper authentication. There's a lot of different areas. Maybe what's your what is your definition and scope when it comes to cybersecurity?

Like you said, the scope is actually quite large. There's pretty much anything that can affect our digital assets. Any attack from any vector pretty much falls under that umbrella. So we usually break that up into different buckets to make it easier to talk about network security, cloud security, data security, identity security, endpoint security and application security can be like the main six buckets we can carve that stuff up into.

You can have dedicated career paths within each of those. But tremendous degree of overlap as well. And let me ask you, like taking a step back to the educational side, right? So I want to be cognizant that I think a lot of engineers or even like leaders that listen to our podcasts and conversations are looking to get more into cybersecurity as we've mentioned, it's going to take up more importance as time goes by.

So maybe. What's your general like thought about, going through the degree path? I know there's a lot of certifications as well. I think, Cisco has a cybersecurity certificate. I think the cloud providers are now coming up with their own as well as, the CI SSB, and there's also standards in the, on the manufacturing and software side.

So I'm curious, maybe if someone's looking or is interested in the cybersecurity side what would you in a general sense recommend? Yeah, there are a tremendous amount of certifications nowadays. The amount of training and certification paths we have now are, it's insane compared to what it was, say, eight years ago.

Fundamentally though, I think, I usually think of cybersecurity as a secondary profession. So if you want to move into cybersecurity, it makes more sense to me and you'll be more effective if you start from another previous career and transition in. So if you design websites, you could transition into website security.

Our control systems engineer can transfer into ICS security, network engineer, and the network security engineer doing the cybersecurity training is awesome. It tends to be almost easier though, than backfilling that, that previous engineering experience that you could be missing. And most of these cybersecurity jobs are around reducing risk, reading and fixing architecture, putting in controls.

It's way easier to do that if you already have the knowledge. Of the career you're trying to change there, you speak the language of engineers, you'll get more buy in because you actually know what you're talking about. Gotcha. And so maybe looking at inductive, right? And I would assume that most of our audience understands what ignition is, right?

Maybe what kind of focus areas do you have? Is it, securing. The sort, the code I guess, that the engineers write. Is it securing the hardware on which, ignition runs? Is it securing the, a APIs that pass the data maybe or collect the data from other devices? All of the above. Maybe could you maybe elaborate a little bit what that looks like for someone who's not as familiar with the cybersecurity aspects for an enterprise software?

Yeah, so I would say my job breaks into three major buckets. I would say I spend about 70 percent of my time on the corporate security side of the house, which is, protecting inductive automation, all the assets we have on prem in AWS, laptops at home, email, data, user accounts. The other next 20 percent would probably be spent trying to secure the product, Ignition, whether through auditing CICD pipeline, where we build Ignition.

Getting security tooling built into their coordinating with bug bounty researchers, penetration testing and other third party firms just to get security and vulnerability is going to found out and fixed ASAP. And the last 10 percent would be more on the customer assurance side. So this would be your compliance certifications being as transparent as possible with the security information, putting on the website, shutting down that loop Making sure people can get, the info they need to hopefully build a, a trusted brand.

I've got many more questions, as we discussed prior to the start, but Dave, what are your thoughts? Absolutely. No, I think it's interesting, Jason. And I want to go back to one of your comments about how you think it's easier for someone to have prior experience, like network to network security, control systems to control system security.

Can you elaborate on that a little bit? And maybe can you elaborate on what you guys, what you as Jason, what inductive automation looks for when they look to go bring someone in on the security side? Because Vlad and I have posited in the past that would be the easiest way to go make that jump, but we don't have, people who have done it more than just once themselves.

So would be really interested if we could talk a little bit more about that and what you're looking for when it comes to that and maybe any advice. We can get to the advice part at some point soon but can you elaborate on that a little bit, please? Yeah, so at a company of our size, we typically look for generalists when we're hiring.

So we look for someone that can run multiple aspects of cybersecurity. They're thinking about risk. They're thinking they've maybe dealt with some compliance certifications in the past, as well as having some decently deep expertise in at least one target area. They were a network engineer for four years, pivoted to a network security role, helped do some audits, responded to threats.

So we look for some people with fairly broad skill sets, which Usually, you know, again, more of a secondary career. They started somewhere. They pivoted. That's definitely easiest path. It makes you more effective. Otherwise, you end up in a situation where you're attempting to convince someone to make a change that you yourself have never made fully, wrapping your head around the impacts of that change, how it affects their workflow.

A lot of cyber security is changing behavior, and so you really got to speak the language of whoever's behavior you're trying to change to be effective. Interesting. Yeah, please. I was going to, I was going to follow up on that, Jason, right? So in my mind, you can either be, and I guess this is once the person is at the at the site, you can either be proactive, so to speak.

And there's a lot of research involved. I'm assuming to understand what threats are possible or what threats are, being released into the wild, or you can be very reactive as an organization. So I'm curious. How do you guys approach maybe figuring out once you've brought that person on board what exactly are they even looking for?

Are they more of a researcher or are there more of a, someone who looks, Hey, I've got, a list of alarms. This is what I should be fixing or a list of obsolete parts, devices, hardware, software, whatever that might be. We need to be addressing those. So I'm curious maybe what that dynamic looks like.

Within your team. Yeah. So right now we're shaping up into two kind of three core verticals within the cyber security team, one being GRC, which is governance, risk and compliance. So that's the audit function, aligning to stuff like sock to or ISO certifications and doing kind of more formalized risk management.

The next one would be what we call enterprise or corporate security. So that is the function focused on proactively identifying vulnerabilities misconfigurations. Or risky assets and getting them fixed and implementing protective controls. The last one would be what we call detection response, and that's the ongoing nature of detecting threats, responding to them and ideally automating that full cycle.

And so that detection response team is the one that's a little more adversary facing, like tracking what threat actors are doing, making sure that our controls and detections map well to what we're seeing in the actual threat landscape out there. Whereas the enterprise side of the security house is more focused on interacting with employees and engineers and making sure everything they're doing is, following good baselines within our policies.

Gotcha. And when it comes to compliance, right? So I think the obvious advantage of being compliant is obviously reducing the amount of breaches that you'd experience. But I think the non obvious items and I would like to. For you, maybe to fill these gaps in. But number one, I think insurers are going to be looking at you in a very different light but also your either suppliers, or buyers of, obviously not just inductive, but other companies would be looking at you differently if you're SOC two compliant.

But. Maybe what are some of the advantages of going through that process and making sure that you're secure again, besides the obvious, which is like closing the gaps that you yourself might experience. Oh you nailed it. It's easier to have those sales conversations and to assure customers if you've went through something that's fairly well known and respected, it's.

If we say, hey, we've achieved ISA 62443 certification for the Ignition SDLC, most people understand what that means. They know if they've been through that process themselves, they know exactly what we went. They've got a really good idea of exactly. Whereas if we say, oh no, we largely do all that stuff.

They're going to have a lot more questions about how, like it feels better when you can speak the same language. I would make the point though, that compliance is not security. I think good security engineering begets compliance but not the other way around. So we've taken a very pragmatic engineering focused approach.

Focus on reducing the risks and building good systems that are well hardened and with good detections and that naturally flows really well into compliance. We don't chase compliance for the sake of making it easier to talk about because you can fall into a deadly little trap there.

Interesting. I like this. I want to take the opportunity to go ask a question that I promised to ask at the very beginning of this conversation, Jason, and we've got into the corporate security side a little bit, but can you tell our listeners at home what a CISO is? And what some of kind of the general job responsibilities are and how it may different for differ from some of your previous roles or from some other people who aren't in charge of what I imagine is all of the risk and all of kind of the vision moving forward.

Yeah, so I guess I see. So in most companies ends up being a risk manager at the highest level, typically with some degree of oversight and control over engineering. Completely varies by industry a if we're talking like, financial or FinTech, CISOs are going to be much more compliance driven than another industry.

If we're talking software companies like us, much more tech focused and engineering focused. But every industry has got a different slant on it. Every company has a slightly different use case for CISO, but. For me, it tends to be about engineering security, protecting the organization as a whole, securing the product, and just doing general risk management across the entire, um, the entire company.

If you're in like a lower role, let's say you're a director of cybersecurity, you tend to be a lot more focused on just running the security tools and doing stuff within your little silo. But moving up to a higher level role like a CISO, you get the perch of the entire business. There's risk all over the place that might not be directly cyber focused.

That's like stuff like fraud. You can help streamline onboarding practices. There's all sorts of little side adjacent areas of risk that don't roll up perfectly underneath cyber security that would be missed if you operate from a lower level. Vlad,

you look like you have a question. Yeah, absolutely. I think, as a follow up, right? So at least in my experience, the OT side, at least of manufacturing has traditionally been, I don't want to say averse to cyber security. And obviously we're talking corporate cyber security as a whole. So I'm curious, maybe in your conversations, are you hearing I guess the need to be cyber secure?

Of different organizations, right? Not just inductive in this context, more cyber secure, or do you still hear a lot of pushback from maybe the OT focused organizations that at least, are still within the circles of inductive pushing back against these practices? Do they even care about some of these certifications, right?

What kind of conversations are you having maybe with either CISOs or, VPs or directors of IT or cybersecurity in some of the other companies in our space? Like you mentioned, I think definitely some of the OT side of the houses were maybe more cybersecurity averse. They were, in their own world.

But with the whole, IT OT convergence thing that's been going on for a while as these things increasingly get blended together. Increasingly we're seeing IT teams work with OT teams or take ownership of some degree of OT assets. I think cybersecurity is naturally slid into that picture.

We're definitely seeing increased scrutiny from our customers. You can look at, there's been a handful of random ICS Breaches or adjacent breaches, stuff like colonial pipeline, things like that have definitely made national news. Increasing regulation in this area is really driving everyone to think about it and talk about it.

So we're definitely seeing definitely. It's definitely any gap that was there starting to close. I think historically, O. T. Has been protected by air gaps. We've a lot of stuff that just off to the side, more or less unreachable. Increasingly, those air gaps are going away as people want to take advantage of stuff like, cloud compute, AI, other services.

They just want to tap into their s. O. Provider. Their corporate logging tools, dashboards for analytics, people are tearing down some of these traditional air gaps, bridging this stuff together. As a result, they have to think about cybersecurity a lot more. Let me ask you, maybe even on your infrastructure side, and in a general, like in the manufacturing or OTIT industry, right?

I think there's different. Concerns depending on whom you talk to, right? And those could be, the fact that let's say hardware remains there for 30 years. So obviously it becomes obsolete and very difficult to protect. There's obviously always the concern, which again, surprises me a little bit of data breaches, right?

If my palletizer data gets somehow stolen by a malicious actor, right? Maybe it doesn't. impact the production as much as if it's some pharmaceutical level data versus the more obvious, right? If there's actual downtime, if someone hacks into a PLC and shuts it down, or is able to write malicious code or bypass safety.

So I'm curious again, like maybe what kind of threats you're. Team is concerned with, and also on the side, what kind of threats do you see other leaders in, similar functions talk about on the on the OT or IT space in in manufacturing? Yeah. On the IT side, we typically focus on the CIA triad, which is confidentiality, integrity of data and availability on the OT side, we definitely see that huge emphasis on availability, on reliability, on uptime safety's, paramount.

So some of these systems can't go down as some of these, massive outages could cause potential lives to be at stake. So the stakes are much higher. So that focus on uptime, though, seems to, the major driving force for a lot of industries. And it's super interesting, right? To be honest with you, and I've had this conversation even with hardware vendors, right?

Because it seems that the expectation of the end users is such that they need to be able to protect the hardware for the next 30 years. And it seemingly is. Again, if you've tinkered with networks, if you've tinkered with, hardware, how difficult and challenging that might be. So I think it's It's very important to have those conversations, but I'm not necessarily sure it's it's possible to place the ownership on the vendor, whether that's hardware or software for that matter, to protect in perpetuity.

So I'm curious, maybe how you guys are addressing that challenge, right? And again, the question is also, how do you see the industry tackle those, I want to say, inherit. OT problems, but obviously in our space touches IT as well. Yeah. As I started to familiarize myself more with this space, it was some stuff was pretty mind blowing initially learning that like the way some of these protocols operate, the inability to ever use encryption for some things, you have an entire world that was when I started inductive completely foreign to me, built with no security in mind and no easy way to backfill security to that in industries that operate.

Crazy long update cycles. We try to patch everything every month. Something's patched daily. Some things are just destroyed and rebuilt from scratch all via code. And so to go transition to talking to customers that are deploying something hardware and software. And getting that particular implementation of everything certified by a bunch of auditors and planning to leave that for 5 to 7 years, so they don't have to go through that bureaucratic process.

, windows for maintenance. It's it's pretty mind blowing to me. From a software perspective. That puts a lot of pressure on us to fix bugs as fast as humanly possible and to find them. That's why we do stuff like bug bounties and penetration testing. We've got robust QA, we build security tools into the pipeline because any bug we can find before it ever even hits the product.

Saves a customer from having to patch, especially if they're on a crazy long cycles as good as we are, even if we can do a same day patch to something we reported by a security researcher, there are a lot of customers that are then fundamentally in a position where they're going to ignore that for you.

That's probably the most frustrating, crazy thing I've had to wrap my head around. We can have an immaculate response to something, and it might not be able to protect some customers who are. Got to wait it out. That's been the crazy part that is an absolutely crazy part. I would agree with that.

Jason, we have a question from Anton that I'm going to go ahead and read and I will let all of our listeners know. We've got a. Couple of dozen folks live here with us. If you've got questions, probably for Jason about ICS cybersecurity, but also for Vlad and I about anything else please feel free to go ahead and drop them in the comments.

We will do our very best to go ahead and answer them. Or you guys are more than welcome to go back and forth in the comments as well, especially for any of our newer guests here. But Anton writes quick question. Compliance requirements are made to ensure proper controls in place and make industry more secure, but sometimes make some companies implement controls for compliance that don't work in real life, more so just on PowerPoint and less so in real life.

And I realized we've given you perhaps slightly a bit of a bomb or a grenade there with our first guest question, but would like to get your thoughts on that, please, Jason. Yeah, I touched on this earlier, but my approach are one of our security values here is security first, compliance second.

And that's because doing things right will typically lend well to satisfying compliance demands, but being too compliance driven can put you in a situation where you are chasing checklists and creating paper policy that has no enforcing control behind it for the sake of an audit. And you end up Yeah, spinning your wheels and creating more gaps.

You can look at every major breach you hear in the news and Google that company and find out what certifications they have. Probably have compliance out, out the year. They have everything under the sun, still happened. So good security engineering and just being extremely pragmatic about how we address risk is always my number one priority.

Haven't gotten much pushback on that. The compliance stuff naturally layers in over time, but it's definitely, I much prefer to implement a control and then codify that in policy that describes how that works, but you start with that control. So it's actually enforced in real time, as opposed to starting with a policy that's completely unenforceable that gives you the illusion of reducing risk when in practicality, it does nothing.

That's been our kind of approach. It's worked well so far. Absolutely. Let me ask a bit of a follow up to that. So Jason, you mentioned earlier how one of the shocking things coming into this industry is like the slowness of updates or the we don't update hardware because it's worked for the last 50 years.

Why would we update any of this hardware approaches that I feel we all see? I imagine. From the inductive side it's an interesting kind of balance or dance, right? You guys can go push hour after or day of code changes, but that requires end users to go take that and update their software.

And then there's, stacks and stacks of different hardware from, maybe half a dozen different generations of technology on the it side and the OT side. That just me saying it seems complicated. How do you guys balance that? Because I'm sure you have conversations with end users and clients about this is what we can provide.

And beyond that, there are other risks, compliance, other Items that one has to look at to make sure that they are cyber secure. How do you balance that? Or what are those conversations look like? I think the biggest thing we've been stressing is just put yourself in a position to patch whenever you're building new architecture, you're planning new stuff, make sure you bake in some way that you can do maintenance on that on some interval, otherwise.

In cybersecurity, there's always situations where you have a system. You simply can't touch makes too much money. It's too important. It's too brittle. You can look for choke points around where you can build in a relatively decent level of security. Maybe if that system is only accessible via.

Some kind of a mesh VPN client that does a posture check to make sure you're a company on device. You have to tap a YubiKey or something that requires physical presence on your laptop to even access that. But sure, a system could be woefully out of date. If you can adequately, silo that off the rest of your network, you can get the same thing.

And then we'll, use a penetration test or some third party to validate that the controls you put in actually work. You can effectively minimize that risk, even though you're not in a position to patch. Definitely just push people to deploy detective controls, things that can't break things.

Get some basic alerting on that stuff so you can at least respond if you're not in a position to patch. But there's an adage in security we say prevention is ideal, but detection is a must. So there's a lot of detective controls you can invest in that will pay dividends for the situations where you can't make changes.

Let me make the comment, Jason. I'm assuming that, inductive is not liable for the downtime that could incur if someone were not to patch. But at the same time, I'm sure you receive a lot of comments when things do go down, and obviously after investigation, I'm sure they will realize there's been a patch that could have prevented the downtime.

But what I do want to ask you is, how much do you have to educate those customers on cybersecurity or is it something that you see them. Inherently understand and maybe second part is who is typically on the customer side responsible for making sure that these things are done right?

Because again, you mentioned multiple parties that can obviously assess come in and audit, but I just personally, at least don't see that happening as much as it probably should. In the at least the manufacturing space. Yeah, we, look, at the end of the day, we make a platform. So what you do with it is up to you.

So it's ultimately the customer's responsibility for how they deploy ignition, what they hook it into and reliability thereof. This is further complicated, though, by integrators and distributors that have different, definitely have situations where someone comes in, they get a job, they deploy the thing, and they go, maybe they're on call for support.

Very interesting, though there's definitely a mix between our customers. We have crazy large fortune 100s that have insane security and engineering teams that, they're capable of deploying and responding and doing extremely sophisticated stuff on the flip side. You have, water plants in small cities, maybe no, no dedicated persons on site.

So there's definitely, definitely see the smaller teams being the one struggling with. Boots on the ground meeting compliance regulations, having any form of cybersecurity. The larger works tend to be well staffed and capable of handling that. I don't think we, those conversations definitely come up through sales engineering.

It's usually more around of it tend to be more. How can we do this with ignition? How can we meet this compliance certification with ignition or architecture reviews to style stuff? And we can guide people, but ultimately it's up to them how they handle it. There tend to be a million ways they could do it.

Yeah as we've, discussed not too long ago, I think it's a very interesting dilemma, especially because again, ignition bridges, the gap or the divide between O. T. and I. T. and depending on how their architecture is, it could be on a network that is completely disconnected, then becomes connected or is, you VPN firewall server switch, right?

There's so many. I think ways to accomplish the solution that you're not simply dealing with, just a mobile application and a data center with a server, right? You cannot necessarily expect them to have the same level of risk and on the same side, right? The risk of, let's say Facebook not serving ads is a very different risk than, a factory potentially damaging equipment and, or a worker.

So I, I think It's a very special dilemma. You find yourself with the Jason. So I'm only I can only imagine some of the conversations. Is there anything, are you able to again, obviously without divulging anything secret, any interesting, maybe. Items that you've seen in the field or any interesting stories that have been solved that you can talk about?

Honestly, so nothing comes to mind. Ignition tends to not be the reason anyone has ever got hacked to my knowledge. It, these things tend to not be publicly exposed to the internet. And even when you hear of some major issue around a water plant or a power grid, they tend to not be overly OT specific, right?

As in the initial entry vector still tends to be routine IT stuff. A systems engineer got phished and he connected to the plant floor and malware essentially followed him or someone was using team viewer or a VPN exposed to the world with weak credentials, or they're using some kind of a firewall that was unpatched.

So attackers compromise a firewall and just laterally. That's mostly what we're seeing is most these major famous ICS style breaches. still are coming from the IT side. I think there were a couple of, there was a water plant one on the East coast where people did put PLCs on the internet or something, but we typically aren't seeing that too much, and we definitely recommend you do not expose ignition to the public internet, let alone PLCs.

I know that we have a forward looking question, but maybe do you see more breaches happening on the OT side in the coming years? Is that something, manufacturers should pay attention to? More attention to I know that a lot of systems run on, I think Microsoft announced their discontinuation of Windows 10 support.

I believe like earlier this week, 2025 and I still see Windows XP, releases out there on the plan floor. So I think it's. It's really the control software that is the problem. It's a lot of times, the OS, the drivers that run and connect the data that's being passed. So do you see an increase maybe of those vulnerabilities in the OT and NIT space for that matter?

But yeah, definitely be an increase of that stuff isn't getting replaced or ripped out. Like I said, Windows 10 is EOL in about a year now, still tons of Windows XP and 7 out there. Increasingly, though, I think there's a common thing in cyber security to where we say defenders think in lists, like the compliance checklist, attackers thinking graphs and in order to beat the attackers, we have to think in graphs.

So you have to think of how your architectures built and how can you move through that architecture to get to save the plan and making sure you have those choke points in place to prevent that. So that even if when you're running that stuff, that's wildly out of date, it's impossible to get to realistically.

Interesting. I've never heard that analogy. So in graphs, meaning that they're trying to, Kind of attack from different directions and then traverse where they need to get to through devices. What do you mean by thinking graphs? In that attackers or defenders are thinking of if I have these 171 controls I need to implement, checking them off down the list, but attackers don't care about those controls.

They need to go from point A to point B. We'll take any route they can get there. So not uncommon for people to hook a test system to production. And then they go that was the test system. I was like if it was hooked to production, it's a production system. We saw that with the Microsoft breach that happened.

Was it last year they were hacked by, was it China? I think, or Russia. I think it was China had a test system hooked into production and came through there. So irrespective of any compliance checklists and anything, the shortest path is the way the attack will take. We'll take any path.

Interesting. I love that analogy. Jason, I want to go ask you, we talked about penetration testing. We talked about compliance. We talked about certifications, which I think lots of, the fortune 50 fortune 500. Those groups generally have money to do that, but you also mentioned a lot of smaller groups like water, wastewater, most sub 50 or a hundred million dollar a year facilities.

They probably don't have a they probably don't have a full time CISO. They probably don't have a person full time looking at. Cybersecurity. Do you see, do you think we're going to find more parity in there in the future? Do you think that those groups will have to find money and time to invest in that?

Where do you see that going, especially for the smaller groups? So increasingly large enterprises or corporations certainly invest more and more in cybersecurity. There are more regulations and compliance coming. Most people realize this is super important and it's They want to avoid major issues, but the small, water plants, the small government stuff.

They're in a different level of bureaucracy and budgeting. I don't think there's a short term fix or any of that. Yeah, I would have a more cynical response that yeah, probably take a couple of major things to go wrong before something around there starts to change just from my vantage point of what I've seen across every industry tracking all this stuff for the last decade.

Absolutely. I would agree with that. I hope that we see those groups spend more money before it's too late and they just go out of business. But I would agree. I also don't see the impotence, at least in the US over in Europe. They've got some interesting regulations coming out that will force some of those both on the physical asset side, as well as the cybersecurity side that have some teeth in regards to what fines are going to look like.

And so I am hopeful that we'll see maybe some of that coming. Over to North America, but I think that we would need something like that. And maybe also a government agency to go find people before we see a lot of these groups going down the path of investing the time and the money into that so thank you, Jason, before Vlad asks the next question, we do have to, we do want to thank inductive automation for sponsoring this episode, as well as having Vlad and I out for ICC six weeks ago.

If you guys want to catch Vlad and my reactions live all the way from before through after, and we've got about half of the episodes that we've shot out, please go ahead and check us out on manufacturing hub. I look back, that starts episode 179 is Vlad and I, or I'm sorry, 178 is Vlad and I. I'm talking about our previews for that.

It was Vlad's first ICC. And so I feel like Jason, every time we had a guest on at some point, I just turned to Vlad and I'm like, Vlad, we're now 30 minutes into ICC or Vlad. We're now two days into ICC. What are your thoughts with that? So we had an awesome time again. Thank you for inductive automation for doing that, for sponsoring this episode and for.

Having Jason here with us at the moment to talk all about ICS cybersecurity. Vlad, what do you want to ask Jason? There's a good question in in chat upon which I want to expand a little bit, right? So Dan is asking, what is a good recommendation as to the source to find tools or procedural guidelines for taking on penetration testing?

And to expand on that a little bit, Jason, right? So I, and again, as we've discussed a couple of times now maybe you realize that not all companies in our space are postured well enough in in cyber security. So if someone is a technical contributor, right? So it could be from an engineer all the way up to a decision maker is looking to understand maybe where do they stand not just in compliance, but also in.

In reality, right? What are some of the steps that you would maybe recommend them take in order to, again, just assess, not even remediate some of those items, but just understand where does the organization currently stand? Yeah so I definitely want to start with penetration testing per se typically where we start with anything in cybersecurity, you start with asset management.

So first, understand what you have. Then you want to pivot to configuration management and understand how that those things are configured. Like for us, we like to align everything possible to the CIS benchmarks. Which are you get them online for free. Just lists of things. You can ways to harden a windows or a Linux system or even stuff like Google.

Then from there, we, you can do vulnerability scanning, which is where you start to look at the exposure of these assets, like what's out of date software packages, what vulnerabilities are in play weak encryption methods. And typically penetration comes in later when you're trying to validate the the controls you put in place.

So if you haven't even put in controls in place, you typically wouldn't even bother with penetration testing. I would start by hardening the environment specifically as it pertains to ignition. We have a security hardening guideline, follow those steps, list every, configuration you can make. Out of the box, if you've got a new Linux server running ignition, do your best to align that to like the CIS benchmarks, follow the ignition hardening guideline, you're in a really fantastic place if you do that, and that's all completely free.

There's open source scanners like OpenBoz as well that you can use, and there are open source audit tools you can use to audit against the CIS benchmark. Again, all for free. I'll have to do a little bit of reading on the CIS. Benchmarks list. And I believe there's a similar maybe list for O. T. Specific assets, whether that's software or hardware that exists as well somewhere on the web.

But yes, this makes a lot of sense. I posted the link for those who are listening will be in the description and those who are watching it should be on YouTube as well as linked in Jason as a As a follow up, right? So the question for me is again, and I think we've discussed this a little bit before.

I think Europe is releasing I guess an incentive and I guess it's a it's a D incentive to not be compliant, right? So you need to put measure in place in order to receive tax credits. As far as I understand it. What is maybe again, besides incurring your own downtime, the incentive on the North American side, right?

Because I think again, in many conversations, A lot of companies and obviously it seems like inductive is not part of that bucket, but they don't know what could happen and are not investing until they see the tangible downtime, right? And we can obviously read in hindsight what happened, but everyone crosses their fingers and hopes for the best when it comes to their systems, maybe.

So what, what is pushing maybe these organizations to change their ways of thinking? Honestly, outside of outages or breaches, the only other real driver within North America tends to be compliance or new regulation. It's not a great way to solve all this stuff long term because you end up just juggling a bunch of those.

But yeah, there typically isn't a great incentive outside of that. Something bad happened and I never want that to happen again or occasionally some people we definitely see industries learn from their peers. If you see a major breach at a competitor, a lot of their direct competition will immediately up level in a similar area.

So that's nice to see at least, but it's always, again, I've watched this stuff for the last over a decade, 15 years. It's all sad. So we don't typically learn lessons. The stuff tends to come around in cycles. People invest enough to dodge whatever the immediate need is. And then you end up through a cycle of maybe pulling back some of the stuff you put in place.

And then cycle continues. I guess where I wanted to lead with that question, right? And I think again, like Dan asked a very important question on how to, again, like maybe assess the facility. I think the next step is usually in, now that we understand where we are, here's maybe a plan where we would like to be or where we would like to go.

How do we convince upper management to invest either in, more penetration testing, more internal resources, more. Contractors and consultants which I know there's quite a bit more on the I. T. side, maybe a bit less on on O. T., but how do we as an industry also paint a picture of, You know what that ROI is to not solicit the investments, right?

But if you are within an organization and you have those concerns, maybe that is the word like, Hey we need to address this, but we need to find budget and an opportunity for it. Yeah, I think at that point, it's about crowdsourcing all the data pointing out, making the case of what could go wrong.

how much that would cost and pointing out why fixing that proactively could save you a bunch of money in the long run. It's hard to always quantify this stuff, but there are definitely methods to doing that pointing to any peers or other, what are competitors doing? You being inspired by regulation coming down the pipe using any, the other angle is to use security as a selling point, building a brand of, that's Hey, these guys run a good shop.

They've they're well engineered. They take security and resilience and reliability very seriously. You know that does pay dividends in the sales cycle and what industry you're in. I think just leveraging all those and making the case up the chain is worth a pound of cure. That's the whole thing.

Absolutely. I was going to say, I think security as a selling point is a really interesting topic, and I think it's a segue to a part of the conversation that I want to have with what you guys are doing to keep ignition as a product safe. As we had discussed, we've spent a lot of time talking about how do I keep my site or facility safe, but that is not necessarily how you guys keep ignition as a product safe.

And I know that there's a whole slew of things. As you and I had talked about Jason including you guys went to own, which is a really weird thing to say out loud. Normally it's, I'm just typing it or thinking it in my head. But you guys did that in 2022 and there was bounty money and all of these other things.

So I think security as a selling point is absolutely inductive automation, take ignition. Can you tell us a little bit about that and what that journey looks like and how it's. That part of your job is different than how do I keep this ever growing company and organization safe, please? Yeah, we Pwn2Own was a fantastic thing.

We're super thankful to be a part of that. The first one was actually 2020. So for people who aren't familiar with Pwn2Own, it's a kind of a hacking competition where I think it started with iPhones and some other stuff like that. And it was like, if you show up and you can hack this iPhone, you can hack it.

And they just branched out from there. It's funded by the Zero Day Initiative. And they essentially put on these competitions. They get top tier researchers from around the world, try to hack, commonly used software or hardware, and they give them really fat cash prizes, getting remote code execution on something can typically earn 50 or 100 K per exploit.

You have. They buy those exploits and they give the, then they give the the exploit code to the software vendor in this case, us, so we can fix it. So really cool initiative to just make the world more secure. We did the first one in 2020. I think we did subsequent ones in 2021 and 22 as well before they pivoted to, I think, automotive.

It was a great, it was a great I'd always followed Pwnedown tremendous amount of security research coming out of there, really great service to the world. I remember when I got the first email, I'm saying, Hey, we'd like to target ignition. I was like, awesome. I was so excited. It's free security research.

It's hard to get stuff like this in front of the best researchers in the world. And for us, we want to make the most secure product we can. So having people put hours and hours or weeks in time into this, shake out some vulnerabilities. We do our best to fix them. I think for the first one we were pushing out same day fixes for that stuff, which was awesome.

And the researchers love that too, because then we're responsive and actually trying to fix this stuff. We're not trying to bury it behind NDAs. We genuinely want to fix this stuff, future proof ignition. It's been a great process overall. Is that a recurring event? What, what's I guess in the general format, but is that a something People can participate in on a yearly basis.

They do there are different ones. They do. There's one that's more focused on like windows, Mac, Linux, Chrome, and that kind of thing. They have one last year they did automotive, but the ICS one, they did three years running. I don't think they did it last year. This year. I'm not sure what the future is, but they announced a month in advance.

And they take people essentially got to find an exploit TV. Get an invite. Then they show up and they demonstrate that on stage, get their exploit working within the parameters within a short timeframe, they basically grab us all and take us, underground and they disclose it. And we talk about researcher.

I'll post a link in the comments. If people want to check it out. No, that's true. That's really interesting. And that Jason is what I would think of more of a, technology or software group as comparative to what most people would think of as manufacturing or industrial software. So I think that's really interesting.

Were there any interesting lessons learned? Is the bug bounty or a bounty program still part of what you guys are doing with Ignition? takeaways or interesting stories that you can share from that series? Yeah, I think we just we found some really complicated issues bugs, within that thing.

So it's pretty awesome. That was the main takeaway was that style of research is really valuable when we do classic penetration testing. We're paying for time. We find a vendor, we typically find boutique vendors that have stellar street cred will wait all year for their best researcher because we want findings.

You don't want a pretty report. And we pay them for 10 to 15 days and they assess ignition as a platform. With a bug bounty, it's slightly different in that you, 20 or 30 researchers could get invited to a private bug bounty. They can hack away for a month and we're paying for results. We're not paying for time.

We can't guarantee that they'll spend that time there, but you end up paying for the results. So it's an interesting model that gets a lot more eyes on it. The biggest takeaway for us when they pivoted to automotive was we want to keep that pipeline of security research going. So we're actually, I think we're launching our first private bug bounty on the seventh.

So in about a week so we're running a 30 day bug bounty. So they'll invite through bug crowd. They're one of the major top 2 platforms. They'll invite a handful of researchers, 20 to 30 hack way to ignition for a month. We'll buy the results. Fix them and blog about it. We'll keep doing those until as long as it makes sense.

And then eventually, once it's hard to shake anything out of a private bounty, the long term plan would be to open that to the world and just have an ongoing perpetual bounty where any security researcher could come submit a vulnerability through that platform, buy it. That's super interesting, right?

I don't know if that necessarily translates to a manufacturing end user, because I think obviously hacking into production systems and bringing them down could cause some serious damage, but I certainly think that there is a. There's a way of thinking, and you've described it as a list versus a graph that I think, again, a lot of the end users, at least that I've been at simply look at a list of devices, and they go like patch by patch, whereas an attacker is going to find easiest point, which again, could be social engineering to that, it person that just sits at the facility and grants them access to to whatever they need. But yeah I wonder, do you have any similar type of, approaches or interesting advice, maybe where you could challenge, maybe even internal resources to submit vulnerabilities or bugs or create a, how would I say it?

Like a culture of not necessarily penetration testing, but understanding what could happen at a facility and then reported through the right, maybe chain of command versus like waiting for an IT or cybersecurity team or audit to come through. Yeah, so with the bug bounty, it's worth pointing out.

That's strictly for our product and stuff. The scope is strictly defined. But internally for us, we have robust QA to find this stuff internally for other people who don't have dedicated cybersecurity team. I think it's important just to try to, let people know to have some point out where they need to bring the risk to, have an email inbox or person where people can bring potential risks to so that someone can look at them, get those documented and see what you can do.

It really depends per industry, but yeah, you don't want people actively penetration, penetration testing per se, because there's risk for bringing things down. But a lot of security is just good engineering security is quality. When you have really senior engineers, they tend to find, they tend to be great candidates to spot security issues.

You don't have, you can proactively look at things like, ah, that's, That's poorly implemented. The other thing most people can do is just threat modeling, just talking through your architecture, getting people in a room and saying, talking through different components and how they're built and what could go wrong.

And you can shake out a tremendous amount of stuff. Just doing a tabletop like that. We do internal tabletops for business continuity for instant response. We just talk through mock scenarios. And just talking to people, you can find some gaps right away. What would you do if this happened? And you can see who's got a blank, the blank stare.

It's maybe that person needs some more training, or maybe you can uncover a gap. So engaging in threat modeling, completely hands off. You can talk through some stuff. There are frameworks on GitHub. I think it's Stride and Dread. I think we're two of the popular ones for risk modeling and threat modeling.

You just talk through. I would have to do again a little bit of research on that side. I think it was mentioned a couple of times in some of our cyber security conversations, but I've certainly, I've at least not been at in a meeting where that was a very thorough I guess conversation. So I think that's super interesting.

And I'm sure that you've had a lot of Interesting insights in those meetings. Jason let me follow up on, on that. Talking about the culture, right? We've mentioned that at the end of the day, there are an infinite number of tools and lots of things that you can do, but you have to go build or change your culture of compliance, a culture of looking forward, a culture of security.

Can you talk a little bit more about how you have helped to create. A culture of this type of culture at inductive or and maybe what you've seen work and not work in other places. Yeah, great. That's a great question. I think 1 of the best things I did early on is when I got put in a dedicated cyber security position as I just went and met with all the directors at the time and just asked about their pain points.

So it wasn't a specific security specific conversation, but just talk about their pain points. And then at brainstorm, how could I help them solve their pain point in a way that achieves, a security objective of mine. And then you're part of the solution. You're not injecting friction or trying to change someone from behavior.

They don't want to change. You're actually solving the problem in a way that's fundamentally more secure. It's really easy to bake security into a new initiative to finding those areas where you can do something new and rip and replace something and do it in just a much better way that scales Resiliency and security over time.

That's probably the best thing I did was just talking to people and understanding their pain points and figuring in where I could slot in. I think what doesn't work is just coming up with your own list in isolation and trying to like, push this stuff through. At the end of the day, the business exists for a reason to make money to provide a service.

You have to really understand that from the top level and make sure what you're doing. I, I like to function more as a bodyguard, not a cop, like I'm not there to tell people, no, I'm there to protect them on the journey the business has to go on. So we prefer to say yes, but as opposed to saying no, when people are

interested, I guess it. Another thing too is we like to adopt, I think there's a model popularized by Netflix, but this idea of a paved road or a golden path that is find ways where you can build workflows that make people's lives easier that are also secure. So they're heavily incentivized. It's, it's easier for them just to do this thing that is prebuilt workflow to use this automation to use this template as opposed to doing the work themselves to build it from scratch and in a secure way.

They can just grab your, it's like having a developers, it's like having a docker container image, it's pre hardened, you can use this one, it's already pre set up, it's going to save you a bunch of initial setup, you're often running with a secure image in less time than had to configure from scratch yourself.

Things like that have been the biggest wins. I think.

Absolutely. I love that. Vlad. We're getting close to time where I get to ask Jason our fun last final questions, but we have the op and Jason, I always regret saying Vlad. We've got time for you to ask one more question. But Vlad, we've got time to, to have you ask one more question today. What do you have for Jason?

I want to bring back, the education question. I know you've given us a couple of good maybe paths for someone who's looking to get into cybersecurity but maybe to bring us back to a currently working individual that doesn't necessarily want to pivot, wants to pivot into cybersecurity, but just wants to.

Become maybe familiar with the standards understand what are some of the basic steps they could take inside of their organization. And again, they could be in an it space or OT space. What would you recommend as starting points again, maybe not full certifications, but maybe good reading topics just to understand.

The fundamentals. I think if you want to take a crack at looking at what a basic like list of security controls would look like. I mentioned the CIS benchmarks before. Those tend to be specific to certain operating system or certain type of software or hardware. There's also something called the CIS controls, which is a list of, I believe, 153 security controls.

They are I think they're horizontally sliced based on the size of the organization so you can filter based on your vertical and say, we're very small. We have no dedicated cyber security people, give you just like the top 50 if you do anything, do these 50 things every control maps to real world attacks and they update this every year.

I think this was born out of years ago. This was the NSA red teaming, the air force, and eventually the air force got sick of losing and the what can we do to win next year? Does essentially not get breached. And then that's where the CIS controls came from. They eventually got spun out into this nonprofit that runs them.

It's a great list. You can just read through those in there. Each line is a single ask a single thing you could do, and they build on each other. But you can look at the level one controls only, which is have a list of your assets. Do configuration management for those assets. And it just goes down the list.

So that's a great place to wrap your head around the style of controls and organizations. And all the compliance certifications here build on top of something like this, the gauge maturity of doing something like this, the NIST standards, NIST CSF 800 53, all way more robust and in depth. But this is a nice, pragmatic little starting point.

That you could just read through the PDF, in an hour and a half. You have a mental model of what a security stack would look like. Interesting. Really appreciate that. Yeah, I was going to say, I like that, but Jason, if step one is having a list of all of your assets and configure that, we've got a whole lot of work for a whole lot of manufacturers to go.

Yes, if that is step one. Step 49 and 50 are going to are going to take a while in order to to get down there, but no, I agree with Vlad that, that seems super interesting. And I am actually, I will spend some time going going through and and getting Other rundown of it. That seems interesting for all of our listeners.

If you guys are watching on replay, or if you guys are watching show notes, Vlad is really awesome at getting all of these links in the show notes. So if you guys are listening in that format, please feel free to go ahead and check the show notes. All of those notes for all of those links will be in there.

Jason, this has been amazing. As I forewarned you, my most favorite question to ask everyone other than cybersecurity professionals is to go predict the future for all of our for all of our listeners, the last, I don't know, 15 cybersecurity professionals we've asked have given the most terrifying, very spooky, appropriately Halloween themed thoughts of predict the future in regards to us, ICS cybersecurity, but Jason we're going to give you the question, but What are your thoughts in relation to ICS cybersecurity, be it on the product side, be it on the direction that all of these groups are going to need to go, or if smaller groups are actually going to find time and reason to spend money on cybersecurity, lots of topics that we've talked about, would love to get your last thoughts into the future.

I think I would have to keep your streak alive. This stuff gets worse before it gets better. I don't see any like major improvements globally happening in a fashion. I think collectively the amount of information we have available to work with to secure things is better than ever, the amount of training and certifications and classes out there.

And the level of security tooling we have out there is insane compared to a decade ago. So increasingly, there are startups and new vendors that are making stuff that are cheap and affordable and effective for small organizations. So if you put in some time and do some research, you can definitely find, solve a lot of your pain points.

But collectively, this explosion of AI tools and data flowing everywhere and everyone hooking everything together I think it'll get worse before things get better collectively. But we do have fantastic resources and skilled people out there now to take advantage of it. Can I ask you on the AI side, right?

So I, I have this opinion that the social engineering aspect is going to get a lot more interesting. Because simply like AI can ingest so much information, but also, Almost, scan your Facebook, your LinkedIn and create so much more context than before. So I'm curious, is that what you think, like on the AI side, or do you have something else in terms of like better finding of vulnerabilities on the technical side?

Like what kind of maybe attacks are you anticipating happening as a result of. Like AIs, LLMs. You nailed the main one. It definitely makes it easier to social engineer, spin up phishing templates, or otherwise conceptualize an environment and spoof something. Attackers tend to be early adopters of new tech.

They tend to have the initial lead, the initial edge, exploiting this, using it against offenders. Over time, that will, I think the edge will swap to the defenders as, assuming you have security tools in play. Building these things into security tooling can, we're already seeing a little bit of value better detections, suggested code fixes, long term it'll pay dividends for defenders, but short term attackers win.

Absolutely. Speaking of fishing, we just had a fishing attack at my parents house yesterday. I got a text message saying, did we renew our Microsoft office licenses? Because someone, not me who pays for them, got the bill. For five licenses at $700 a piece, an insanely high number of dollars.

And I'm like no, that I absolutely would not be paying $700 per Microsoft license. I have the family pack for a hundred dollars and so I don't know what they were trying to do. Probably get you to click the link. So because it was such an outrageous price, but I agree. They are getting better, which is not something any of us need.

With that but Jason, this has been awesome. We'd like to ask for some career advice. You've given a bunch of really good kind of steps of if you're interested to get into cyber security, go start with some amount of practitioner skill because those are the people you're going to have to go talk to when you transition into that.

But open it broader. Do you have any other. Interesting career advice for folks looking to get into cybersecurity or ICS cybersecurity. Oh, outside of mastering your day to day craft. I think doing some basic security certifications, spinning up a home lab and actually playing this stuff.

If you can't get hands on experience in your current job, you can do it at home. I think that always demonstrates passion and curiosity, which are the number two things. Top two things I look for in a new candidate. Absolutely. I'm going to steal Vlad's question and Vlad probably knows I'm going to steal his question.

Are there a, any particular certificates that you would suggest people to look at any one or two over the rest of them? Not, not really. For us, like in anyone who comes through it at inductive, we haven't do this CompTIA security plus certification, so a nice primer on the general landscape and the verbiage.

Absolutely. Thank you for that. And then, Jason, last question for you is, how can our listeners help you? Who should reach out? To, to either you specifically, and what you're doing on the cybersecurity side at Inductive or Inductive in general, your open your open soapbox in order to go ask our listeners anything that they can do to help you.

I would say if you're an Inductive Automation customer, Follow the ignition hardening guide. A lot of work goes into that totally free. You can put yourself in a really good position there. Also prepare yourself to patch things in the future. That's the main thing. If you have any questions, thoughts, concerns about this, feel free to reach out to me, add me on LinkedIn, happy to chat about this stuff with anyone in your personal life, please, for the love of God, use a password manager.

I

love that. Thank you so much, Jason. All the way around. Thank you everyone for listening. Thank you. Inductive for sponsoring this episode. If you guys are watching on LinkedIn, you guys have access to Jason's LinkedIn as well as Vlad and myself, if you guys are watching on LinkedIn, make sure that you're connecting with all of us and following manufacturing hub for all of the updates that comes out and you guys can go rewatch all of our October episodes, which are all of our ICS cybersecurity episodes.

In the past, all of them have a slightly different flavor. And again, thank you to Jason for coming and giving us that corporate CISO flavor from there. If you guys have made it here on podcast form, you guys are amazing. Thank you so much, everyone. Please remember to do the like, and subscribe and share.

If you're on a podcast player, do the thing where you rate us five stars and hit the follow, because when I remember to ask you guys and Vlad remembers to upload on time, our listeners just continue to grow, which