Our Help Desk Plaque Reads “Over 100,000 Threat Actors Served”

Our Help Desk Plaque Reads “Over 100,000 Threat Actors Served”

The shine is off the cybersecurity promise of MFA. While its certainly vital to implement, threat actors are increasingly finding ways to get around it. Most recently we’ve seen social engineering proving effective at this, targeting the help desk. Given the high profile attacks we’ve seen getting around MFA, how much security stock should we put into it going forward?

This week’s episode is hosted by me, David Spark (@dspark), producer of CISO Series and Andy Ellis (@csoandy), operating partner, YL Ventures. Joining us is our guest, Martin Mazor, vp and CISO, onsemi.

Got feedback? Join the conversation on LinkedIn.

Huge thanks to our sponsor, Material Security

Material Security is a multi-layered email threat detection & response toolkit designed to stop attacks and reduce the threat surface across all of Microsoft 365 and Google Workspace. Learn more at material.security.

Full Transcript

Intro

0:00.000

[Voiceover] Best advice for a CISO. Go!

[Martin Mazor] For new CISO or an expanded CISO role, always focus on quality, not quantity. Focus targeted metrics of performance, targeted goals, targeted frameworks. Get those done. Don’t worry about everything in the world.

[Voiceover] It’s time to begin the CISO Series Podcast.

[David Spark] Welcome to the CISO Series Podcast. My name is David Spark. I am the producer of the CISO Series. My cohost for this episode, it’s Andy Ellis. He’s the operating partner over at YL Ventures and a long time former CSO. Also, did your title go from CISO to CSO, or did you. when you kind of bumped to that role immediately became CSO?

[Andy Ellis] It went straight to CSO partly because I’d already owned the domain name CSO Andy, and so I decided that I did not want to have a title that didn’t match my domain name.

[David Spark] You know what? That’s a great idea for anybody is get the title you want and your name.com.

[Andy Ellis] Yeah.

[David Spark] And then when they give you the title, go, “No, it has to be vice president because it’s vicepresidentdave.com.”

[Andy Ellis] Right. I mean, the challenge now is I’m a CEO. I’m an operating partner, so maybe I should create a whole bunch of websites with all the different titles I carry, but I don’t know that I can afford that many.

[David Spark] [Laughs] Good point. By the way, an excellent tip though for moving up in your job. We’re available at ciso-dev.davidspark.dcgws.com. There are other programs on our network. And if you have yet to discover them, please go check them out.

[Andy Ellis] But only after you’ve listened to all of our episodes.

[David Spark] Yes, go back through the entire archive, even before Andy actually joined.

[Andy Ellis] No, those don’t matter as much.

[David Spark] Don’t matter, the ones earlier… I’m always amazed, by the way, that there are people who do go back to episode one. Which, by the way, I do not recommend. I can’t stress that enough. The first few episodes are embarrassing.

[Andy Ellis] Yeah, never do season one.

[David Spark] Yeah. No, season one got good, but the first few episodes of season one I would avoid I if were you.

[Andy Ellis] Yeah.

[David Spark] Our sponsor for today’s episode is Material Security – secure your productivity suite. Aw, everyone is using one. And is your security up to snuff? Well, we’ll be talking about a little bit later in the show. But first, Andy, we’re recording this considerably before RSA, but this is going to air the week after RSA, so we’re making our predictions now.

People can call us on it because they will hear it right after RSA. Your prediction as to what the topic… And, by the way, it’s going to be pretty obvious what the buzz topic will be at RSA this year.

[Andy Ellis] I think the buzz topic is going to be AI enabled, and that’s a really key piece of it. There will be a lot of folks saying, “I’ve got AI.” Everybody is going to be like, “Yeah, whatever.”

[David Spark] By the way, we’ve seen AI on boards in booths everywhere for the couple years.

[Andy Ellis] It’s been there. But I think the key is going to be how are you adding AI into your product, not as a core capability but as a thing that is enabling whatever your core capability is. I’m hoping we’re going to see this level of maturity in marketing where people aren’t just going to say, “Hey, I’m AI.

Buy me.” They’re going to say, “Look, I’m AI enabled static analysis or static application security testing.” Whatever it’s going to be. It’s just AI enabled.

[Martin Mazor] And it actually does something this time. [Laughs]

[David Spark] By the way, that’s our guest, who I’m going to introduce in just a second, but hold on. Let me ask you a quick question, Andy. Have you done anything with AI outside of like these image generating programs, which are incredible? But have you used, say, ChatGPT for anything you’re like, “Oh my God, this saved me a week of work.” Like something…that much work?

[Andy Ellis] Well, I don’t know that I’d say a week but definitely it’s saved me multiple hours. I do a lot of these vendor webinars where you come on, and you’re the talent. And they’re going to say, “Hey, we’re going to ask you ten questions. What should they be?” And I’m like, “Great, what’s your topic?” And I ask ChatGPT to give me ten questions.

And boom, it’s actually really good top ten questions.

[David Spark] By the way, we have leaned on ChatGPT for the games that we play on our Super Cyber Friday show. It’s been phenomenal. You give them the format of the game and the game… And, yeah, you do a little bit of tweaking here and there. But, oh, man, it saves a lot of brainstorming effort in an enormous amount.

[Andy Ellis] Yeah, it’s great at the questions. Then you say, “Give me the answers.” And the answer is actually not at al insightful. I would not recommend using them. But they’re nice like low stone for you to be able to say, “Okay, at least I just need to make sure that I touch on those topics.”

[David Spark] Yeah. Now, we are… And I don’t know the answer yet, but we are embarking on an effort with ChatGPT. I’ve actually got one of my producers working on it. If he’s able to pull this up, it literally would be a week or maybe two weeks’ work of one person if he can figure it out. It’s about trying to categorize vendors.

We have a list of vendors, and we’re trying to categorize them. And if we can get ChatGPT to do that for us, which is what I’m hoping…

[Andy Ellis] Oh, that would be awesome.

[David Spark] It would be monstrous. So, fingers crossed. This will be one of my big eye opening moments of ChatGPT if we can pull this thing off. Stay tuned. All right, let’s bring on our guest, who, by the way, he jumped in, but I want to give him a more formal introduction. He’s the VP and CISO for onsemi, Martin Mazor.

Martin, thank you so much for joining us.

[Martin Mazor] Hey, thanks for having me.

Um, maybe you shouldn’t have done that.

5:34.761

[David Spark] What are some of the classic blunders for a CISO? You can have the best of intention for an organization, but being too siloed can make cyber security stand apart from the rest of the org argued Bernard Brantley in a recent Dark Reading piece. Now, he pointed out some of the mistakes he’s made.

Now, these include not accounting for soft skills when assigning tasks to a subject matter expert, and the classic of not linking the CISO’s actions with business goals. He also highlighted the idea of tying security execution with a wider impact in the company, and he posed the question, “Am I implementing something to make my team’s life easier or to benefit those outside the organization?” All right, Andy, I want you to answer this two ways.

One is I want to hear your classic CISO blunder, and what do you think you’ve seen others…? Because you actually…you’ve mentored, and you work with a lot of organizations dealing with security. What are other classic blunders you’ve seen?

[Andy Ellis] So, actually single biggest blunder, and it won’t sound like one at first, is getting to be one of the approvers on product launches. Like every CISO in my generation was told, “This is what you want to be like. This means you’ve made it, that you have all of the clout and the power when you get to decide if a product can launch.” But the reality is the only person who gets to decide is the head of products.

Because if you’re deciding what happens, and they say, “Oh, are you going to stop this billion dollar product for this one thing?” And the answer is, “I’m the security guy. I’m not making a decision about your revenue. I’m making a decision about whether you did good risk management.” So, classic blunder, getting right in the way, and that train will just run you right over.

And they will happily run you over, so I got off of that track right quick. That’s sort of my classic blunder. I think the classic blunder I see from everybody and I see this even today is reporting on metrics that are meaningless. My favorite is click rate. Like, “This is how often people click on phishing emails.” Nobody cares.

And we all know it’s a made up metric.

[David Spark] And we’ve also heard the argument of it’s so variable, because you can create a simple one that no one will click on it, and you can create an incredibly hard one that everyone will click on.

[Andy Ellis] And everybody knows you can do that now. So, when you report on it, you basically lose your credibility because…

[David Spark] And when I say simple one, I meant phishing test. I’m sorry.

[Andy Ellis] Yeah, simple phishing test. Like of course nobody is going to click on it, but you want to send the gift card that says, “Hey, I know we’re laying off half your friends. Go treat yourself to a spa day.” Hey, you’ll get a lot of people to click on that one, and then they will hate you for it.

So, you hopefully aren’t doing that. But it highlights the challenge that phishing is really complicated, and these metrics that we use are just awful to talk about it. And everybody knows, and they’re not going to tell you to their face, but they lose a lot of respect for you when you start using those.

[David Spark] All right, Martin, I’m going to throw this one to you. Same thing. A, have you always been a perfect CISO your whole life? Have you ever made a blunder whatsoever? So, own up to yours if you have made one. Then what do you think is the most common CISO mistake?

[Martin Mazor] I would say my biggest blunder when I was kind of growing into the CISO role was trying to think that I knew more than the product or the business knew about their own product or their own business. So, sometimes that little bit of CISO ego that we all know about really comes into play.

That’s something I learned, that I’m not the smartest person in the room. And I’m here because I know something, but I don’t know everything.

[David Spark] I’ve heard that, and you don’t want to be able to do everybody’s job. So, how do you position yourself, if you’re not positioning yourself as the smartest person in the room? What is the difference between, “I’m the CISO. I’m the leader,” and, “I’m not the smartest person in the room.” How do you communicate that?

[Martin Mazor] I’ll tell you what I tell my teams, and I’ve told them for many years in many orgs, we’re a service organization. We’re here to provide a service. So, it’s the classic metaphor, I guess, of building a car. One function builds the engine. One function builds the brakes. One function, etc.

Right? We are one of those functions. So, we know our space. We know the brakes. But we don’t know how the engine works, so we need to be collaborative. And we need to be that service oriented discussion and group.

[David Spark] All right. Andy, I want to get your answer to that question, of like how do you not come off as the boastful, smartest guy in the room?

[Andy Ellis] Yeah, so one of the challenges is that security touches every engineering team, so you actually have to know a little bit about what everybody does. So, for me, the metaphor of like, “I’m in charge of brakes,” doesn’t work as much because I need to know about engine safety. I like to say we’re the sidekicks.

We are not the superhero. We’re not Batman, who’s going out and saving things. We are Alfred. We have to make sure that Batman’s suit works before Batman goes out and gets in trouble. So, we have to know as much or more about Batman’s suit than Batman does. But we’re never going to use it. And so it doesn’t matter if you’re smarter.

At the end of the day, you’re not the superhero.

[Martin Mazor] Yeah, I’ll just add to that. So, when you think about in a modern metaphor, again, of a car or an automobile… And actually working in manufacturing, you’ll know that the brakes don’t run independently. You’ll know there’s electronics. There’s integrations. So, if you’re just the brake function, you’re just the engine function, you’re just the electronics function, whatever you want to call it, those integration touch points have a pretty big impact.

So, it’s not an isolated silo, brake kind of thinking.

What’s the best way to handle this?

10:58.998

[David Spark] If you follow the cyber security news, you know threat actors are increasingly finding ways to get around MFA or multi factor authentication. Often with social engineering they do this. So, a recent article on Hacker News looks at different approaches, and there is the classic adversary in the middle approach.

There’s the MFA bombing someone with push notifications. That’s where they get so irritated, they just sort of relent, if you will. There is SIM swapping. And the recently popular, service desk attack like we saw with the MGM Resort where it was actually over the phone they did that. So, how common and successful are all of these, do you find?

And this is… The important question is do you still feel confident in MFA still securing identities given that these types of work arounds do exist? Martin?

[Martin Mazor] I still think there’s a value add here on MFA. Relying simply on who’s knocking at the door kind of protection model is certainly not a great answer either. Right? I’m concerned mostly about social engineering, of those kind of scenarios you mentioned. I think the complexity of SIM swapping, if you’re relying on some of that, SMS type texting responses, things like that, which I wouldn’t recommend… If you’re relying on those technologies, you can, I think, in some comfort level rely on them.

But the social engineering aspect and the complexities around that, I think, are going to be much more challenging. Of course the deep fakes and all that kind of world, which is becoming much easier and cheaper to do that, those, I think, to attacking the help desk and things like that are going to be much more prevalent and a focus area for myself and the org today.

[David Spark] All right. Andy, where are you on the confidence spectrum? And does this actually make you less confident, or you’re just as confident as you were before?

[Andy Ellis] So, I’m as confident as I always was in MFA, which is if you implement it well, it’s a fantastic defense. If you implement a really bad point, like, “Let’s attack on MFA,” it’s awful. Like if you do password auth and then after password auth you send an SMS push, what you have is single factor auth, which is SMS push.

Because the passwords have all been breached at this point. So, this is what you have to recognize, is how do you build an integrated authentication solution and tie in social engineering attacks into your threat model. Like we built this at Akamai. This is like the core of zero trust when people were first talking about it.

It was the big buzzword at RSA. Like I got up on stage and explained, “Here’s what we did.”

And what we did was actually fairly simple. Every device had an X.509 certificate on it. That was the first factor was you physically had a device that was registered to the person. And then once that device connected, you got pushed to a phone. We used a Duo. Happy to give them a few props here. I have no interest in them financially, so no conflicts there.

To say, “Hey, is this really you?” Not SMS but an out of band push. And so we had these two factors coming in nice and clean. You can’t trigger a push without already having authentication, which is an X.509 cert.

So, if you don’t have this, “Oh, I breached your password, and now I can push bomb you. I’ve got no SIM swapping attacks.” So, now all I have to do is talk about how do we deal with social engineering. Number one way that social engineering works in an organization is people are afraid of executives and are afraid to make phone calls.

If you make it that if you’re at all suspicious that this person is asking you to do something and it’s okay to call them, or their boss, or someone else, then you don’t have as big of a risk of social engineering.

[David Spark] That’s a very good point.

[Andy Ellis] Like we made it [Inaudible 00:14:40] that if you thought… Like the CEO had just called you and asked you to do something, do you know what you were supposed to do? You were supposed to email a wide opening mailing list and cc the CEO, saying, “I just got this call pretending to be the CEO, asking me to do this thing.” And the CEO would say, “That wasn’t me.

Awesome. Great job.” Do you know why it was this very large mailing list? So that we got real time training for everybody who was about to get social engineered. Because the reality is social engineers go after a bunch of your people, and they don’t talk to each other. Let them do so.

[David Spark] A CEO’s top job, if I understand correctly, is to request the lowest person on the totem pole to get them gif cards.

[Martin Mazor] Absolutely.

[Andy Ellis] Absolutely. Like all the time, “Get me gift cards.” So, our CEO would get up on stage at All Hands on a regular basis and put up phishing emails that purportedly were from me, telling him to do stuff so that people would know, “It’s okay that you get these messages, and it’s okay to challenge people, even to the CEO’s level.”

[Martin Mazor] The social engineering aspect is a constant engagement. I would add, though, with modern authentication. It’s not just the mechanism for authentication, the user access, whether it’s app push, FIDO keys, and everything else. It’s the telemetry you gain.

[Andy Ellis] Yes.

[Martin Mazor] The telemetry you can gain from those modern IDPs is just tremendous. So, you build your processes around that, and you’re more or less not relying on anything except a telemetry or primarily the telemetry and how you’re going to react to it.

Sponsor – Material Security

16:03.264

[David Spark] You remember at the top of the show, I told you about Material Security and that you could secure your productivity suite with Material Security. Well, let me tell you exactly how they’re doing that. Microsoft 365 and Google Workspace aren’t just applications. We kind of all know that. They’re critical infrastructure.

These environments are home to all your people, content, and communications. Securing these today requires a heavy set of disjointed tasks that leave blind spots and coverage gaps. Material Security is the only solution purpose built to address risk across the whole environment with the focus and depth required to make a difference.

Material provides a unified suite of cloud email security, user behavior analytics, and data loss prevention purpose built for Microsoft 365 and Google Workspace. Material integrates in minutes via Microsoft 365 and Google Workspace APIs with zero downtime. Customers get a single tenet, isolated incidents, and complete control over the underlying infrastructure.

Material works with organizations of all shapes and sizes. So, your organization is of a shape and a size, right? So, learn more about their advanced security for your cloud productivity suite at material.security. Simple as that. Just the word material.security. Put it in your address bar, and you’ll end up there.

It’s time to play, “What’s worse?”

17:32.808

[David Spark] All right. Martin, you know how this game is played. Two horrible scenarios. You get to decide which of the bad scenarios is the worst of the two. I make Andy answer first. You can agree or disagree with him. I always like it when you disagree but not required. Andy likes it when you agree with him.

[Andy Ellis] I get bonus points if you agree, so…

[Martin Mazor] [Laughs]

[David Spark] We’re not keeping score here, Andy. By the way, this person is anonymous. They don’t live as an anonymous human being. I actually know who this person is. But they chose for the purpose of this program, they wanted to be anonymous. I feel most of the times when people say, “I want to be anonymous,” it’s because the story they’re telling is extremely close to home.

[Laughter]

[Andy Ellis] Yep.

[David Spark] All right, here we go. And, by the way, these are slightly different. Okay? But they are different.

[Andy Ellis] Okay.

[David Spark] A publicly traded healthcare company was breached, and they began the process of figuring out how to respond. Millions of records. From the beginning, they knew they had incomplete records, meaning they had a name and an email address for a patient, and that’s about it. They had that in their database.

And they handed this database over to a reputable breach response company that enriched the data but could only do much and made quite a few mistakes.

[Andy Ellis] Those exist?

[Martin Mazor] Reputable?

[David Spark] Well, supposedly. So, the notification process became incomplete, and it was very expensive to get it from awful to crappy. By the way, I have done projects where I took something from awful to crappy.

[Andy Ellis] Yep.

[David Spark] So, they didn’t have a means to notify the people that were breached and have paid heavily for it through regulatory fines and reputational damage. Scenario number one. Okay, scenario number two, a publicly traded health care company was breached, and they get ransomed. They publicly decide to pay the very expensive ransom with the promise that the data hasn’t been leaked elsewhere.

So far it looks good, but who knows. They have incomplete data, but they realize it would be very costly to try to enrich it and alert people privately that they simply do not do it. So, actually this isn’t… I mean, these are opposites in a way.

[Andy Ellis] Okay.

[David Spark] But they’re both… The first one… Well, they paid off the ransom. First one did not.

[Andy Ellis] Okay.

[David Spark] But the first one knows the data was leaked. This one claims it’s not, and it so far looks okay.

[Andy Ellis] The ransomware broker told them that the data wouldn’t be leaked. But as we’ve seen recently, that doesn’t mean they’re the ones who had the data.

[David Spark] Yes. Yes. That pretty much… Anyways, just to conclude this one, they don’t know yet if they’re going to get fined, and the company’s reputation takes a hit. So, both of them get reputational damage. First one definitely got a fine. Second one, they don’t know. So, the second one is gambling.

The first one is not gambling, but they really kind of screwed up with the data, too, as well.

[Andy Ellis] So, for me, this one actually is pretty clear. So, I think I’m going to name our anonymous person will be Trolly Healthcare.

[David Spark] Okay. [Laughs]

[Andy Ellis] We got to pick which version of the Trolly you’re on. But in this case, I would rather be company one. I think company two has double screwed up. One, by paying the ransom in a world where we know, first of all, that that doesn’t guarantee the data actually gets destroyed. And second of all, you don’t actually know who you’re paying it to, and so you might have just committed a crime by funding some entity that is on a US government deny list.

And you’ve decided not to bother trying to do notification, which I’m pretty sure runs you afoul of a number of notification and breach disclosure laws. So, the fine is coming your way, but it’s going to be worse because you chose to not even bother doing the things you could have done. So, company one screwed up on execution but made all the right decisions.

Company two has made all of the wrong decisions and has decided not to bother executing, so they don’t screw it up. I think I’d rather be company one.

[David Spark] But, again, they don’t know yet if they’re going to be fined, so it’s not a guarantee. But you’re assuming this is a guarantee, they’re going to get fined.

[Andy Ellis] They’re going to get fined. And even if they don’t get fined, like this goes into the place of I would not want to work for that company.

[David Spark] Okay.

[Andy Ellis] You have decided not to fulfill your obligation to end users.

[David Spark] I throw this to you, Martin. Are you agreeing or disagreeing with Andy here?

[Martin Mazor] I think I’m agreeing. So, yeah, I agree. Yeah, the second company… They’ve already got the damage. They’re got the reputational impact. They’ve already got the being [Inaudible 00:22:03] SEC mandatory stuff that comes along with everything. Probably breach of some customer contracts, breach of some supplier contracts.

They’ve already got the gamut, and they’re paying the ransom, which you can argue is the worst thing you can ever do. So, yeah, I agree with Andy.

[David Spark] All right. Andy, kudos to you. You got someone to agree with you.

[Laughter]

[Andy Ellis] 76 and 12.

[David Spark] Again, I want you to just randomly come up with numbers each time because…

[Andy Ellis] Oh, no, this is now my baseline. I’m going to increment from here.

[David Spark] Oh, are you?

[Laughter]

[David Spark] 76 and 12.

[Andy Ellis] 76 and 12. I should write that down.

[David Spark] Somewhere, so he knows what to do with it. I think it would be quite funny if you just completely change the numbers of each time and said it with such extreme confidence that people started believing you, as you completely change the numbers each time.

[Andy Ellis] See, but now we’ve telegraphed that we would do that, so I think I’m just going to have to stick with 76 and 12, and I’ll increment. Next week, it’ll be 77 and 12.

[David Spark] Look, there’s a way… By the way, if anyone wants to do this, you can actually go through our transcripts and figure this out.

[Martin Mazor] ChatGPT.

[David Spark] If anyone… Yeah, or ChatGPT might be able to figure it out.

[Andy Ellis] I would not trust ChatGPT’s answer. I’ll be…

[David Spark] I’m sorry, you may not trust ChatGPT. But you know what I trust less? You pulling those numbers out of your butt. [Laughs]

[Andy Ellis] Maybe. But if somebody wants to go and give me a credible number for what it has been for all of my shows, I will send them an autographed copy of my book.

[David Spark] Okay. There you go. All right. The challenge has been thrown.

How would you handle the situation?

23:29.656

[David Spark] How does release speed impact security? Now, it’s easy to think that more deliberate development naturally leads to more secure code, but Lea Kissner argued in a recent SC Media article, “While it’s sometimes counterintuitive, my experience has been the exact opposite. Quick releases are beneficial for shipping secure products.” Now, Lee argues that the ability to quickly and frequently ship code means teams will be able to issue critical security patches faster with less risk of breaking things, as opposed to teams that ship less often and then have to do so in a hurry during an emergency.

All right, it’s an interesting call here that Lee makes. I’m going to ask you, Martin, does that hold water in your eyes?

[Martin Mazor] I think it can. So, if you’re doing short sprints, you’re doing quick releases, there’s a couple assumptions you’re making, and I think this person is making as well. First, you’ve got a ton of automation built in. Automation you actually trust, by the way. Not just automation but automation you trust.

It’s proven out. You can feel comfortable with it as you’re using it. And secondly, these short sprints are small deployments, which are always good, right? If you know that world. So, short quality automation, yeah, I think you would actually have a better visibility and better manageable. First, it’s like a quarter release that just has everything under the sun.

You spend weeks and weeks testing. You’ve gone through multiple sprints to get there. Yeah, there’s probably more bugs in the short timeframe of quick releases.

[David Spark] That’s a really good point in that example, and my feeling is there could be a happy medium. But what do you think, Andy?

[Andy Ellis] So, I don’t think there’s a happy medium. I think there’s two different extremes if you want to have security and safety. There is one which is make very few changes. Be very careful about them. Think about complex systems in the IOT world that can’t take updates on a regular basis. We don’t want to have people trying to push code to our cars like every 30 minutes to do sprints, so you better take the time to get the security right.

That’s going to take you longer to release. But that’s not the vast majority of software out there. Vast majority of software is online, needs to be able to take updates regularly, and release agility is the single most, I think, correlated factor to security. Like how quickly can you get from, “I need to make a change,” to, “The change exists in the world.” The longer that’s going to take, the less secure you’re likely to be because what’s going to happen is the organization is going to push back against marginal changes.

But if you come in and say, “Well, I think this is really bad…” If you’re saying, “Well, it’s going to take a quarter to release the thing that might only possibly be really bad,” everybody in the org is like, “Yeah, we’re not going to fix that right now. We’ve got a whole bunch of product features to drop in, and you don’t get to disrupt us.” But if like we’re releasing 15 times a day, and you’ve got a thing that, “Eh, this might be bad.

It might be good. We’re not really sure.” But it takes us 30 seconds to fix, nobody is pushing back on you. Release agility is what’s going to keep you sane. Now, it’s also going to keep you up at night because people are rolling out software that maybe they haven’t tested. So, if you want to have good release agility, you should have a really powerful test suite behind it.

[Martin Mazor] Yeah, I would add just, once again, that automation…you have to feel comfortable that the automation…your security testing automation, your verification automation processes are there. And if they’re not then nothing is going forward even longer term. I’d also say what I’ve done in my past, there are certain, “Thou shall never touch,” areas.

Now, if you’re making two week sprints, and you’re releasing, and you’re touching identity, you’re touching core infrastructure, those are going to go through other scrutinies, so it’s not a, “Everything has to be equal,” kind of approach. Right? The core tenets needs to be tested a little differently as well.

Hey, you’re a CISO. What’s your take on this?

27:15.661

[David Spark] We’re seeing more cyber security professionals looking to transition from IT into OT. Ryan Virani on LinkedIn had a few suggestions how to start making that transition. This included things like deep dive into OT fundamentals like SCADA, PLCs, and DCS, pursuing certifications like GICSP, and volunteering to get hands on experience.

And, by the way, if you don’t know what all those acronyms are, guess what? It has to do with OT. What else in an IT background could apply in the OT world? I’ll ask you, Andy. And which of these do you think is most important for someone looking to make this transition?

[Andy Ellis] So, I think if you’re going to make the transition, it’s actually a natural one to make, especially if you’re old school IT. Right? Companies are going to cloud native, and you can say, “Look, all of my IT skills are actually very likely to shift over into the OT space.” Like, “Oh, look, we have these machines that don’t get patched very often.” It sounds like the old school Windows world.

People weren’t patching for a very long period. “Okay, now you’re just doing that to your room controllers or other things.” I adjust a little bit. But in one sense, shifting from IT to OT is probably about the same jump as shifting from IT to cloud based IT. So, very reasonable that you want to make this transition.

Recognize that you are going backwards in time in terms of supportability. OT is like old school IT was. So, you’re not going to jump forward and use all the modern technologies should you go into the OT world. That said, everything is going to be OT. We’re going to see the convergence of OT back in at some point into IT because realistically we need to manage our buildings the same way we manage any other infrastructure.

[Martin Mazor] Yeah, I’d say some of the core fundamentals of even IT architecture or security architecture directly apply to the OT side. Working for a manufacturer, of course I’m quite intimately aware of the OT environment. Having the core capabilities of network security architecture, passive monitoring, integration to SOCs from an OT technology perspective, Andy is spot on.

The technology life cycle in many OT environments is 20 years. So, you’re still dealing with those legacy technologies. Those same modern risks impact those legacy technologies, so how are you going to segment it? How are you going to monitor it? How are you going to isolate it? How are you going to do micro segmentation?

How are you going to do basic end point protections? Because you’re never going to patch. How do you do virtual patching? All those things that maybe have gone…shifted to cloud based environments, those skills now relate back into the OT environment very directly.

[David Spark] What is something in OT…and both of you answer it…that is so not seen in traditional cyber security that it’s like would be a spanking new education for someone who has a very long and valuable history in cyber? Andy?

[Andy Ellis] So, I think two things. One is managing devices that you built but don’t own. And that’s the thing we don’t normally see in traditional IT. More and more companies are making big physical objects, selling them to someone, functionally it’s a long-term lease, and then administering them.

But you don’t control these objects. You don’t get to decide what’s happening to them, and that’s a very weird world. Like if you’ve been in the MSSP world or the MSP world, I think you are somewhat familiar with that. The other one is the volume of telemetry that comes off of these devices. I think that most people are not prepared for what real world telemetry looks like.

When people talk about big data, my experience is the IT world has no idea what big data really is.

[David Spark] I was… Just a quick tease to that. Years ago, I was interviewing the head IT guy for one of the NASCAR racing teams, and just from a day of practice with NASCAR, they’d get a terabyte of data. Just raw data. Which I found bizarre. How is it that they generate that much? But they could, just off a racecar.

[Andy Ellis] Because consider that the…every tire is continuously producing like a stream of data about like how much torque is on it, what temperature it’s at, what bump it’s feeling, everything continuously. And now put that to every piece of the car is continuously producing this stream of evidence about the world.

That’s a level of data that in the IT world we’ve never seen.

[Martin Mazor] Yeah, I’d echo the level of data that’s needed… We’re at a 4x difference between IT and OT ingestion…data ingestion sizing for monitoring purposes.

[David Spark] Wow.

[Martin Mazor] So, it is just tremendous… And it’s different protocols, so that’s part of that lesson learned, or how do you get into that kind of world is how do you learn what are the IT protocols versus the OT protocols. They are unique and different. They have different models, different requirements, different technologies to identify those.

But it is a 4x at least difference. It’s significant.

[Andy Ellis] Yeah, I’ve talked to companies that do telemetry ingest, and the whole big thing there is distributed compute. Like how do you shove down models to ingest the data closer to where it’s being generated so that you can digest and only send up what matters? And that’s a really hard problem.

[Martin Mazor] Yeah, a needle in a haystack challenge for sure.

[Andy Ellis] Yeah.

Closing

32:30.424

[David Spark] Excellent, gentlemen. That brings us to the tail end of this show. I want to thank our guest, Martin Mazor, who is the CISO over at onsemi. I’m going to let you have the very last work, but first I do want to mention our awesome sponsor, and that’s Material Security, secure your productivity suite.

Easy to find them. It’s just the word material spelled exactly the way it sounds. Not like one of those weird cyber companies that has two Qs and an L in it. No, it’s material.security. Although, there is an L in material, where it should be.

[Andy Ellis] But no Qs.

[David Spark] No Qs whatsoever. If you add a Q, you will not get to their site at all. Material.security. Secure your productivity suite. Check out what they’re doing over there. We greatly appreciate their sponsorship. Andy, as always, we greatly appreciate it. You have thrown down the gauntlet. Someone out there, figure out how many times people have agreed with Andy on the “What’s Worse” scenario.

You will get a signed copy of “1% Leadership,” a book that I have read and greatly appreciate. So, I think it’s a damn good book as well. Martin, any last words you’d like to say, and are you hiring?

[Martin Mazor] Yeah. No, thanks for having me. It was a great session. Andy, I haven’t read your book. If you want to ship one over, feel free. [Laughs]

[David Spark] Well, go find out how many people have agreed with him.

[Andy Ellis] Go find out how many. Otherwise, you know something? Buy copies for everyone on your team, and I’ll send you a signed one to go with it.

[Martin Mazor] Sounds like a plan, yeah. No, thanks again for having me. And yeah, I am hiring. Check out onsemi.com. Look me up on LinkedIn. Check out what we got going on. It’s great to be here.

[David Spark] Excellent. Well, thank you, everybody. Greatly appreciate your support of our work. Please send us more, “What’s Worse” scenarios, challenge Andy. Give him one that’s tough so people start disagreeing with him more.

[Andy Ellis] I mean, here’s my thing… Because we recorded one recently that was really challenging. The tricky is don’t just tweak one thing because those are the easiest ones for us to be like, “Oh, you thought that was going to be hard. That was actually easy.” Like make things that are nearby each other but that are sufficiently different that you’re like, “Huh, I have to compare an apple and an orange and decide which one is worse.”

[David Spark] Well, no, I like it when they’re truly apples and oranges. Like one bad thing, and then the other thing that wasn’t even somewhat related to the other bad thing. Then you have to sort of weigh what bad scenario does this put me in or not.

[Andy Ellis] Right. But if you give me a rotten apple and a rotten apple with a worm in it, I might argue that I’d rather have the rotten apple with the worm because now I can go fishing with the worm. But like that’s kind of where many of these end up for us.

[David Spark] Excellent. Thank you, audience. We greatly appreciate your contributions and listening to the CISO Series Podcast.


[Voiceover] That wraps up another episode. If you haven’t subscribed to the podcast, please do. We have lots more shows on our website, ciso-dev.davidspark.dcgws.com. Please join us on Fridays for our live shows – Super Cyber Friday, our Virtual Meetup, and Cyber Security Headlines Week In Review. This show thrives on your input.

Go to the participate menu on our site for plenty of ways to get involved including recording a question or a comment for the show. If you’re interested in sponsoring the podcast, contact David Spark directly at david@ciso-dev.davidspark.dcgws.com. Thank you for listening to the CISO Series Podcast.