OT Pen Testing: Why Trust, Culture & Hands-On Experience Matter Most

Take two: intros and origin stories

Aaron Crow (00:03): Thank you everybody for joining me on another episode of the Protect It All podcast. This is take two of this episode. We had some technical difficulties, which tends to happen from time to time, and that's no problem at all. But I'm very excited to have my friend Oren on the podcast again. And Ray, this is your first time. Well, I guess you were on it last time, but we didn't get to the end, so we're starting over. This is technically your first time on the podcast. So Oren, for those of the audience that don't know who you are, why don't you introduce yourself: who you are, how you got in the industry, what you're doing nowadays, all that kind of fun stuff.

Oren Niskin (00:45): Since I was on your show last time, now I'm a Principal OT Security Engineer. So my kids are very scared of me; they think I'm a principal. I was thinking about making a sign that said "Oren: principal's office," but I haven't yet. I am a Principal OT Security Engineer with GuidePoint Security. I've been in OT for over 20 years, which, if you've ever heard me speak, I like to say you should be a little bit skeptical whenever you hear that, because OT hasn't really been around 20 years. But I was in O before OT. I was crawling around in the bilges of drilling rigs and Navy ships, being an electrician and electronics mate, electronics technician, then proceeding on to IT and consulting and eventually OT cybersecurity. Once I hit that, I was just like: yeah, this is where I need to be. All the spy vs. spy stuff: I got caught up in it all, and here I am. I don't think I'll ever leave. So that's my background.

Aaron Crow (01:50): Awesome. Ray, you're up, buddy.

Reynaldo Gonzalez (01:53): My name is Reynaldo Gonzalez. I either go by Ray or Reynaldo, depending on how you want to pronounce it. The way I started my career, my journey: I actually come from the IT side. Like a lot of people, I started with an interest in computers when I was young: building computers, messing them up, trying to fix them. I remember having my first Aptiva model computer, where we browsed AOL and got infections, and I tried to fix that. What really got me into it was being able to explore that kind of technology. I was doing networking courses, building Ethernet cables, when I was a sophomore in high school, and then we had an opportunity to learn networking, so we took the Cisco CCNA classes to learn about routing and switching. From that moment I knew: okay, I want to do technology and networking.

So I went off to college, got my degree on the networking side, graduated, and got my first job at Cisco Systems. I was there for about 13 years. I did the network engineering side and consulting; I was on the data services team then, and got to support a lot of different customers in the US, South America, and Central America. The exposure of being able to see different types of networks and environments was the interesting part. What I learned about in theory in class was one thing, but when you actually applied it to real customer networks, it was: so that's how it makes sense.

The bridge to security for me happened through my years there, as I got more into security-related projects: network security, more infrastructure, architecture. At that time I was living in Spain, and I had my backpack stolen after I had come back from work. I was at a restaurant, and I had my backpack with me, with personal items I honestly don't know why I was carrying: some USB drives, a checkbook, things that were worth money in a way. Within two minutes it got stolen, without me understanding, without me realizing what had happened. When I found out about it minutes later, I went home and called my bank, and within about an hour my credit card already had $3,000 charged to the account. It was really fast. I later went back to the restaurant and found out that the couple who had taken my backpack were very elegantly dressed: a suit, a dress. You could never tell, just watching these people, that they would be the kind of people to do that. That is what made me start paying a lot more attention to security.

From there I really started getting more into cybersecurity, got myself more involved, and went back for my master's in it. I left Cisco, went to United Airlines, and got my role there as Principal Cybersecurity Architect, supporting the IT side and OT. Then from United I came over to my current company doing the same thing. So right now I do a lot of the IT side, but also the OT side of critical infrastructure: supporting strategy, architecture, that kind of thing. That's my background.

Oren Niskin (05:42): And Reynaldo is a big deal in Houston. If you're in Houston, he's everywhere.

Reynaldo Gonzalez (05:47): Not really. Not as much as Oren. Oren's the man.

Oren Niskin (05:52): I'm trying.

Diverse experience: OT is difficult, not hard

Aaron Crow (05:54): Well, that's the funny thing. I get the opportunity to sit across from awesome folks like you guys, and everybody has a journey that gets them there. Our experiences bring value. It's why true diversity on your team is people with different experiences, because those experiences can help me see things I've never been exposed to. I don't think about the things Oren saw when he was crawling around in the basement of a ship. Those are things he's going to bring into the operational side when we're looking at cybersecurity. He has a perspective that others don't.

That's why I see OT as difficult, not hard. The technology side, as Oren is showing with his demonstrations and the labs he's building out now: it's not hard. It's really not that difficult. That's not the point. It's understanding the why. Why do we do things differently? Why is the impact different? Why do we secure things differently? Why do we have open protocols? Why do we not lock our control room workstations? Why do we leave them wide open with no passwords? These are things where, if you only looked at the security side, you'd say: my gosh, your front door is wide open. And the answer is: yeah, but it's in a protected environment, there are three other doors blocking it, there's a security guard, and I have all these other mitigating controls. I'm not really worried about that. It's more important that the operator can actually control the thing that's going on than it is to ask "gosh, what's my password?" or "Bob went to the restroom; who can log in to turn this thing on or off, or adjust something?" That's a bad situation to be in.

The Bell Labs model and why OT

Oren Niskin (07:44): That's true. And I was actually reading about Bell Labs. I don't know if you've heard of Bell Labs, but they invented almost everything you see in a computer. It's amazing, the amount of innovation. The author was saying (I forget the book; "Innovators" something) that Bell Labs wasn't one smart person, like an Elon Musk, who just comes in and drives it. I know he has a team, but you know what I mean. You had a PhD in physics on one side who maybe didn't know how to use a screwdriver. Then you had somebody who spent thirty years climbing telephone poles and running telephone wire. Then you had an electrical engineer, and all these different, varied people. They all came together and worked together in the same spot, and it just accelerated. I think OT needs that. That's why I'm doing what I'm doing: bringing as many different people together as possible is what we need to light a fire and get this thing burning.

Aaron Crow (08:45): Hundred percent.

Reynaldo Gonzalez (08:46): Something else related to that: the other day I met someone at one of these events I go to here in Houston, and they were asking me, why OT? You have a networking background, architecture, IT. How did you get into OT? Why do you like it? And I hadn't really thought about it. Aside from just liking cyber, it's so dynamic, it's evolving, it's always changing. In a way, my wife and my sisters are into gossip, and cybersecurity is kind of like gossip: there's always something happening, and you want to know what's going on, get the scoop, get the details. Being able to be part of that is one aspect.

But the other part that made me realize why I enjoy OT came when I was at United, thinking about the way the infrastructure is. OT is very sensitive: a lot of old legacy you can't always fix the same way as IT, but it's critical infrastructure. My perspective was: at that time I was in aviation, and my family is flying on planes, my friends and other people are flying on planes. That safety is so critical that we've got to do what's necessary to protect them. Of course, there's a lot that goes into aviation; it's very regulated, with a lot of security. But thinking in general about chemical, utilities, energy, everything: if this gets breached, and they attack in a way that causes an impact, we're talking about people's lives and safety. For me, that's the driver. I may not be in those other industries, but in aviation and manufacturing we've got to do our part to protect it, and everything we do a little bit here and there with our peers all makes a big difference in helping modernize where OT security can get better.

Aaron Crow (10:55): Yeah, a hundred percent. I always give the analogy, and if you've listened to my podcast you've probably heard me say it at least once: the control system in the airplane has a vulnerability, and you're flying 30,000 feet in the air. Do you want to update that while you're flying? I don't. I say we land first. It's probably fine; I don't want to risk it. That's the thing in OT. It's just different.

And Oren, coming from the military: you talk about warships and submarines, and you've got to be really confident. Obviously a lot of those things have secondary and tertiary systems backing them up. But still, do you want to be the reason this thing goes down because you pushed a patch? Is it really critical? We're a mile underneath the ocean. Do we need to update that right now? Or why don't we wait till we get to port before we do it, and make sure it's in a safe environment?

Active scanning and the PLC trip story

Aaron Crow (11:55): It's why we do a lot of things in OT in outages. If I'm going to make big, massive changes, or I want to do a pen test or something like that, I'm probably going to wait until an outage, or at least a non-critical time, in case the worst-case scenario happens. And Oren, you talked about this last time: you walk in the room, some PLC trips, and they're like, hey, you just tripped the PLC. And when you got to the actual information, the guy was like: yeah, no big deal, it happens every day around this time anyway. And you're like: okay, couldn't you have led with that instead of telling me it was my fault? Why don't you tell the broader story? You told it last time, but we got cut off. I'll put it out as a short, but it's still a really good comment to really understand.

Oren Niskin (12:43): I'd love to. It's my favorite story. So you've heard of active scanning, right? Is active scanning safe? Is it not safe? One week it's safe, the next week it's not. We were doing some active scanning at a client, and I am very careful, because I've been the guy on the plant floor, like you're saying. I've been the person on the Navy ship. I've been the person on a drilling rig, drilling into Mother Nature's energy source, which is not something to play with. So we're doing some active scanning, and I had explained to them: we're going to use a safe protocol, and we're going to limit the network throughput, and all the things you would say. And halfway through, they said: hey, you just tripped off my PLC, you need to stop. I was so embarrassed. I stopped my scanning, I'm apologizing, I'm stressing out about it, because it's a major deal, and I was trying to be so careful. And then the guy was like: yeah, it happens every day around this time. I wouldn't worry about it.

It got me thinking: when you're active scanning in your environment, you are responsible for every bad thing that happens for the next two weeks. Even if you stopped and you're gone, they're like: yeah, they scanned, and now my system has tripped off for the fifth time this month. It must be their fault.

Aaron Crow (13:58): The last thing that changed, right? I think I told this story last time, but in the pre-job brief, even if they're just talking about "hey, Oren's going to be doing active scanning today," if something happens, even if you haven't started yet, the first thing in that engineer's mind is going to be: hmm, pre-job brief, Oren's going to be scanning. That's probably it. He broke something. Let me go find Oren and beat him until he fixes whatever he's doing or stops breaking things. Even though you're still in the break room drinking your coffee and you haven't even started yet, it's still your fault until you prove it's not.

Honest risk: reframing like a master craftsman

Oren Niskin (14:34): That's true. And that's with everything I've ever done in my career. Even adding a firewall rule or installing endpoint protection: if something happens, it's "your thing ruined my..." It's very funny. But I'll tell you, and this is a secret, don't tell anyone. No, I'm kidding. I think what separates a master craftsman from somebody starting out, maybe somebody starting out in cyber, is the way you reframe it.

If I were to tell you, "I'm going to sell you this software, it's secure": we know in cybersecurity nothing is secure. There are just different levels of security. You tell me what you do to make it secure, what I need to do to make it secure, and what to do if something happens. That's how you have that conversation. And in safety, when you go to the plant, it's the same way. So instead of saying "I'm going to active scan your network, it's safe," what you should say is: there is risk anytime you do anything in the network, but we're going to do this and this and this to limit that risk. If you see anything, you can do this to limit the risk, and let me know as soon as you see it. You have a conversation about what could happen, what I'm going to do to lower the risk as much as possible, what you can do, and, if it happens, how you can lower the impact. It's just like any other CISSP risk conversation.

When you tell it to them like that, they're prepared for it. They're like: okay, I'm invested. I think that's a good idea, go ahead. Then when something happens, they don't jump on you and say it's your fault, because they were part of the conversation. They're bought in. And I have a much easier time about it. But you don't see that a lot. When you see the marketing material from vendors, they say "safe scanning," and I think that's not a good message. It's more nuanced than that. You get a better result when you're just honest about it. That's my soapbox.

Reynaldo Gonzalez (16:33): That's a very valid point, though. Sorry, Aaron, Oren. It's a very valid point, because think about how scanning, the concept of what it is and what it means, has been framed from many years ago to the way it is now. A couple of years ago it was: yeah, this is a safe scanning routine. But now the language is changing to say: well, it's a query, it's a probe. We're not doing scanning; it's how we're using OT to talk to OT. Vendors are catching up. They're realizing it too, because it's true that the message, how they present it, to say "this is a safe scan": like you said, it's not 100%. Can you guarantee 100% that it's really safe? It can imply yes, but it's really a matter of how it's implemented, what is being done, what exactly is involved as part of that scanning. They're catching up to this, so the framing is getting better, and how it's described as a capability across these different solutions is making a big difference.

And there's also the education that you two, along with our peers, can give when we talk to the business: helping them understand it's not that kind of IT scan. We're not running Nmap in that way. We're using Modbus, or whatever protocol, to talk to this environment in the language it already speaks. We're just communicating to say: hey, tell me about yourself. What are you doing? What do you have? So it's getting better, and the more we do it, the further it gets. And of course it's also going to have an impact whenever you say AI is doing it. The AI part is a whole other animal.

Oren Niskin (18:31): Had to say it.

Aaron Crow (18:32): The AI word, or the scan word, especially in OT, is like a bad word. Don't say that word. Don't put it in your marketing. Don't say you're doing it. In fact, you want to say: we're not scanning. We're going to probe. We're going to interrogate. Any other word that means the same damn thing, but you can't say scan.

The OT.Sec.Con boxing match

Oren Niskin (18:57): So, to go to our OT.Sec.Con talk, which I thought was super fun: we did it kind of like a boxing match. I was the consultant pen tester and Reynaldo was the asset owner. In this instance, I may be banging around in his network, scanning or probing or however you want to say it, but he is the one that's going to get the call. He's the one that's accountable for my actions. I thought that was a really good conversation about what I do and what he does, how our perspectives differ, and how I get excited when I find vulnerabilities and he's like: crap. Maybe he gets excited too, I don't know.

Business at the speed of trust

Aaron Crow (19:42): So walk me through that. What did that look like, and how is that messaging helping? Because, and I say this a lot as well, we do business at the speed of trust. The faster the Orens of the world who are going in to do their thing can make Reynaldo actually trust them, the more likely he is to allow you to do the thing you're going to do. And it's not because Reynaldo thinks there's zero possibility that something bad can happen. He has pretty good confidence that, if something bad happens, I'm aware of it. Oren is not going off rogue, doing things we didn't talk about. He's doing things within this box. That doesn't mean the risk is zero, but I know what the risk is in this box, and I know how to respond to it. Whereas I've seen other folks who convince you to look over here while they're trying to not let you know they're doing other stuff. Yeah, you may get some data, but you're also losing that trust. And man, that's not a place you want to be, especially in OT, because you do it once and you're out the door. You're never allowed on site again, or anybody else's site for that matter.

Reynaldo Gonzalez (20:53): You're right, but it comes down to a few different things. When we had the conversation, we talked about how trust is a very big part of it. The expectations have to be very clear: the rules they've got to follow, being transparent. And on the asset owner side, we also have to be clear about what we want. What kind of perspective for that pen test do we want? Is it external, internal, assumed breach? There are a lot of different factors that go into it. And if I'm the one engaged with Oren, it's not just my input or my requirements I'm considering. I have to have those internal conversations to get that alignment and say: before I even share all the details with Oren, here are the things we want to address. Maybe it's driven by a cybersecurity initiative. It could be audit related, it could be something tying back to clients, or it could be something we get pulled into separately. There are different stakeholders you've got to consider. It's getting the right alignment on the expectation, that we want to do these things to see these kinds of outcomes or this kind of information, and then sharing that cohesive message with someone like Oren, whoever is going to be doing that pen test, so we can have that transparency: what we want out of the results, during the results, and what comes after, and getting that action done.

Hypothesis-driven pentesting and the top 20 weaknesses

Oren Niskin (22:33): And that goes into a lot of what we talked about in the talk: how to be creative about it. People say don't ever pen test a live plant, which I actually agree with. You don't want to pen test your plane as you're flying. But what you can do is set a hypothesis. Say I want to know if there are any protocols that can lead to compromise: Windows protocols like NetBIOS or Link-Local Multicast Name Resolution. There are some protocols where Windows will just hand over its hash if you use the protocol right. So you could capture passive network traffic and see if those protocols exist. And if they exist on the network, you can say: since they exist, I know I could probably spoof them and get your hash. You don't even really need to be on the network. What you need is somebody with an evil mind, somebody that thinks red, who can look at it, run a hypothesis, and find weaknesses. You don't necessarily have to own every box. You can gather the information you need to validate whether that weakness exists.

There are your top 20 weaknesses, and if you've got those covered, you're in pretty good shape. But when I actually go on pen tests, usually the top 20 are not covered. There's something in there. And these are places that have spent millions and millions of dollars on cybersecurity, with really talented OT cybersecurity professionals. But we all have blind spots. Having somebody with a different perspective outside of yours, who can help you identify the weak spots you don't see, can bring a lot of value, and make sure you're not wasting a lot of money on something you're maybe not ready for. Like a super advanced vulnerability management system when maybe you have a very easily guessable domain admin password. That's the one I used in the talk. I had this gif of a teenager learning how to drive: they look in their blind spot and there's actually somebody there, and they're like, whoa.

Prioritize the basics

Aaron Crow (24:43): What are you doing there? Why are you there? It's the analogy I've used as well: you don't put a paint job on a car that doesn't have a motor in it. More than likely, if you go buy a junker car, the first step is not to put a paint job on it. Let's probably get it running first. Obviously, if you're building a custom car that analogy doesn't exactly work, but you get the point I'm trying to make: prioritize what you're doing. Don't just go buy the latest AI thing if you don't have basic segmentation in your network. The talk I gave at DEF CON in Singapore was really just the basics. Do you have an asset inventory? The SANS five critical controls. Just basic. Do I have secure remote access? Do I have an asset inventory? Am I segmenting my network between OT and IT? Am I segmenting systems off? Just the basic-level things that don't have to be expensive. And I don't have to do a pen test to do those things. I can probably determine what's going on in my environment and make big changes by doing some of those really, really basic items.

Oren Niskin (25:53): The only thing I would add to that, and what I recommend: we all have what we like to do. Some people are asset inventory people, and they're like, "I'm doing the basics," and they spend their whole time getting asset inventory, looking for that last host on that subnet way down in Costa Rica. And other people are vulnerability management people: "let's do the basics." What I find interesting is that 80% of the value comes from 20% of your effort. Just getting the first 80% is a huge step. Then go on, like you're saying: get 80% of your asset inventory, then get 80% on network segmentation. And the pen test will help you say: hey, you're actually at 10% on network segmentation. You thought you were at 80. And we're seeing growing demand for that. People are wanting their systems tested. It used to be risk quantification and all this side stuff. Now we're seeing a lot of "don't tell me, show me." I think that's really exciting, because that's what I like to do.

Pen tests as validation

Reynaldo Gonzalez (27:01): Something else, too, beyond the segmentation pieces and the visibility: the way I also look at a pen test is that it's validation. It's being able to architecturally visualize, but also proactively plan what your target state looks like. Whether it's a pen test or just in general, on the asset owner side you've got to have a good level of understanding of your current state. And it's not just some areas of technology, like "yeah, we know we have firewalls, we're doing segmentation." Look at the bigger picture: what else do we have in place that supports all the different areas that would be areas of consideration in a pen test report? Because different findings can mean you've got to improve your visibility, improve your controls for remote access, or how granular you get with segmentation: east-west, north-south, zones, DMZs, even just access to devices or hardened systems.

It's a very collaborative effort, from what I see. You've got to know the environment you're trying to assess really well, but also have an idea, proactively, that says: this is where we want to get to. Today we're here. We know, or we expect, we're doing these things, and to some degree it might be good, not as great, or just completely lacking. And we want to know what this output shows us. It can tell us: yes, we're doing this right. Or, like you said, you think you're doing 80% but you're really doing 10% segmentation, and that's a point that helps you. Really knowing the architecture and environment is a critical piece of whether there was value in doing that pen test report. A lot of times it can have that value, as long as those details are there, and the acknowledgement between the asset owner and the pen tester, and what you're expecting when you share, is very clear up front.

Aaron Crow (29:21): Yeah, and the other piece of that is the trust thing we talked about. When I'm doing these assessments or red teams or whatever you want to call them, we're walking in and I'm sitting down with folks who are doing a good job. They're doing the best they can. I try very hard to communicate: look, I'm not here to tell you that you suck at your job or that your baby's ugly. What I am here to tell you, to your point, Oren, is that I may see things you don't. That doesn't mean you're bad at what you do. None of the things I find are to say "aha, I'm smarter than you." That's not the point. The point is we may find things you didn't know. It's trust but verify. You thought you were at 80%; we're going to show you these other things. It's not "hey, you're bad." It's really just to say: here are some things, now let's go fix them together.

The any-any rule and the promotion gap

Aaron Crow (30:17): If those folks have that mindset and they're open to it, it's amazing how much you can get done. But when they're defensive, like, "well, the any-any rule in the firewall is at the bottom, so it's not really a problem": yeah, it actually is a problem. You shouldn't have an any-any rule in your firewall, ever, anywhere in your firewall. There are just obvious things you shouldn't have to justify. But when somebody's trying to defend it... and look, I understand why it's there. I've put in any-any rules myself. Couldn't figure out what the heck was going on, the plant needed to be running, and that's a way to make sure it runs. We put it in and it ran for a couple of weeks. But in the background I'm thinking: I know that doesn't need to stay there, and we need to remove it, because that's not a good thing to have. I've basically just turned this firewall into a router.

Reynaldo Gonzalez (31:10): Yes, the good old any-any rule. We see that more than we would like to count. And something similar can also happen at the lower levels, if you're using those kinds of ACLs and filters down at your switches, or even routers in some cases, where they're acting in a firewall kind of role. Those can get very long and messy from time to time, if you're always having to manage them, or update them, or make an exception: "okay, we're going to make an exception just this time." And then these one-offs become consistent one-offs. When it comes down to that level of rules and segmentation, you get to a point where you have to reassess, or start looking at capabilities that can take the way you've managed that network and those rules and do it in a more logical way, without all that administrative burden. And for that, you've got to do the right level of reaching out to see what solutions out there can do this. But just because one says "we can do it," you've got to validate it. You've got to check to make sure it can actually do what it says. There's a lot of effort that goes into it.

Oren Niskin (32:53): And then you get promoted, and this poor guy comes up and takes ownership of all this stuff, all these exceptions. That's a problem I see in IT a lot. In OT, nobody gets promoted. Well, people get promoted, but at the plant, everybody knows the plant so well. That's my favorite thing: when I find somebody at the plant and they hear a noise and they're like, "that's the number two fire pump." For real? You know that's the number two fire pump from the sound? They're like: yeah, that's the number two fire pump. Those are the kind of people you find in OT. But in IT, generally, people are moving all around, and people leave the company. The CISO is in place an average of two years, maybe. And a segmentation project usually takes years in OT. So just as that thing is rolling out, he's quitting, the next guy comes in and says: what is all this? Yank it all.

Aaron Crow (33:37): Eighteen months, I think. Yep: that's not my vendor, I don't like it that way, let's do it a different way, let's adjust. It can be very frustrating. And then there's the other conversation. I came from the product vendor side as well. You've got vendor X and vendor Y, and the new CISO comes in: I like vendor Y better. Whether it's a firewall or whatever the product is. Okay, maybe it's better, maybe it's got new capabilities, whatever, but we haven't even finished implementing the one we have. Before we start jumping ship and changing to something that's got better features, let's get the features out of the one we already have. We haven't even deployed it all the way. We're not even monitoring it. There are all these things we're not even doing, and you're already looking at the competitor's next version. I get it that they took you to dinner, but let's just stick with what we've got until it's time to go down the road a little further.

Oren Niskin (34:55): I do like those dinners.

Tool sprawl and rationalization

Reynaldo Gonzalez (34:55): Actually, on that point: the tool rationalization piece is an ongoing challenge that all the companies deal with. I'm sure you hear it too, Oren, and Aaron, you've seen it. At these events I talk to a lot of different peers and leaders, and it's: how many tools do you have? Yeah, way too many. Forty, fifty, sixty, thirty-something. And then: well, how many are doing this particular area? And you can probably get at least two or three called out that are doing those kinds of things. That part of rationalization and architecture is saying: let's look at what we have first. If you go into a role, or you come into a company, you already have this whole tech stack, and depending on what your role is on that team, it might be that you have to look into it. On our side, with architecture, that's something we want to understand. We should understand. We've got to know what we are effectively using, configured and working for our cybersecurity roadmap, aligned to the vision and the goals you're trying to achieve.

When we have these tools, go back and reassess: who are the consumers of that tool? What are they using it for? What kind of capabilities and features do we have turned on that are actually being leveraged? Then start comparing that with all the other tools in your tech stack, and you start to see where there's overlap and where there are gaps. That starts making more sense in how you rationalize what you have in house. Or is there an opportunity to fill a gap these tools can't, whether it's a limitation or extra money you'd have to go invest? That becomes a different conversation. But it's being proactive enough to go do that, and it takes the right level of mindset to push it.

Aaron Crow (36:57): As you look at the bigger picture in a mature program, that's what you're talking about. In some of these larger programs, I'm going to have the Venn diagram of capabilities, and there are going to be overlaps, and there are also going to be gaps. Those are the things we're looking for. If I have an overlap, sometimes having two different sources of truth is good. This thing is telling me A and this thing is telling me B; they should be telling me the same thing. Why am I getting different signals? Or, hey, they're both telling me the same thing. They both say it's 73 degrees in my room. Cool: I've got my thermostat that says it's 73 degrees, and a thermometer on my desk, and they're both saying the same thing. That's awesome. If the thermometer on my desk says 80 but the thermostat says 70, there's a problem, because it actually is 80 and the thermostat says it's not. So sometimes those overlapping things are good. On the flip side, from a cost perspective, many times you ask: do I need both tools? Is there enough overlap that I can reduce my tech stack and have fewer tools, the 80-20 rule Oren was talking about? There are all sorts of ways you can look at it.

Build vs. buy and vibe coding in OT

Aaron Crow (38:20): And as AI comes out, I see more and more folks talking about: how can I build an off-the-shelf custom thing that we support internally, instead of going and buying the expensive things that are out there? I do that at home in my lab, obviously, in the things I'm doing. But doing that at an enterprise level, especially an OT level, is a different thing. If I were to approach Reynaldo and say: hey, I can build you a thing that does exactly what you're looking for. We can have one product, we'll build it together, and it'll fill all of your gaps. That sounds great, and I'm not saying we shouldn't do it, but there's a whole bunch of risk behind that, beyond just the cyber thing. Who's going to support it when Aaron leaves? How do we know it's going to work? How are we going to stress test it, and all these different types of things? The reason you're buying these commercial off-the-shelf products is that they've done a lot of those things. There's support around it. The code has been tested and gone through all these different SOC 2 analyses, and they've smoke tested it and all that kind of stuff. I think a lot of people aren't thinking about that. Just because I can vibe code something and it works does not mean it's good enough to put in my production environment and depend on. I don't want it flying the plane for me. Not yet, at least.

Oren Niskin (39:47): And going back to what we were saying before: active scanning was bad enough. If I vibe code something and put it in there, and lightning strikes outside the plant and kills all the PLCs, they're going to blame my code for sure. Anything that happens in that plant is my fault. I vibe coded this thing; anything that happens in there is going to be my fault, period, forever.

Aaron Crow (40:10): "Oren's Terminator just killed us all."

Oren Niskin (40:14): That's right.

Overlap as complement: steering by the attack path

Reynaldo Gonzalez (40:19): The other thing we've got to look at is how tools complement each other. There will be overlap in a lot of different capabilities and tools; a lot of tools do many of the same things. But sometimes "the same thing" can mean the way it analyzes data, the way it captures it, the way it presents it, targeting a specific view or interest for some customers or some groups, while the overlap it has with another tool is presented in a different way. Like you're saying, overlap is not necessarily a bad thing. There's some overlap you might need, but there's also overlap where, categorically, they might be in the same group, but they're actually doing different things. They appear at the surface to be the same, but they complement each other in what one does and the other offers, or how they enrich each other. That's also key when you're rationalizing what you have and making those decisions. Where is the opportunity? Where is there a way for us to fill gaps? Where can we expand and grow? It depends on the use cases and how folks are using them. You've got to make them effective and use them the right way for them to have the right impact.

Oren Niskin (41:37): And I go back to our pen test conversation, which I think people are coming around to: my next step maybe should be the one somebody used to gain access to my system. Then you could say: I thought I had coverage here, but they got around my detection system. That's where those complements can come in. Maybe I want to add Windows Defender, since I can run Windows Defender alongside another endpoint protection and have both of them running, or have two sources for my network detection. You have a strong business case if somebody used that path to attack your system, and you can steer your investments like that, instead of trying to do it off maturity diagrams or something. That's what we were talking about in our talk: the value you get out of it, and the risks. I spent a lot of time on the risks.

Aaron Crow (42:37): Well, there's a lot of risk there, right?

The risk of doing nothing

Reynaldo Gonzalez (42:37): Yes. And there's also risk in not doing anything, right? We hear that often.

Aaron Crow (42:49): And that's the catch-22. To your point there, Ray: the risk of doing something means I'm bringing in these things, I'm changing my process, people don't like change, and I'm allowing somebody scary like Oren to come in and scan my network. But on the flip side, not allowing Oren to come in and scan your network, or penetrate, or interrogate, or talk nicely to it, whatever you want to call it, means that you don't know. Putting your head in the sand and hoping that you're good isn't enough anymore.

Ten years ago, when I was doing this, to Oren's point: I've been doing this longer than it's been called OT. When I first got into this, it was just the O. It was: hey, you're in this power plant company, you know technology, and you also know the operations side, so we're going to put you focused on these things. It wasn't called OT. There were no industrial or OT products in the world. So when you're looking at these things, we have to think about the big picture. What are we doing? Why are we here? And I can't just pretend it's not going to happen. We see these things in the news. We're seeing attacks hit critical infrastructure. We're seeing attacks hit manufacturing. We're seeing ransomware. We're seeing Colonial Pipeline-type events. These are regular events. No matter what some of the pundits say, that there's never been an OT attack: there are OT attacks all the time. Just because they're not reported doesn't mean they didn't happen. I've personally been at more than a handful of incidents that are not public, which I'm obviously not going to mention for those reasons, but they were absolutely OT attacks, and they brought down very, very large critical infrastructure environments. It happens. So doing nothing is no longer an option.

Reynaldo Gonzalez (44:53): And to go along with that, there's also the fear of knowing you then have to take action. Okay, not doing anything has a risk. But there may be some people, and I spoke to a few folks at these events, who say: well, do you want to know? If you do a pen test, with these results, now you know. There's something that has to be done. And some responses I've gotten from some people are: well, I don't want to know. Because if I know, I now have to do something about it. And I get it, because now you're kind of forced. But just because you don't know about it doesn't mean you're safe from it, or that it's not going to happen. You need to know. It could be that you're not ready to act, or you don't have the technology, but at least you're aware of it, and then you have to plan or have some kind of action. And at the same time, it doesn't mean you're accountable for all those steps. It might be that you drive part of it and other groups are accountable. Maybe they're not ready, but at least they're aware and they can prioritize. Being fearful of knowing, being oblivious to it, does not make you any safer than trying to be proactive about it. That's a mindset.

Porting safety culture into cyber

Aaron Crow (46:17): To me, that's the same as the safety culture, if you've been in OT. There's a reason why we do pre-job briefs and safety briefings. We have challenge coins: stop when unsure. A junior person can walk up to the most senior person and say: hey, this isn't safe. Stop. And there's no retribution from it. If I'm doing something unsafe, it's not that I'm getting reprimanded; it's actually that I want you to be safe and go home, and I don't want you to get injured. It's okay that I'm getting "reprimanded," quote unquote, told not to do something, because it's not safe. I don't want you to stand on the chair to change the light bulb. I want you to go get a ladder, and somebody that's authorized to stand on a ladder, and change it out correctly. Yes, I know it's a pain in the butt, but you can also fall out of the chair. Little things like that are a big deal.

So when we bring that culture in OT and start including that same culture around cybersecurity, it shouldn't be "I don't want to know." It should be "I do want to know." It doesn't mean I can do anything about it. But even if I can't make a change, even if I can't buy a product, I'd rather know it's there, so I can raise my hand and say: hey, by the way, we have this risk. Maybe it's improbable it ever gets impacted because of X, Y, and Z, or maybe I just don't have the money to fix it. But it should at least be documented, so we know it's there. So if something does happen, at least everybody knows: by the way, this thing is really flammable, let's keep fire away from it. And if it does catch on fire, I should have a plan: the fire extinguisher is over here, and here's our process. I'd at least like to have a plan for what happens if the bad thing happens, instead of just pretending I don't know it's there. Because you probably know it's there anyway, and you just don't want it documented, which to me is a level of ignorance that is beyond acceptable.

The cyber dentist question

Oren Niskin (48:26): So I've got a question. I think it's almost an emotional thing. I know people, some friends of mine, obviously not me, of course, because I'm perfect: I know people that don't go to the dentist because they don't want to know. That's a classic thing. Of course it would be better if they knew either way, but it's an emotional thing, and they know it's not good. So how do you make people more comfortable going to the cyber dentist?

Aaron Crow (48:55): Again, to me it's a culture thing. It's the same thing we've done in safety. If people think they're going to be reprimanded because something bad happened, because there was malware or an attack or a vulnerability, or the PLC went down, then they're not going to tell you. They're going to try to cover it up, or pretend they don't know, and they don't want to fix it. If they feel like their environment is accepting, where I can raise my hand and say "hey, there's a vulnerability or a risk over there," and people aren't going to scream at me, then we can document something. Again, it doesn't mean we have to change it. But that culture has to be one of acceptance, not reprimand.

And we've done a great job in OT with that. I keep going back to the safety culture: zero is the acceptable safety risk. We want zero incidents. Safety zero. That's what we talk about. I don't want somebody dying. There is no level of death acceptable in my power plant. It sounds stupid to say out loud, but there was a time when that wasn't communicated, and that wasn't the actual official standing. Not that they really officially accepted it, but by not un-accepting it, however you want to say that, they were by definition accepting it. So build that same mindset. It comes at the organizational level, from the top down and the bottom up. They have to understand that if I raise my hand and say "hey, this is not safe, we have an any-any rule," or "I'm using a Netgear firewall or router or switch in this space, and that's not okay," you should be able to raise your hand as a junior person and say: that's a vulnerability, we really shouldn't be doing that. That doesn't mean I have to rip it out and break the system. It just means it needs to be documented, so it can get put into the pipeline of how we fix it long term, so that risk gets removed.

Reynaldo Gonzalez (50:57): I want to add a couple of things to that. There are a few different factors that make sense to me, and I agree with you both: culture is a big part of it. And along with that culture, it also comes through the leadership style, and how they allow or empower their employees to speak up. Hey guys, we're all after the same thing. If this gets impacted in any area of that site, it affects everybody, because at the end of the day we all work for the same company. So it comes down to leadership having the right message, and the comfort you have in that team, where you build trust with your employees and among each other. Maybe have some kind of outing event where folks mingle and have more team connection, so they feel comfortable with each other.

Because it's also personality. Individual personalities: some people are just more shy than others, some are more outgoing, some are very candid in what they say, and others are very quiet. Work around the different personality types, but empower them. If you have a concern, raise your hand, like you're saying: hey, this might be an issue. Whether you're right or you're wrong, it's okay. And especially with the senior guys: if a junior person says something that turns out to be wrong, don't be condescending to them. Help them and support them. Teach them. We need to be able to pass on that kind of knowledge at the same time. So it goes back to the team: the mechanics, the chemistry of the individuals. A big part of your culture is that empowerment. They've got to feel like they are valued, and they are valued, and be empowered to bring those things to the attention of the right folks.

Oren Niskin (53:24): Maybe even expected to, right? Like: I expect to know where my risks are, so you need to tell me. Don't keep it a secret. That's what they said in the Navy: don't keep a secret.

Aaron Crow (53:31): Yeah. And going back to that safety culture: I think about power plants when we're doing outages. Maybe it's a three-month-long outage, and the whole time, the whole point is safety zero, safety zero, safety, safety. That's the first and only goal. And the safety team would actually have a budget. At the end of the outage, if we had a safe outage, there would be a giant party. They'd have a fish fry, they'd bring in barbecue, and they would feed the entire outage staff. And whoever did the most safety observations: if I saw Oren doing something unsafe and I wrote him up about it, Oren and I were talked about in a positive way. Because I submitted that thing, I got added to a list, and maybe I won something.

Oren Niskin (54:32): A shotgun.

Aaron Crow (54:34): A shotgun, there you go. Or a gift card, or a day off, whatever that thing is. But to your point, it's all about that culture, and enticing people to say: not only is it okay, it's actually demanded. We demand that we do this. No incidents. It's like your phishing campaigns, when you're running PhishMe or whatever campaigns you have. Instead of getting onto somebody when they click the link, because the links are really good now, so it's very easy for that to happen, let's entice them to be looking for it. Whoever reports the most phishing emails gets the new Apple device, or a gift card, or whatever. Now, obviously there are some things you've got to design into that, and I'm not telling you how to run a program, because people could take advantage of it. But you get my point. It's all about the earnestness of doing this for the right reason, communicating, making it fun, and making it something that is not looked down upon.

The free t-shirt phish

Oren Niskin (55:31): They finally got me, Aaron. I finally clicked one. I was so embarrassed. They finally got me after all these years.

Aaron Crow (55:33): Did they? It happens, man. But why did you feel embarrassed? That's the mindset we've got to understand.

Oren Niskin (55:42): I know, that's the thing. I should know better. Nobody jumped on me about it. I don't even think anybody knew about it. But it was definitely like: ooh, that's a good one.

Aaron Crow (55:53): And it happens. It's going to happen to everyone. Everyone's going to click one. I literally reported one this morning. With AI and everything else, they're going to get better. We expect things to be done unsafely, we expect people to get injured, we expect incidents to happen. It should be the same around cybersecurity, and we should have a culture of: okay, what can we learn from this? How can we make sure we don't do this again? Instead of saying: Oren, how could you? How are you so stupid that you clicked on this link?

Oren Niskin (56:25): "You work in cyber."

Aaron Crow (56:48): It should be: okay, if Oren could click on this link, imagine how many other people probably clicked on it who aren't in cyber. How can we make sure everybody learns from this so it doesn't happen again? That's what we should be thinking. It shouldn't be "how dare you, Oren." It should be: wow, Oren, tell us what made you get hit by this. Of all people, with as much experience as you have in this, explain to us how that happened, so we can make sure everybody else thinks about it and looks at it the way you didn't this time, but maybe you can next time.

Oren Niskin (57:04): They offered me a free t-shirt and I instantly clicked.

Aaron Crow (57:06): There you go. So now everybody knows how to get into Oren's inbox.

Oren Niskin (57:12): That's right. Swag.

Building the next generation

Oren Niskin (57:17): Another reason I submitted for this episode: Reynaldo and I gave that talk at OT.Sec.Con about pen testing, the conversation between asset owner and pen tester, and it's really awesome. But Reynaldo is also super into bringing up the next generation. I wanted to talk about that, and what I'm doing in education, and how it all works together.

Aaron Crow (57:41): Sure, a hundred percent. Let's definitely dive into those. One of the reasons I do this podcast is exactly what you just said, Oren: to give back. We need more and more people coming up, understanding these conversations. So Ray, what are you doing? How are you bringing more folks into this space, and the training and learning and all the goodness that we need? Because we need more people.

Reynaldo Gonzalez (58:10): Actually, I was talking to Oren about this some time back, and a few others. Aside from being in the field of cybersecurity architecture and OT, I also teach classes at Lone Star College. I've been teaching a little over fifteen years now. It's more evening-type classes, mostly adults, but now it's a combination of folks who are either in the field of IT, or some kind of cyber, or even non-IT and non-cyber, and people are coming into cyber. I started teaching first on the networking side: I would teach the CCNA and CCNP courses. And for the past several years I've been doing cybersecurity: fundamentals of cybersecurity, the CCNA CyberOps course, the ethical hacking course. Those courses are taught based on the content from those modules from Cisco, and the MindTap Cengage program we use.

When I have conversations with students: a few weeks ago I did a presentation for the college, where they wanted me to talk about cybersecurity and AI. It was taking the experience of what we go through as cybersecurity leaders, and where AI is at and where it's going: how AI and cyber mingle, what it does for offensive purposes and defensive purposes, both pros and cons. But the idea there is trying to show students that you don't have to have a lot of exposure in IT or cyber to get into cyber. You've just got to have the interest.

And that's where I really like to help them. A lot of the questions they ask me are: how do I get into cyber? How do I know what part of cyber is for me? How can I learn more about it? So one of the questions I ask them is: well, what do you do right now? If it's cyber, great. If it's IT, great. But what do you do? What are you into? What are your hobbies? What do you know about? And based on the response, I take that and say: if you think about it, you already know a lot. Say someone's coming from being a mechanic, and they know these different parts and how they connect. I say: can you tell me which parts are electrical, which have some kind of configurable option? Well, those are actually related to IT. If you know the inner workings of being a mechanic, you know how it's supposed to work. You know that if you do these things right, it does what you expect, and if you mess up here, it's going to break or cause an issue. Well, put your bad-guy hat on and say: if I wanted to be malicious and intentionally break this, I know I could do X, Y, Z. You know what works and what doesn't.

Cybersecurity is kind of the same thing. You want to know how to defend and protect something, and think like a bad guy who would try to break it, knowing how they would do it, because you have that background. Now you can go into that defensive approach. If you think about it, you're already in the space. You've just got to learn some of the terminology, the basis of what cybersecurity is: the terms, what a black hat and a white hat are, what a virus is, what OT is, all these other areas. Learn some of these concepts, and now you can get into these fields and domains, learn the basics of how these things work with what you already have, and then you just grow. A lot of the education side is giving them those real-life examples, showing what you can easily do with this part of technology and how you get into it. The interest starts to appear, and you've got to have that interest, because you will struggle. Is it going to be easy? Some yes, some no. Is there a learning curve? Yes, it depends. But as long as you're determined and you're interested, it doesn't matter. Everyone can learn tech. And then you've got to build on the social skills too: communication.

Oren Niskin (62:40): You've also got Youth.Sec.Con. Youth.Sec.Con is awesome.

Reynaldo Gonzalez (62:44): That's right. And attending those events is another way to learn.

Hiring troubleshooters

Aaron Crow (62:51): As I've built out teams in my past, and currently, whether at EY or as an asset owner: early on, when I was an asset owner hiring folks for this OT stuff, the OT word didn't exist, and I needed to find people who could fill the roles I had. It was really hard to find somebody with the skill sets I needed, so I was looking out to skilled-labor type folks, because I'm looking for a mindset. I would rather have a mechanic or an electrician who can problem solve. Because what is a mechanic good at? Troubleshooting. You bring in a car, and most people don't know what the heck is wrong with it. "I don't know, it's making a noise, and it seems weird." They have to figure out what that means and deduce what's going on across all the components and systems in that car, and say: well, your alternator's out, or your front wheel bearing is bad, or whatever. Mechanics are great, amazing troubleshooters.

I can teach you technology. It's harder for me to teach you how to troubleshoot. It's harder for me to make you have a questioning attitude. That's something that's very difficult to teach. So for somebody who has that as a skill: I can teach you how to subnet, how to work a CLI, what commands to run on a firewall, all that type of stuff. It's harder to teach that troubleshooting mindset. So find the people who have that capability. If you have that ability already, it doesn't matter what your past is. I can teach you the technology stuff, and you'll be really good at it.

And Oren, it's why you came from this. You started on the operations side, and you were troubleshooting. Something's not working, so you're tracing wires, looking at voltages, going through a process. Yeah, there's documentation and things, but a lot of times it's trial and error. That translates directly to technology. It's just doing it in ones and zeros and bits, as opposed to physical wires. It's the same process mentally.

Oren Niskin (65:06): And that is super addictive, by the way.

Aaron Crow (65:09): It is. Which leads us to your labs and the things that you're doing, Oren.

The PLC trainer kit, live on YouTube

Oren Niskin (65:15): Yeah, very cool. So I've got this kit here. If you're watching on video, it's pretty awesome. What this kit is: I'm building an entire OT system, from PLC wiring and the physical process all the way up. Now I have an Ignition HMI, so that's a Linux server, and then network security monitoring on top of that with open source tools, Suricata and Zeek. And then I built an industrial DMZ with a firewall and a web proxy. These are all things you would find in a real OT environment, and I walked through how to build all of it on YouTube, live on the stream. And next week, or I don't know when, I'm going to do, like you did, an Apache Guacamole remote access server. Then I think I'm going to do GRASSMARLIN, and I'm just going to keep going and going and going with all this stuff.

There's a little cadre of us building these kits together, a little community of all kinds of people. It's crazy, the diversity of people. Some of them have been in industry, in OT, for years. Some have been in IT and want to move over. And some are right in either high school or college. A wide variety. I'm getting a lot of joy out of it, because when I first moved into OT cyber, like you're saying, it was hard to find OT cyber people. And it felt good, because I was the one guy with the candle. I had the light and nobody else did. But our industry is suffering because of that, because you can't really make a big fire when you have one guy with a small candle. My situation, everybody's situation, would be better, even career-wise, if we had more people in OT, and more people like Reynaldo at asset owners who understand it. That's what I'm trying to do with this kit.

My new favorite thing to say is: the most important next gen tool you can have in your business is the next generation of human. That's the real next generation. I took that picture of me with a bunch of really smart kids at LSU who are all building this kit, and now they're going on to internships and starting their careers in OT. And another thing I really like about it: it's not a lot of talkie talkie. It's less talk, more walk. People like pen testing and they like actually doing stuff, which has been lacking. We all see really long PowerPoints and webinars from vendors, but I think people are really itching to do something. This is something you can do for pretty cheap, it's a lot of fun, and it's all skills that people will pay money for.

ICS Village and passing the torch

Aaron Crow (68:18): A hundred percent. And that's awesome, folks: get in there, look at the YouTube, follow along. There's so much you can do. I'm building them back here a little bit differently, but the same type of thing, with ICS Village, for some trainings we're looking to do: OT entry-level type courses that people can follow along with under the ICS Village nonprofit brand, doing those maybe at DEF CON and maybe in other places. Not quite as hands-on as yours as far as building a PLC, but actually interacting with a pre-built PLC. And it doesn't have to be super expensive. Our whole goal is to have the kits at 500 bucks or something like that, something somebody can get into. They can mess around with Zeek and Suricata and a firewall, understand an HMI, and a little ESP32 that turns on a light or turns on a pump or does something simple. Yes, it's not something you'll see in a plant, but the concept is the same. It's using OpenPLC, it's using Modbus, it's using DNP3. It's using the same types of things you're seeing in these spaces.

I guess our point here is: you've got three people on the screen, or in your ear, that you're listening to, and every one of us is doing this. None of this is my job. It's not necessarily Oren's job. If it is, maybe I'm getting a little bit of something here and there, but that's not the reason we do it. We do it because we want to build that next community. We want the next folks to come behind us, because, to Oren's point on the fire, we need to pass the baton. We need to pass the torch to the next generation of folks coming up behind us, because eventually we're going to have to retire, and who's going to be behind us to take that forward? Hopefully they're in a better place than where we came in, and we leave it better than we found it. That's my spiel. Thank you both for all that you're doing.

Oren Niskin (70:19): I was going to say thank you guys, because I got the bug from the ICS Village: walking around and seeing it in real life, and being like, that's a city right there, and there's a PLC, and I could just log in and tell that pump to turn on, with no nothing. That's crazy. It was really cool to see.

Reynaldo Gonzalez (70:43): Really quick: my first time going to DEF CON, two years ago, I was so overwhelmed with all the different villages. When I saw the ICS Village I was like, that's really cool. I saw the aviation village and all these other ones; the social engineering village was insane. It just makes it more interesting, like you're saying, Aaron. We've got to help the next generations learn this stuff and get interested. That's also why we're getting involved in these youth programs: to get folks in high school and college more into cybersecurity. And like Aaron was saying about getting ready to retire: even in the field at these companies, a lot of people in that OT space have been there for many years, and soon they will retire. Who's going to take over their knowledge? We need to be able to transfer that. We need a lot of that young interest to come into this area, start learning, and take over, because we've got a lot of critical infrastructure that needs continual protection.

Aaron Crow (71:51): Yeah, absolutely.

Oren Niskin (71:53): No crawling in bilges required.

Aaron Crow (71:56): Exactly. But sometimes that's the fun part. We're taking an intern with us to a client that's doing some really cool stuff, munitions destruction and things like that. So we're taking an intern who's in college, looking at cybersecurity, to some field sites, taking them along with us. Put on a hard hat and safety-toe shoes, and let's go actually see some real stuff. You're going to get dirty, but that's okay. That's part of the fun. It's why I'm always smiling. It's why I have all the things that we do here. I could be in IT. I could be sitting at a desk, managing cloud and all that, and there's nothing wrong with it. I just really enjoy this. I enjoy contributing to protecting critical infrastructure, and things that are ugly and messy and loud and different. I caught the bug, kind of like what you said, Oren. I really just said: yeah, this is where I need to be.

Oren Niskin (72:54): That's my favorite part, hands down. Site visits: watching automated frozen pancake orders and coffee cup fillers and all kinds of crazy stuff. I met a guy once who said that if How It's Made isn't your favorite show, he wouldn't hire you. I said: I want to work for that guy. That is my favorite show.

Outro

Aaron Crow (73:11): That's right, or Dirty Jobs, all that type of stuff. You never know what you're going to see. Well, awesome, guys. Thank you for your time. I appreciate, again, all that y'all are doing. Definitely reach out to Oren and look at what he's doing. Look at what Ray's doing. Go take their classes, go dig into the content. There are resources out there that are available; you just have to take action. So step in. The opportunity is yours, and there's a great career behind it. It's not easy, and I'm not going to pretend that it is, but it's worth it. It's really valuable, important work, and it's a great community to be part of as well.

Reynaldo Gonzalez (74:01): Always reach out. Message away, LinkedIn message away. Very happy to help others.

Oren Niskin (74:07): And it'll be a happy day when I see your pull request on the GitHub, contributing some of your awesome stuff to make everything better for us. That's a good part I like.

Aaron Crow (74:14): Exactly. Yeah, for sure. Well, awesome, gents. Thank you again for joining me, round two. I appreciate it, and this time it went well. Good job on the mic, and thanks for joining me today.

Oren Niskin (74:31): Thanks, Aaron. Thanks, Ray.

Reynaldo Gonzalez (74:31): Thank you both. Appreciate it. Thanks for having me on as well.

Transcript lightly edited for readability.