OT Cybersecurity: Why Trust Beats Technology | Jacob McCune | Ep 114

Intro and Jake's career arc

Aaron Crow (00:01): All right. Thank you for joining me on another episode of the PrOTect IT All Podcast, where I get the opportunity and the privilege to sit down and talk to people and hear their stories, their war stories, their experiences, and all that kind of stuff. And meet all these amazing, wonderful new people that have all these great things to bring to the community. So Jacob, with that, thank you for taking time for saying yes to my random LinkedIn outreach and realizing that I'm not selling you anything, that I just want to have a conversation. So thank you for joining me today. Thank you for taking time out of your day. And with that, why don't you introduce yourself? Who are you? How did you get into this? What do you do? All the things that matter about you to the audience.

Jake McCune (00:44): Yeah, no worries. Glad to be here. Call me Jake. I go by Jake. But I am a Cybersecurity Architect, currently working at a critical-infrastructure utility. About 20 years of experience in IT and cybersecurity. So I've been doing it a while. Come from a kind of non-conventional. Worked my way up from the help desk. Don't have the degrees or any certifications. I just have a whole lot of practical experience and application across the board when it comes to systems, infrastructure, OT/ICS, RMF. Worked for the Department of Defense for a while and did a little bit of RMF work for First Army headquarters and kind of got experience all over the place and took a chance to get into cybersecurity. And once I broke into cybersecurity, I liked it, so stayed at home.

Aaron Crow (01:40): Yep. That's awesome. The funny thing is, I get so many people. I follow Reddit posts and groups around OT cybersecurity. And obviously with the podcast people. I was just in Singapore at DEF CON and people are talking, how do I get into OT? And I really want to do this, and all this kind of stuff. Your story is what I tell people. Because I have a very similar story to yours. I got in from the ground up. I was desktop administration when I was in high school working at a company, and I've worked my way through into network administration and server administration, applications and Active Directory and all these different things over the years that has taken my career through. I'm old. I've got lots of gray in my beard. So MCSE certified and Cisco and Certified Novell Engineer and like all of those tags and certifications in my past. But they all brought me to here. So your story is what I always tell folks. In my experience, OT is not an entry-level job. You're not going to go take a certification or a training or a bachelor's degree and jump into an OT role. You're going to probably have to go into the help desk or the SOC or some other thing, and then pivot from there after you've proven yourself and then do a lateral move within the company. So it's awesome to hear. I've heard so many folks talk about it, but every time I talk about it, you don't need that. The best experience is having that. You've built that trust and that's how you got into that role, right?

Breaking into OT cybersecurity

Jake McCune (03:13): Yep, practical experience is still huge in my opinion. A lot of people undershoot it. And I guess the biggest detractor is getting past those filters. The people that think that you need or you require something to be an asset. Which I don't think you do. I think the biggest thing is that you need to be able to talk to people. And you need to be able and willing to do the work. And if you show up and do the work and you can communicate, a lot of times you're going to be fine. I think that your network is more important than your degree. You need to make sure that the people that you're talking to, and like we were talking about before the podcast, if you're the smartest person in the room, you're in the wrong room. I really, really do believe that. I like to sit myself at the table with as many smart people as I can and even just being a fly on the wall.

Jake McCune (04:12): Yeah, practical experience is still very important. And OT, like I call it, you need to get a feeder role. You need to work your way up to like sysadmin or infrastructure analyst or something like that where you understand all the basics and you got a core, and then work on your network. And if you really want to break in, you need to make sure that you know people and also that you're doing the work. Show that you're trying to do the work. The OT work. Understanding what a PLC is, understanding what the Purdue model is, understanding what cyber physical means, all that good stuff.

Aaron Crow (04:53): Yeah, you know, building out teams in the past, working at a power utility in Texas where we had had 40-something power plants. And this was back, you know, 2010, 2012, when OT wasn't even a term. That wasn't something we call it. So nobody had experience in OT, at least the way that we're talking about OT today. So when I'm trying to build out this team, I'm recruiting for people that have never been to a power plant. They've worked in law firms and banks and other things. So I can't put on the resume that they need industrial control systems experience or know how to configure a PLC or even what the hell a PLC is. Because none of the people, none of the skills that I needed, none of the people would have those capabilities. So I had to bring people in that had networking or whatever other skills that I need. I had to teach them the OT side of the conversation. And it's funny. I had a few folks that were super smart, super capable, great IT people, and they'd been at that for years, but then they would have a hard time grasping things as simple as a patch came out. I'm going to go ahead and push the patch and reboot the system. No, the heck you're not.

The IT vs OT mindset shift

Jake McCune (06:00): No, no, no. We don't do that here. Yeah, no. People in IT, a lot of times, they grasp onto that CIA triad, and it's different. It's not that. Safety and availability above all else. And also understanding an incident as an outage, even if the incident didn't cause an outage. If you have an incident in OT, if you're going to go and actually respond correctly, you're going to treat that as an outage because you're replacing that piece of equipment out there in the field. You're not just going and doing forensics while it's still running or shutting it down because you can't do that. Especially these days when we're looking at critical infrastructure where I'm working at, you're talking about automation that controls giant valves for gas pipelines and high voltage electricity and all that good stuff. It's about life and limb and availability above all else. That's hard when you. If you've been in IT a long time, it's really hard to wrap your mind around. I think that's a hurdle that a lot of guys have to come over to really understand what OT is, overcome rather.

Aaron Crow (07:13): Yeah, for sure. I had a conversation again in Singapore at DEF CON. A gentleman came up and he had worked in OT or critical infrastructure a decade ago or something. And he was asking, "Hey, back then, one of the things that we noticed was that all the protocols were open and there was no encryption on the protocol. You guys have fixed that now, right?" And I'm like, well, yes. There are encrypted protocols, but no, most of the time we don't use them. And he was just dumbfounded. Like, yes, there's encrypted protocols that you can choose, but most people are using open Modbus, DNP3, et cetera, et cetera, et cetera. Not because they can't, not because there's not options, but there's other reasons that we choose those. Because availability. And you hit the nail on the head, right? Availability is more important than. I don't give a crap about confidentiality. I'm running a turbine. There's the reading off the temperature or pressure, whatever. There's nothing confidential in that, right? I'm not trying to protect the value that is in that string. I need to get it as fast as possible. And everything that I add in between in that chain can break things. And if encryption breaks my process from my controller, from my operators being able to control the thing that they're trying to control, that's a problem. And that above all else. I can secure that, I can remediate that in other ways that doesn't necessarily mean adding encryption to the layer.

Jake McCune (08:42): Exactly. Yeah. If you can show me that it's reliable enough, we're going to consider it, obviously, from a cybersecurity standpoint. But at the same time, again, you can't push availability and safety enough when it comes to OT. OT is really where the dollars are at. A lot of people also have a hard time separating the IT and the cybersecurity and the OT from business. But then also understanding the relationship it has with the business. So I think that's also something that's fundamental and what helps me talk to stakeholders is understanding the business. Because you can come at them in real terms with what the risk is for their systems and protecting their systems, but also trying to build that trust saying that, "Hey, I know how to come protect your system without taking down X, Y, and Z. And we'll work within your outage, your planned outage schedule, all that good stuff." Understanding, talking to the operations folks and saying, "Hey, look, I understand you have this outage window coming up. We have some stuff that we'd like to put in while your window is open. Let's go and do that. And we can buy you some risk buy down. So we can help protect your systems and do it in a way that we're not intruding on your operations." So it's important to understand the full circle, right?

Outage windows, critical path, and how OT really runs

Aaron Crow (10:13): And, to be clear, those outages are not like in IT. Those outages are, you know, every Friday night there's an outage window, or every Saturday night from midnight to 4 a.m. or whatever. And OT, especially in critical infrastructure, that may be every once a year, maybe twice, maybe you've got a spring and a fall.

Jake McCune (10:35): If you're really lucky, it's once a quarter, but mostly in nodes, once, twice a year.

Aaron Crow (10:41): Yeah. So you're having to bundle all the things that you want to get done into a very short window, and you're not critical path for that outage. And what that means, if you understand project management, what is the thing that I have to do to be able to get from start shutdown to start back up. We are never, at least in my experience, I was never critical path, nor did I want to be critical path. So what that meant is when they're ready to release water and turn the thing back on, whatever I didn't get done, sorry, but it has to be ready for them to be able to start the product.

Jake McCune (11:12): Plan better next time.

Aaron Crow (11:36): Exactly, right. I got as much done as I could cram in, but I wanted to do 10 things and only got seven done. Okay, we'll move those other three to the next time, which means we're not patching those things or we're not doing whatever those things are that we wanted to do. Because critical path is, I have this outage window to get this power plant online or this manufacturing facility online, this gas thing online. And that is the most important thing, and to do it safely. And they're not going to push an outage longer because I want to update some patches. Because then they're not, that's more days they're not billing. They're not able to have their product or the capability online in a power plant or all these things. That's big dollars. And not to mention all the contractors that are on site for an outage and just exponentially grows. My gosh. It's so huge.

Jake McCune (12:00): Compliance. NERC compliance, EPA. People don't understand that gas is under the EPA, also under the TSA, and water, a bunch of EPA. EPA is also hot dogging and catching up real fast to FERC and NERC, diving deep into that 853, NIST 853 and 882 and taking lessons out of stuff that NERC and FERC have done. And TSA doing the same with gas. So you got to be conscious of all that as well. And I'm a real proponent of building out your timelines, making sure that your stakeholders are aware of your timeline, and then pre-project planning as much as humanly possible and understanding sustainment inside of your project planning so that you get back to operations sustaining their operations fast and as efficiently as possible. Having the very high level timelines, but being able to take that deep dive with your engineers. Being an architect, I've stepped back from being an engineer, and you really need to make sure that you can talk to your engineers and they understand exactly what you're trying to do, the timeline to do it, and understanding the really important pieces. And then also being able to walk into an executive meeting and say, "Look, this is what we're trying to do. This is why we need this money."

Translator, mediator, and the language of three audiences

Aaron Crow (13:35): Yeah. And dude, I love that you said that. That's my experience as well. The longer and later in my career I got, the less I was configuring the firewall. I mean, I was still doing that stuff. I still need to understand that. I need to architect, I need to know how all those things work and function. But so much more of my time was spent in those conversations. And it was having the conversation. I really saw myself almost as a mediator. I speak technology and IT, so I can talk to the IT folks. I speak operations enough to talk to the plant people and be able to translate between those two. As well as having to speak to the executive folks, which is a different thing you have to understand. All those things have different goals and needs and concerns and fears. And those are all the things to be successful in this OT space. That's the biggest caveat I've seen in getting these things done. Because plants don't want IT coming in and saying, "We're going to do these things to you. You're going to pay for them. You're going to like it. You don't have control." Nobody likes that. But we also know that they do need to be done. But it's just like, if somebody walks up to you and says, "You're going to do this," I can't speak for you. For me, when somebody walks up to me and says, "You're going to do this," I'm like, no, I'm not. Even if it's a good idea, I'm not going to do that. No. I'm going to do everything but that.

Jake McCune (14:51): We're starting off with, "I'm not. Now I'm going to do everything but that," exactly. Yeah. No, I have a good story about that too. A friend of mine, I think he's a mutual friend, Kevin Smith, who had talked about a story, how it's important to think about how you're dressing before you walk into meetings with certain high-power individuals and making sure that maybe you have your steel toe boots on and not your dress shoes on when you go talk to a plant manager. He had a story about some consultants walking in and doing just that, trying to tell somebody they were going to do something to them. And the plant manager saying, "You come in here with your pointy shoes telling me what I'm going to do in my plant. I need you to take yourself and your pointy shoes out of here." And then straight up consultants getting kicked out of the plant because they just didn't understand and came at him with the wrong language, with the wrong intent. You have to understand what you're walking into. And I think when you build up practical experience, that stuff comes more naturally. So it makes it easier to go and do those type of things. And especially while there is value in finding a niche and drilling down your niche, there's also a lot of value in understanding broad concepts and getting a broader experience than just whatever you're trying to drill down to in the niche that you're trying to drill into. Because that then helps you be that communicator. One of the things that I like to say is when I come at problems, a lot of the times I use patience and perspective. Those are my two biggest things when I come at a problem, especially when I'm trying to communicate the solve to that problem to people and explain how, in my view, we should solve that problem. Because everybody sees stuff differently, and somebody that has more practical experience, I think, has the ability to take more perspective. Because you've talked to so many more people with so many different perspectives. So when you go into the room and you're trying to solve a problem, you talk to the executives differently with different language while not talking down to them, listing off technical reasons why we need to go and do these things, is different than going in and talking to the engineers saying, "Hey look, from my perspective, this is the best way that we can solve this problem." But also then having patience when you thought that you were coming at them from the correct perspective and you find out you didn't. So you can't, you also need the patience to understand that and to try and find their perspective. So my biggest two things is coming at a problem with patience.

The jiu-jitsu story and building trust

Aaron Crow (17:50): I've told this story before, but you know, and I say it all the time. One of my mentors told me a long time ago, all businesses are people business. And we have to work with and through people to be successful. It doesn't matter if you're the janitor or the CEO or whatever, right? You've got to work with and through people. And there was a power plant that the company I was working at, I was an asset owner at a power company here in Texas. And we bought a power plant in the town that I lived in, which was awesome for me because it was close. Most power plants, Texas is a big place, and power plants are usually not in cities, at least big cities. So usually I had everything from West Texas to East Texas and North Texas. They were all old places. I mean, it could be eight hours between plants as far as driving goes. So it was a big swath of driving. And outages, three months at an outage doing a control system upgrade and FATs and all the things. There was this one plant, again, that we bought in our town. So I was super excited. We're onboarding this thing, and there was this one guy that was in charge of the OT cybersecurity stuff at this plant. I'm like, man, I'm so excited. We're going to go in there. We're going to show him. Because we'd rolled all this whole program out and we'd done all this stuff and, I think we'd gotten pretty good at it. And we did a good job and it was pretty thorough and mature, especially for the time that it was. And we walk in and I'm just like expecting him to be like, "Thank you. This is amazing. I'm so excited." And he was like, "You're not doing that here." And I was just like, what, what do you mean? He's like, "This is going to break my compliance." Because he came from this other big company and they had their own way of doing things. And I wasn't able to, he didn't just like my idea. And no matter how hard I tried to explain it, technically it didn't help. I drew it on the whiteboard and I got documentation and I brought in my team and we showed him how we did it at other places, and none of those things happened. Until one day we were sitting there in his office and I looked up on the wall, and he had a picture of him getting his purple belt in jiu-jitsu. And I'm like, "You do jiu-jitsu?" He's like, "Yeah." I'm like, "I do jiu-jitsu. I'm a white belt. I see you're a purple belt, so you can kick my ass." But that connection broke down a wall enough that he started talking to me and he didn't hate me. And now we're great friends, right? But it took that connection finding that way in.

Aaron Crow (20:16): And sometimes that's bringing donuts. I'm sure you've done that many times. You bring donuts or pie or hamburgers or barbecue or whatever the thing is, and you're buying there. You just want them to have a conversation with you, right? And if they're eating dinner with you or lunch with you at the table, at least they're open to talking somewhat and seeing you as a person. And you're wearing steel toe boots and a hard hat, and not penny loafers and whatever. I had a salesperson that came in wearing high heel shoes, and I'm like, you can't walk onto the power plant with open toe high heel shoes. There's grating up there. It's not, no, you can't do that.

Jake McCune (20:57): You've not been in a power plant without telling me you've not been in a power plant.

Aaron Crow (21:00): Yeah, your fancy dress and shoes don't help you here. But it's so important to be successful. All of those things matter. And this goes back to what we talked about in the beginning. And I'm not negatively talking about degrees. I think they're absolutely a place for them. All the things, right? But nobody teaches you the soft skills. They don't focus on, even my career, nobody until a certain place in my career, nobody taught me about communication and presentations and all of those other things. Without those things, it doesn't matter how smart you are. You're never going to get your idea pushed through. Just being smarter doesn't matter. You have to be able to convince people. And to do that, it's the Dale Carnegie, How to Win Friends and Influence People. You've got to be able to influence people. And just telling them how smart you are is not going to do it.

Jake McCune (21:56): Yep, true story. By the way, I don't know if you know this, but that's required reading if you work for John Deere. Absolutely.

Aaron Crow (22:03): There you go. There's a reason for that, right? Because it doesn't matter what your role is. It's super important. If you're just trying to convince your boss or your peers or your subordinates or whatever that is, it matters.

Degrees, certs, and the job-description problem

Jake McCune (22:16): Yeah, absolutely. Now at the same time, if I could go back and tell myself, I would tell myself to go get that degree just because it takes away those filters when you're really struggling and you're trying to find a job and you can't. It's one of those extra things that's just a check mark, right? And also nobody told me how important people networking really is. And I didn't have a mentor when I started going through college. So I didn't understand the importance of networks. And one of the best ways to learn how to build your network and to build a network is to go to college. So I don't fault people for doubling down on stances like you should have a degree. Do I think you should have a degree? Sure, I do think you should have a degree. But also I don't think you need a degree to be good at something. And I also don't think it should be a requirement either. So one of my biggest pet peeves right now is job descriptions. You can tell right off the bat when the job description was written by somebody that doesn't do it. And I would say probably 95% of the job descriptions out there were written by somebody that doesn't do the job or doesn't understand the job that they've written the description for. While I agree that having a degree is a very good idea and you should go do it, I don't think it's as important as some people.

Aaron Crow (23:50): Yeah. And honestly, in my experience, posting jobs, again, when I was an asset owner, a lot of times that came from HR, and I had to fit my description in with the job level. If it's a Senior 1 or a whatever tier, which comes with the pay range, I would have to fit the requirement. They had a generic, when you're this level, you must have at least, and most of those were a job degree and bachelor's and this much years' experience. And I'm like, look, this job needs to pay this much. And it's also why you see all these jobs that are on LinkedIn: entry-level OT person, five to ten years' experience, degree. Wait, what? How's that entry level? Now they're paying entry-level prices but they have requirements that you have 10 years' experience or 5 years' experience. Those are opposites of each other. You're either a beginner or you're not.

Jake McCune (24:56): Yeah, but that does harken back to our conversation about getting into a feeder role. But I also at the same time think people need to understand that you can't get somebody that's good at an entry-level salary with the requirements that you have unless you're taking advantage of somebody. Or if somebody is really hard up and really needs, what we've seen a million times recently, people have been without so long, they're willing to take whatever.

Aaron Crow (25:25): Yeah, which is a short-term play, right? Because once they get back on their feet, they're not going to want to stay there because there's going to be other opportunities they can go to.

Jake McCune: So I think it's unfortunate that people are taking advantage of that, but it is what it is.

CapEx vs OpEx, the long tail, and getting the work funded

Aaron Crow (25:53): So how are you seeing, what are you struggling with as far as A, having those conversations, getting buy-in from the OT side, the operations side, pushing that envelope on what needs to be done with budgets. I also know the difference between, and I'm sure a lot of folks have heard this before, obviously you know, but the capital side versus the O side and how different that is. I can get a capital project approved for a million dollars, but the $100,000 a year to pay for it ongoing, that's the hard part, right? The people, process, and technology thing that supports this thing. Who am I handing that baton to? It's easy to pay that upfront part because maybe I do a great case and it's different, but all those things are hard. And you need to have that full picture of understanding to be able to really successfully manage OT, any project really. But that O side comes as a tail that's really difficult sometimes to manage in these spaces.

Jake McCune (26:41): Yeah, I think the most difficult part is helping people understand the risk. And also to yourself, being true about the risk that you're trying to cover and the systems you're trying to buy down risk on. Being honest with yourself, "Is this really worth the fight to try to cover what I'm trying to cover and lower the risk on these systems for this output over this period of time?" But also then explaining how important some of these systems are to people that might not understand how important they are. Also, I think every company is struggling with it right now, but resources. Resources that know what they're doing are hard to come by. So when you have somebody that's off for a week, it's hard to get stuff done. But I think really the hardest part is still just spotlighting and highlighting the amount of risk that you're trying to guard against, and also how much risk systems are at. So I think that's probably the hardest part really still. I think that's pretty much what every at least utility is struggling with right now. And to your point of capital versus OPEX, working for a utility, capital projects are really important. Trying to make sure that you're taking advantage of opportunities that other projects might be taking care of, and making sure that you're co-developing solutions that might be parts of a bigger project to get what you need done. Stuff like that. Making sure that, again, that you're not a squeaky wheel, but also everybody knows that, look, I'm fighting for OT here and I'm trying to make sure that going into the future, we're covering risk and I'm not just trying to cover off compliance. I'm a big proponent of security first. And I think that if you do your security first right, you're almost always beating compliance anyways. So I think that measuring security by your compliance audits is a bad idea. So I'm always fighting for that. I think that's definitely the most difficult.

Security first, compliance follows

Aaron Crow (29:16): I can't tell you how many times I've had that conversation. Well, we're compliant with NERC CIP, insert compliance requirement, you know, standard here. And you just have to say, okay, but that's the bare minimum, A. And B, especially in NERC CIP, and I say this a lot with power utilities, that's only a small subset of your actual assets. Maybe it's 80% at some larger places, but how many of those are not included in that compliance program? So if we actually look at it, it's probably even less than that. So when you look at it from the flip side, if I'm designing my cyber program and I'm implementing cybersecurity, I should naturally be able to output that compliant. Now, obviously there's probably some specific tasks that I have to do to maintain compliance and be able to show compliance, prove compliance. But if I'm doing all the right things, then all the tasks, all the cyber related things within the cybersecurity requirement of that compliance program should automatically be done from the cyber product that I'm trying to do, right? So then it's just about how do I prove it and how do I report on it, right? And how do I give you documentation?

Jake McCune (30:21): Absolutely. And you always have to keep that in mind, right? How do I help my compliance people tell the story? Because a lot of times compliance is more about telling the story than about following the letter of law. If you can argue to an auditor that you have these systems, you have them in there this way, and that's how I'm covering these, and then go and prove it, oftentimes you're covered. But compliance is still extremely important. But at the same time, I think you need to worry about it. I think that if you are security forward, then you're ahead of whatever compliance you're trying to keep yourself to anyways. And like you're right where you have to make sure that you are thinking about compliance and your compliance team. Because the more you think about your compliance team and help your compliance team, the more they're going to work with you. And also the more proactive your compliance team will be. Like, "Hey, I haven't seen this report in a while," or "Hey, this thing is coming up," because they know that you're involved. They know that you're thinking about them. So they're more likely to think about you as well. Where you might get a meeting in time for something you might not have gotten before. And it was a valuable insight into something that you didn't know about, things like that. So yeah, that's a difficult conversation that happens often, I think, having been in the consulting space, but then also being an FTE for a lot of this stuff. And I think it goes the same for petrochemical and oil and gas and big manufacturing. So I've definitely covered all those bases. While the conversations are similar, again, it's about understanding that perspective with those things. But while keeping compliance in mind, if I keep my head down and do security right, I'm probably going to be ahead of compliance.

Aaron Crow (32:18): Yep, absolutely. And compliance can guide you and drive you to make sure that you're doing the right things. But yeah, designing programs and all the things, whether as an asset owner or consultant or whatever, I've never wanted to design them to just meet this. Now, sometimes you have to just do the bare minimum because that's all you can do at a certain place, right? Sure. But if you have the maturity, that shouldn't be your end goal. That's to get over this hurdle. And then what, right? What else can I do? And it doesn't always mean rolling out a bunch of complicated technology. It can be, especially now, we know that we can build so much with scripting and there's so much that we can do in this space. That doesn't mean I have to go buy expensive tools. Now, sometimes you need an expensive tool. And sometimes it's actually cheaper in the long run to buy the tool than it is to build something in house. Because then who's going to support it? And if Jake gets hit or Aaron gets hit by a bus or the lottery, then who's going to support that thing after the fact, right? And manage that.

Institutional knowledge and the talent we're losing

Jake McCune (33:16): Especially in OT, institutional knowledge is huge.

Aaron Crow (33:22): And we're losing it. We're losing it because people are aging out. A lot of those are, my dad worked in the power industry for 40-something years and he got an early retirement from the company that he was with. And then he went and worked a whole nother career still in that power utility space, but as a vendor. And retired from there and then did it a third time. And it was a shorter stay the other two times. I think the first time was 39, 40-something years at the power utility. And then it was like 11, and then it was like 5. But still he'd worked all of this time. He's in his late 70s, and those places still call him. They had an outage like two years ago and they were having issues because there was a fire or something in the control room. And he still was around, so they called him to come consult on it. Because he built the damn thing in the 70s. So he had the institutional knowledge of where the things were and why it was wired that way and where it was supposed to go and how the process worked. And that is pretty much priceless. A new person could be smart, but they don't know that institutional knowledge.

Jake McCune (34:32): [If] they're rebuilding the system from new, it becomes a lot more difficult.

Aaron Crow (34:36): Yeah. But even with that, there's some knowledge that they need just because how the process works. Like how the thing is wired, how the steam tubes are done. Yes, I can replace a control system, but I still have to understand the physical process to understand how to build the control system to drive that physical process. And that's the piece that has left, because there was nobody left. They were all new folks and they understood it to a point, but not to that level, to be able to design a new system based on that. Even the engineers, they were just new. They didn't have anybody that had really understood that process that well. So they had to bring in outside help. And that's something we need to think about is where you look at incident response, you look at disaster recovery, you look at all these things. So many times I see people doing tabletop exercises and it's the IT people, it's the CISO, it's people like that. But we're not bringing the operations guy in the room. Because he's the one that really will tell you how it's going to work when the plant goes down and he needs to get it back up.

Jake McCune (35:32): Absolutely. But also where does the ticket go? It's going to end up in operations. Especially if you're doing what we were talking about earlier, where if it's an incident on OT stuff, it's often an outage, and you're replacing a piece of hardware and then doing forensic work afterwards. So it's going to end up on operations' desk. So you really, those people need to be in the room for sure.

Same team, different jerseys

Aaron Crow (35:57): Well, and that goes to where you got to build those teams. And we have so much animosity across the board between IT and OT. And there's this oil and water and OT/IT convergence or whatever the hell you want to say. But you need to work. I always say we're on the same team. Maybe you're offense, I'm defense, whatever analogy you want to use, but we're in the same jersey. We're on the same boat. We're going the same direction. How can I help you and build that camaraderie? The other saying I say a lot is we do business at the speed of trust. So the more that you trust me, the more likely it is that the faster we can go and do work. Because I don't have to convince you that I'm not an asshole and I'm not trying to break your stuff. You already know me. Now you're past that. Just like the jiu-jitsu guy. Once I was able to build that trust, then he was able to hear the other things I was saying. Until I built that trust, nothing I said mattered, because he didn't trust anything that came out of my mouth. It didn't matter that I maybe know what I'm talking about. He didn't trust me, so nothing I said mattered. It was just Charlie Brown's teacher, and he gave me the Heisman.

Jake McCune (37:02): Yep. Yeah, often, especially when I was doing consulting, I tried to impress upon people that I'm not here to tell you no. I'm here trying to offer you a way to yes, right? I'm here trying to get you to yes with the lowest risk possible. So I don't want you to think I'm coming in here to tell you no, or tell you that we need to alter your production or your process, people, anything like that. I'm coming in here trying to solve a problem for you and trying to get you to your yes, to get you to doing what you do while altering it as little as possible and making sure that it's dependable, but with as low cybersecurity risk as possible. At the end of the day, I'm really thankful that my first gig was risk management because it helped me see how much of cybersecurity is just that. It's risk management. Always at the end of the day, again, we get back to the business talk. And when it comes, the best way to talk, in my opinion, to somebody who's business-minded about cybersecurity is just risk. Use risk. Because I think that's the best universal language. "Hey, we have these risks. They could potentially cost us this much." Go try to find peer information, stuff like that. But at the end of the day, as a cybersecurity architect, I'm building systems to lower the risk and keep production up and running as long as humanly possible. I'm not trying to come in here and tell you no and stop.

Aaron Crow (38:42): Right. You're trying to help. But again, until you build that trust, they don't know that you're trying to help. And that's the biggest hurdle to overcome. It's one of the reasons why I feel I've been successful. Part of it is because I wore those hard hats. I worked in outages. I worked right there. And that's where I gained their trust. Because I wasn't the IT guy that came in at 10 o'clock on Monday and left for a two-hour lunch and then left at 4 o'clock. I was there the entire, like, we were working 16-hour days, seven days a week for three months, just like them. And that built that, they're like, "Okay, wait, these guys are different. They're wearing the same clothes as us. They're here for the stay. They're staying in the same hotel," or, well, these guys are probably local, but you get my point. We built that trust, that camaraderie, because we weren't fly by night. We weren't running away. We were there when they called us. We showed up and we're able to help them. And that made a big difference to our success when we needed to do something that they didn't necessarily understand or like. They, because we earned their trust within the other side, they were again at least able to listen to us, where they wouldn't have six months ago or somebody else walking off the street. Even if they were wearing the right outfit, they still wouldn't have built that camaraderie that we had over months of doing this, you know, fighting in the ditch with them, right?

Jake McCune (40:04): Yep. Yeah, doing the work is always the best way to prove it. For sure.

Looking over the horizon: cloud, AI, and the Purdue model

Aaron Crow (40:09): 100%. So what do you see coming up over the horizon? I always prep with you about this, right? And I give all my guests the same question. What's one thing you see coming up over the horizon that's maybe concerning and one thing that's exciting when it comes to all the things in your purview?

Jake McCune (40:31): So I think one thing is, well, it's a multitude of things or both, right? We can talk about, especially in my space and OT, relying more and more on cloud resources and also the inevitable AI, but that really comes back to cloud sources and utilizing the cloud correctly in OT. Taking advantage of some of these software-as-a-service things that IT has been able to take advantage of for a long time when it comes to machine learning and AI, especially for threat intel and things like that. Taking a look at passive network sensor data and quickly finding anomalies and things like that. I think that is both, I think it's a double-edged sword. I think it is both kind of daunting and risky, but at the same time, I think it's something that we have to do if we're going to keep moving forward. And I also think that I see that a lot of folks are going to start leaning away from the Purdue model. I think when somebody comes up with something that is almost as easy to communicate to someone as the Purdue model, I think it'll quickly go by the wayside simply because I think Purdue model did its job. So I think at the end of the day, with what we've got now and the things that we're having to work with and integrate now, the resources that we want to be able to utilize, I think we move away from that into the next thing. What that next thing is, I can't tell you. There's a million different people floating a million different ideas when it comes to that, but I haven't seen one concrete solution, right? And maybe that is just the solution. It's more of a bespoke solution. But I feel like when somebody comes up with something that is a succinct way to replace Purdue, I think it's going to be something that quickly gets accepted. Especially if it considers more cloud resources and utilizing ML and large language models using OT-style data. And I see some companies that are trying to kind of cut that in half and bring some of those features to on-prem stuff. And it's really, in my opinion, a half solution, where I think we just really need to start thinking about those next steps. I think it's both, again, I think it's both one of the scary things that's coming up, but also one of the exciting things that's coming up, for sure.

Aaron Crow (43:30): Yeah, absolutely. And it's funny. I remember again, rolling this out in 2012 or whatever, and the control system vendors were bringing in all this stuff. We went from these very proprietary boxes to using Windows and firewalls. And the next thing was virtualization. And virtualization, I'd been using virtualization for years. This was not a new technology. But explaining virtualization to a plant manager and explaining how that worked. And then I would need one physical server and multiple servers would live in there and how that worked, and explaining how it's actually more reliable. And I can have HA and redundancy and all that kind of stuff. It was like black voodoo magic. And they were just like, "Nope, not doing that. What do you mean? Nope. I don't understand it. I need a physical box. There was a box. I need a second box. There's a box. There's my redundancy." Like, no, what? Time out. "And we've done this for 40 years. This is the way we're going to do it," et cetera, right? And again, it was one of those, like I said, my earlier example. It wasn't a matter of me being smarter, or explaining the technology better. That was not the problem, right? I could never outsmart them or convince them by the technical prowess or my ability to explain a concept, a technical idea. That wasn't the thing. They didn't understand it. They were never going to do something they didn't understand. And it wasn't because, even if I could convince them, they were still like, "Nope. Until I see it working at another plant and it's been doing that for six months to a year and hasn't caused problems, you're not bringing that shit to my plant. Because it's going to break and I'm going to be the guinea pig and I'm going to be the one responsible for it while you're at home at a movie with your kids. I'm going to be the one responsible for it. My team will be. You know, it'll impact their bonuses and all that kind of stuff. No, you're not testing on me."

Jake McCune (45:27): Absolutely. I think that a lot of the larger companies, luckily, are starting to try to take advantage of this stuff, and everybody else will start opening their eyes. And like you said, nobody ever wants to be the guinea pig.

Aaron Crow (45:44): Nope. Somebody's got to be, but nobody wants to be.

Close and where to find Jake

Aaron Crow (45:50): Well, that's awesome, man. So thank you so much for your time today. Awesome conversation, man. This is exactly the things that people need to hear. A lot of this I talk about all the time, but it's so important to hear other people's perspectives. It's not me getting on a soapbox. It's coming from the trenches. Seeing this stuff done in real world in OT spaces from practitioners like yourself that are doing the work, that are fighting the good fights and are being successful in those things. And these are still the problems that we know we have to fight and deal with. That doesn't mean you give up. That just means you have to understand your limitations and how do I solve for those things anyway. So thank you so much for your time.

Jake McCune (46:31): I was going to say, this isn't the gig that you get into if you want something easy. This is [not] an easy job, and I'm not here for it to be easy. I'm here because I like the challenge.

Aaron Crow (46:39): It's not. Yeah. Me too, man. I'm passionate. I have a smile ear to ear. Anytime I'm talking about it, I enjoy this. It brings passion to me. And I see others like you that are the same way. And we do this because we see the value. We know that it's not easy, but if it was easy, anybody could do it. They wouldn't need us. They could train an AI to do it. And I'm not worried about that at all anytime soon.

Aaron Crow (47:18): How do people find you? What's a call to action you want people to know?

Jake McCune (47:26): You can find me on LinkedIn. Like I said, it's important to make sure that you're networking and getting out there. So you can check me out on LinkedIn. I don't have any big projects that I'm trying to push out there. If you haven't ever heard of it, check out CornCon. It's a small cybersecurity conference in Iowa that brings in some pretty heavy hitters and really fun to be at. So if you're looking for something new, I'd say check out CornCon at corncon.net. And that's about it.

Aaron Crow (47:56): Awesome. Awesome, man. Well, hey, I really appreciate it. Great to meet you. Great to dive in today. And maybe I'll see you at CornCon. If not, definitely let me know if you're ever in my area. I'll do the same with you. And we can talk some more in person.

Jake McCune (48:06): Perfect. Yeah, perfect. I love that. Great chat, Aaron. Hopefully we can have Scotch together sometime.

Aaron Crow (48:12): Absolutely. Heck yeah. Absolutely, man. Thank you so much.

Jake McCune (48:16): No problem, thanks.

Transcript lightly edited for readability.