Security Starts at Design: “Shifting Left” in Industrial Automation

Josh Ross, CEO of Ironloop, argues that industrial automation needs to embed security earlier in the design phase rather than relying only on monitoring after deployment. Shifting left means evaluating configuration changes before they go live and automating risk assessment, which reduces downtime and speeds up audits.
Chapters
Welcome to the Industry 4.0 Club's fireside chat. Club's purpose is to engage the power of diverse worldwide talent to accelerate the global evolution to Industry 4.0. We accomplish this by hosting and supporting respectful, thoughtful, and interdisciplinary open conversations and creating quality content on wide-ranging Industry 4.0 topics to expand the reach of our community. My name is Mike Unger, and I am the CEO of the Industry 4.0 Club. I have over 40 years of management and leadership experience, most of that in manufacturing at Michelin. Our fireside chat this afternoon is titled Security Starts at Design: Shifting Left in Industrial Automation. And to help us talk about this and discuss this topic, we're joined today by Josh Ross, who's a co-founder and CEO of Ironloop. A little bit more about Ironloop. It's a cybersecurity company helping manufacturing, energy, and defense keep operations secure and audit-ready. IronLoop turns industrial machine and network configurations into a continuously updated inventory, change alerts, and compliance-ready documentation so teams can reduce the risk without disrupting production. Before IronLoop, just to talk a little bit more about Josh, he led cloud infrastructure at Applied Intuition, And built enterprise AI products for Foundry.ai. Welcome, Josh. Really glad that you're here to join us today for the conversation.
Yeah, thanks for having me, Mike.
For those of you that are listening on LinkedIn, if you've got a question for Josh or something you'd like to ask him and share, please put it in the comment box and we'll be glad to, to get that question or comment to him so that he can respond while we're talking with him today. So just to kind of get us moving today, Josh, I wanted to ask you a little bit more about yourself. Yeah. So I noticed you have a degree in computer science and economics. What in your past was the trigger to get you on the path towards programming rather than, let's say, economics?
Yeah, yeah, absolutely. Yeah, I, my journey with computer science and programming goes all the way back to high school where I first started learning HTML, CSS, PHP, Java, and really just loved the possibilities that software engineering and programming generally opened you to. There was so much to build, there were so many problems that you could solve, so much creativity that was involved in the process itself, and it really gave you a deep understanding of how systems work. When I got to college, it was pretty clear to me what I wanted to study, and I started doing some software engineering internships, really liked that work, and kind of knew right out the gate that I wanted to go into that world. And so when I graduated, worked at Foundry AI that you mentioned, we were building enterprise machine learning SaaS products for different businesses. It was really cool to build product from the ground up and do it for folks that weren't really being focused on when it came to a lot of modern software. There's old systems from the '90s there, looking at Lotus Notes databases and things like that. And really just learned a ton in that experience. Then went on to Applied Ignition where we were building software for autonomous vehicles, just continued to deepen my technical interest, did a lot of interesting work on security, networking, and hardware that I'd say really led me to the journey that we're on now with building Ironloop.
That's great. Well, so does the degree in economics play into this at all?
Yeah, that's more of a generalist business interest, I'd say. I think there's definitely overlap when you think about these degrees and you think about this work, economics is all about markets and systems. Software engineering and computer science is often about the same things, just applied to different set of problems. And so I really valued that education. I learned a ton. My favorite class was probably algorithmic game theory, where I really got to combine the two in a heavy way.
Goodness. Well, thanks for that. I can only imagine what that class must have been like. That's Yeah, the book, pretty fun. The idea is game theory is pretty cool stuff today, quite prominent in today's economic world anyway. So let's talk, let's kind of get into the discussion around cybersecurity and really start laying the groundwork for what you're doing today. And just how do most companies today handle their cybersecurity approach?
Yeah, it's really different depending on who you ask, and maybe the time of day that you ask them. I think IT and cloud security is one thing. OT security is a completely different thing. When you think about IT security, cloud security, these are industries where cybersecurity has been a focus for, you know, 20-plus years at this point.
Mm-hmm.
It's often about patching systems, maintaining a system of record, keeping security as part of the process throughout the entire development loop as you're writing configuration, writing code, deploying systems, and then once the systems are live, actually monitoring and maintaining those systems to ensure there's no active threats and that they stay secure and don't really drift over time. A lot of those same principles really have just not yet been applied to the OT space. And so when you think about OT cybersecurity, I think today the answer is it's often about network monitoring, anomaly detection, and some amount of vulnerability scanning. When you think about firmware that's running your systems. But from our perspective, security is really not baked into the end-to-end lifecycle of operational technology in the way that it is in IT and cloud.
That's, um, that's interesting. You know, I think having been more on the OT side in my career, I think more about like what we used to have to do. And it's been a couple days— it's been a couple years actually since I was Handling this or involved with this, but we would do a lot of work with individual with people, right? Because there was a lot of it was just you know when someone came into you know I know this isn't shop floor stuff, but still even for individuals, you know it's like how do you respond to to an email that's that looks a little bit nefarious, right? Do you click on it or do you report it? And so they would— we actually had a program where we would end up, you know, really systematically to all of our employees, always be testing to see if they were alert for that kind of thing. Yeah. What's the equivalent of that on the shop floor? Is there an equivalent thing that, you know, that's an office sort of activity when you're behind a computer all the time?
Yeah.
What's the equivalent of that when it comes to the shop floor?
Yeah, no, it's a great example. I think when you think about the impact that individuals, that people in your organization have on the overall safety and security of your systems, it's not a piece to be ignored. It's— I think when you look at the shop floor, what you really need to focus on is what are the ways in which my assets are configured? What are the changes that I'm making? Are those changes first safe and second secure? I think that's another one of the big differences that we see between IT and OT. IT, you're often focused on the protection of data, whereas in OT, you're often focused on the safety of the system. system. And so it's, it's really a different perspective that you have to take. But yeah, when you think about what things individuals on the shop floor should be thinking about, it's, hey, is this change that I'm making backed up? Is this change secure? Am I gonna, you know, trigger any alarms or break the systems if I make changes to the way in which assets are configured or coded, whether it's for networking equipment or PLCs or SCADA systems?
Yeah, I'm even thinking about, you know, we got to the point where, because unfortunately a maintenance technician would bring in a thumb drive and decide to plug it in somewhere, and, you know, all of a sudden they've, they've created a problem. They didn't realize that they had a virus on the thumb drive.
Yeah.
So it's still, still people are heavily involved in this and making sure that we've got safety from an OT perspective as well on the floor, right?
Yeah, absolutely. And a lot of it comes down to if you can get this deep understanding of the way that your systems are configured from a software perspective, you can really learn a lot. It's— you're never going to have a perfect system when it comes to the way in which people are operating with your environment, with your different assets, with controllers. And so you really need to think about, well, what software protections can I have in place? To use the email example, right? We all have spam filters on our emails today. That's sort of that first step of saying, hey, maybe we shouldn't click this email, maybe this email looks suspicious, right? What's the equivalent for the OT side of things? I think a lot of that comes down to, are the changes we're making actually safe and secure?
Yeah, thank you for that perspective. I think this, this, uh, it's an interesting conversation, you know, especially given how fast, uh, things have changed. I want to kind of return to the title we talked about in the title of this conversation today, the idea of shifting left. So what do you— what is it that you mean by shifting left in industrial automation?
Yeah, absolutely. So shifting left is a term and phrase that we often see used in the IT software and cloud world where you talk about moving processes earlier in the development lifecycle. So from a software engineering perspective, this would look like, hey, I should be testing changes before I actually deploy into some production system. I think a lot of the same principles from that way of doing things really can and should be applied to the OT world where if you're again making a configuration level change, you should think about, well, what's the impact of that change from a risk and security perspective before it's actually live on the network and not after? And so when we talk about how can we shift security left inside of industrial automation, it means thinking about the security of your system as part of the design process, not just as an add-on after the system is already live.
Well, when you talk like that, it makes me think about, um, we used to layer— we used to have, you know, we would put a piece of equipment and we would have layered— I'm going to date myself— blueprints, right? So you have the machines, and then you have the, the energy layout on top of that, and the electric, you know, you have Other utilities, but you'd actually show each would have its own drawing, so to speak. Are we, are we talking the same thing now about, like, if I put together a certain configuration of software, is there a cybersecurity layout on top of that? Is that kind of the same thing we're thinking about here?
Yeah, I think it's, it's really integrated throughout the process, right? Maybe a good example is, you know, traditionally, if you're commissioning a new piece of equipment, Maybe you're doing a factory acceptance test before you add that new piece of equipment into your manufacturing line. You are thinking about all the physical processes, all the ways in which you need to test this new asset. Cyber should be part of that conversation, right? We should be looking at the system configuration, the security configuration of that asset to understand, well, what's the impact on the overall security posture of my line once I bring this new piece of equipment online? And so really, I'd say it's this mindset shift of, well, yeah, it is possible to include cyber as part of your assessment in the hopes that, hey, it's going to make you more efficient, it's going to help drive— reduce downtime, it's going to help you restore incidents faster. And so I think the kind of other piece of this conversation, which I'm sure we'll get to, really is about, well, how do I actually derive value from implementing and installing cybersecurity? Into my plant.
Yeah, thanks. I just want to remind our listeners who are listening on LinkedIn that if you've got a question for Josh, please drop it in the comment box while we're live here, and we'll get it to Josh to answer it if we have time. So cybersecurity, you know, it's a— sometimes it's hard to get OT to care about it, right? Because they're focused on some other things. But It's something typically led by IT and then needed by OT. We know today very much so that IT and OT can converge much more often to fully leverage the digital environment in order to really, in order to have successful leveraging of the digital environment. What suggestions do you have for companies and how to best bring IT and OT together?
Yeah, yeah, it's, I think it's really organizational a people and a process problem. The way we like to think about this when talking to customers is really what are the frameworks, what are the metrics, what are the things that we both care about, and how can we almost come to the table together to really find a way to get what we're both looking for, right? IT has a different way of thinking about the world because they're mostly focused on data security. When you're looking at OT security, it's again all about safety of the physical processes, safety of the plant, safety of the environment. And so it's really a different set of metrics that you might care about. And so the first conversation you have to have is, you know, what is the framework that is gonna enable us to work together to converge our systems so that we can both benefit from one another? If you wanna, you know, look into the future, deploy AI inside of your plant, well, how are you gonna do that if you don't know the overall state of your system, have some system of record, understand change management and be able to safely deploy updates inside of your environment. And that's where a lot of the traditional IT principles can really be applied and help one another. But to go back to the original question, I do think it comes down to, hey, what's the common framework and understanding that we can have with one another? What are the metrics that we're going to track from each other to make sure that, you know, we're building and maintaining systems in the way that we want to?
Yeah.
And then from there, we can talk about tools and technology we want to adopt.
I think that's great. You know, I, um, so again, just to make sure that I'm not, um, people don't think I'm living in the present when it comes to the shop floor. I've been a few years away from, from the manufacturing shop floor, but one of our challenges used to be we would ask, we would want to do something as an OT operational team on the floor, And our IT friends would tell us, no, you can't do that, right? And we got— later we got pretty smart because we said, don't tell us no anymore. Tell us how.
Yeah.
You know, to make sure that we achieve our security.
Yeah.
How does IT really become a trusted partner where, where we work from common goals to really achieve the business results? What do you What are your suggestions there?
Yeah, I think when you— to your example, like when you think about IT and what IT has done a really good job of, IT has gotten really good at data backups, for example, right? OT probably still has some work to do there, and there's some great companies working on solving that problem. But I really think it's looking at, well, what are the principles, what are the learnings, what are the metrics that we can share with one another, and how can we really employ these principles in a way that fits our workflows. I think especially in OT, cybersecurity is not necessarily going to be paramount, right? Safety still is going to always come first. If there's tools, technologies, or methodologies we want to adopt in order to be faster and be more productive, it's important for IT to listen and understand. And I think you're totally right, right? The CISO or the IT lead can't be saying no, they have to be saying how. Every change we should understand both before and after what the impact is on the overall risk of our system, on the overall security posture. And that's where a lot of these principles of shifting left, understanding what the impact of change is going to be before you make the change, really come into play and really is important.
Yeah, thank you. We have a question from Ryan. I want to put it up and maybe you can talk to it. Ryan asks, for the potential buyers out there, what is the main difference versus traditional incumbent OT security solutions like Nozomi and Opswap? Hope you know the answer to that one 'cause I have no idea what those two are.
Yeah, for sure. And thanks for the question, Ryan. Really a lot of cybersecurity tools in the OT space kind of came in the wave of post-Stuxnet. So Stuxnet was the US-Israeli cyberattack on an Iranian nuclear facility. sort of this big landmark cyber-physical attack back in 2010, I believe. Nozomi, Dragos, Clarity, a lot of these companies spun up after that attack and came into the space with these network monitoring solutions where they said, hey, let's look for anomalies inside your environment. Let's see what firmware versions you have running on all your different assets. And then from there, we can help you understand whether or not there are attackers in your environment that are actively doing stuff. or if there is outdated firmware that you should consider updating. I think that's a great solution. Anomaly detection is very important, but when we talk about shifting left, that really lives on the rightmost side of the spectrum, right? Because it's only monitoring live events, live traffic, live assets in your environment. Where we kind of close the loop from a more traditional, like, DevOps perspective would be saying, okay, how can we monitor what the security of the configuration state is going to be before we actually ship it? Can we understand what the impact of changes are going to be to our risk profile before we actually deploy those changes? That's where, you know, we think there's a gap in the market today, and that's kind of what we're building towards. So hopefully that answers the question, Ryan.
Yeah, Ryan, thank you for the question. If, if there's a follow-up, drop it in the comment. We'll be glad to continue the conversation on this topic. So I wanted to— we'll come back to that if we need to, but really appreciate that, Ryan. So how can this approach about shifting left improve cybersecurity? Just to talk about that, and more importantly, really save manufacturers money that they can then invest in other projects and other priorities that they've got? Because it's kind of like a lot of this is foundational and necessary.
Yeah.
So do you have any examples you can share about that as well?
Yeah, absolutely. I'm tempted to answer the second part of the question first because I—
Drop in there.
Yeah, exactly. No, I think when you talk about security, it's the same as anything else, right? We have to think about what's the budget, who's going to actually implement this, what resources, time, and money are we going to actually apply to this initiative? And, you know, the question then is, well, how important is this to the organization? And so the way we think about security and, and how shifting left can really drive a lot of productivity gains and why it's a value add is that it's not just security that you're getting from adopting these principles. It's also being able to understand change management, have backups of your system, have a system of record. And so the overall goal is, well, can I actually reduce downtime by applying a lot of these DevOps-like principles into my environment? We think the answer is yes. I think we've seen the impact of our software on end customers already. I think a small anecdote is a defense manufacturer we're working with where a controls engineer previously was making changes. They would deploy the changes to some system. They would then see when they come— when it comes time to do their annual audit, well, okay, I, I've got this change. This is not secure. We have to go back. We have to change, you know, revert this change effectively. And that's ultimately going to lead to downtime. When you think about what it would look like to shift left and how our software actually helped this end customer was they were able to understand what the security impact of their changes were going to be while they were developing them. And that's a complete mindset shift to say, well, now I'm not going to have to revert changes. Now I'm going to understand the impact on risk and safety of the changes before I actually make them and deploy them into my environment. And so really, you can think and tie it back to Well, how much time did they save by not having to revert that at the next quarterly or annual audit?
That's wild. That's interesting. Well, I appreciate you sharing that. I mean, at the end of the day, I think, you know, I hope most manufacturing, all manufacturing leaders, as a matter of fact, understand that cybersecurity is really a foundational item in the digital world today.
Yeah, yeah, absolutely.
You know, we talked, we talked about with smart manufacturing that, you know, digital is the data we have and the digital information we have can be huge for helping to improve results only if, if it's well managed and taken care of, right? And I think taking care of it, one of the ways you take care of it is to ensure that it's safe and secure.
Yeah, yeah. I think as you think about you know, value-add. Like, these are questions you should be asking your vendors, right? Am I buying a security tool that's only helping protect me against, uh, you know, black swan type event, um, and sort of this threat of China, Russia, Iran, North Korea, uh, etc.? Or am I buying a product and a tool or a platform that's really going to help drive productivity gains and kind of help me change my organization in the way that I want to? That, that's really the types of questions that I would be asking when you're evaluating these tools.
That's great. No, thank you for that. Well, we've been talking for the last 22 minutes, 23 minutes or so with Josh Ross from Ironloop. And we're getting towards the end. So again, just one note, if someone has a question for Josh before we wrap up, we're happy to put it up and have him address it. Josh, as we get ready to wrap up here, Do you have a final thought for the audience? Maybe a key takeaway that you'd like to share and just that folks need to kind of remember? If they don't remember anything else from our conversation today, what would that be?
Yeah, absolutely. Yeah, I think, you know, security should not be hard. Security should not be scary. The way that you're going to slowly and over time improve the security posture of your system is by thinking about How can I embed it in all the ways that I work? Everything from design to operations, right? We like to talk about this end-to-end lifecycle coverage of the platform that we're building, and it's true. You know, we think about, well, how are my systems changing? Do I have a system of record? Can I safely, securely, and confidently make new changes and updates to that environment? Will I be able to quickly restore in the case of downtime? All of these things are really important. You know, security should be baked into all of them, and security is almost an ancillary benefit to what you'll get by shifting left inside of industrial automation and moving these practices early and earlier in the pipeline. But overall, you know, it shouldn't be seen as this daunting thing that we can't address. You shouldn't only think about it in the context of cyber insurance and these black swan events. You really should think about What productivity gains can I get by employing a lot of these principles into my system?
Yeah, I appreciate that a lot. I think what you're sharing in general is to be proactive.
Yeah.
Yeah, and really put in place the things that will prevent issues, not react to them. So thank you so much for that insight.
Yeah.
That's wonderful. Well, I would like to thank Josh. Thank you for taking time out of your schedule. I know you've got a lot going on. To talk to our audience today and share your insights in cybersecurity. I know I've learned a lot, and hopefully others as well. Also, thanks to Ryan for the question. Appreciate the engagement from the— from our audience. So the Industry 4.0 Club would like to encourage you to take action to advance the deployment of Industry 4.0. So read an article, attend a broadcast like this one, attend a workshop. or even develop a smart manufacturing roadmap for your company or your plant, or encourage your plant to do the same. We'd love to know what you're doing. We'd love to hear from you. Please drop us a note on our website at www.industry4o.club or on our LinkedIn page and share with us what you're doing to advance Industry 4.0. In addition, if you'd like to be on a future broadcast, and have a conversation like this or have something you'd like to share with our audience, we're happy to also host you. So reach out to us so that we can host you in the future. With that, Josh, again, thank you so much for taking the time out of your schedule and look forward to hearing some of all the great things that are happening at Ironloop.
Yeah, thank you, Mike. Really appreciate it and love the work you guys are doing with Industry 4.0.
Yeah, thanks, Josh.










