Transcript
Opening
**Mike Krass: **Welcome to What's the Problem, the podcast where we dive deep into the most pressing issues facing cyber and data security leaders today. Each episode, we're joined by a guest expert who will share their insights and their experiences on the challenges that they're currently facing or seen in the world of security. Whether you're a seasoned veteran or a new leader to the field, this podcast provides valuable info and some strategies to get your organization to the next level. So join us as we explore the ever-evolving landscape of cybersecurity and discover new ways to tackle problems that keep us up. This is What's The Problem. I am your host, Mike Krass. Let's get started.
Conversation
Mike Krass: Today we are joined by Lauren Malhoit. Lauren, say hello to everybody.
Lauren Malhoit: Hey, Mike. How's it going?
Mike Krass: It’s going great. So Lauren, same question to everybody when they come on the show. Can you tell our listeners why you are qualified to talk about security?
Lauren Malhoit: Oh, yeah. Every time you ask this, I think what a loaded question for people. But I'll go ahead and give some creds here. So I actually started in, like working support and moving my way as a network engineer, virtualization architect, etc. I did post sales for AVAR. Eventually, I worked for the largest networking companies, at least in the US. Of course, Cisco and Juniper. And now I lead growth and product marketing for a scale up DDI company, actually, headquartered in Iceland called Men and Mice.
Mike Krass: Not to be confused with the famous John Steinbeck novel for our listeners here in the US who obviously read that when they were in third grade.
Lauren Malhoit: That's right. That's right. We try not to harm any mice in the making of our product.
Mike Krass: Yeah, absolutely. Men and mice, men and mice, the order is correct on those two words…are critical, I should say on those two words. So Lauren, you know, we were talking, and we had this discussion earlier about a single pane of glass and how it's likely not going to be the setup that's gonna set you up for success from a security standpoint. And you were telling me a little bit about this thing called overlay architecture, and how that gives you some visibility around some of the more complex IT environments. So let's start there. Why is a single pane of glass not going to take you where you want to go from a security standpoint? And what the heck is this overlay architecture that you're talking about?
Lauren Malhoit: Let me make a few clarifications here. Wire networks are so complex. And we've been talking about digital transformation for probably a decade. We see this in all of the industries. We not only talk about new architectures like multicloud and sassy, but we're actually doing new streams of revenue from IT. Offering things that people have seen: curbside checkout, self checkout without having to go through a cashier. In the manufacturing world, location like indoor location services. Being able to quickly find whatever widget it is, and quickly ship that out to the customer. They’re competing with the likes of Amazon to do this. And IT is actually expected to deliver all of these things on top of what they already do. And to do that, right, they have to introduce these new architectures, these new multi cloud architectures. Sprinkle in a little hybrid working, right, because now we have several remote employees, people demanding to be remote. And how do we secure all of this right? How do we get visibility into all of this, which I think is probably the first step towards securing all of this. Now, when you say a single pane of glass, I am dubious that that exists. I think that you can't use one solution to provide everything that you need within an environment. But what you can do is use what I'm proposing here in this overlay architecture. And what an overlay does, it's not new. We hear it when we say SDN (Software Defined Networking), or SD-WAN. When we say all these things, we're just talking about overlays. We're talking about software that abstracts the capabilities of underlying services. And whether those services are hardware or software or a combination of all of the above. An overlay architecture then kind of takes the capabilities from everything underneath it, right? If we're talking about software defined networking, we're talking about the capabilities of the routers and switches underneath it, as well as the security groupings, right. However that's done. The company I work for, we do DNS, DHCP, and IP address management. And by giving people the ability to use the services that they want to use, right. So if they want to be in public cloud, if they want to use things on premises, if they want to do a combination of all of the above. Having an overlay solution that allows them to hook into all of those things is going to be kind of the only way to move forward for these modern architectures. And for securing and automating these modern architectures.
Mike Krass: Yeah, let me try and run an example by you and I want you to correct me or tell me that I got it perfect just for our listeners. So, you know, splitting up this overlay architecture into two words. So an overlay…When I think of a common overlay that hits my email inbox, it's my friends that use that Superhuman app, right? So they merge all of their email inboxes together into a single inbox. They are looking at it in just one view, right? They don't have to go look at five different email accounts on Apple Mail, and Outlook, and this and that. Like all these different mail clients. They just get everything together. So is Superhuman, a good example of just an overlay on its own?
Lauren Malhoit: You know, I do think that's a really good example, right? And if you had to go to each individual mailbox, probably, one would fall off. Maybe you don't see that. Not much mail comes there. It's spam. And so you don't really worry about it. And then all of a sudden, that just falls off your daily chores. You're not looking at it every day. Maybe once in a while you think to look at it. But with this kind of Superhuman, with this overlay, then you don't forget. You can see everything. You can set everything up consistently. If you have email rules, I assume you can apply those policies across the board. All of that good stuff. So I think that's an excellent example, Mike.
Mike Krass: Got it. And sticking with our Superhuman example, which… If anyone from that company is listening to this, they're probably going to call in and be like you got all these things wrong. Let me tell you how.
Lauren Malhoit: Or a sponsorship opportunity.
Mike Krass: Yeah. Feedback is a gift. So all of our Superhuman employee listeners, please respond to this. So that's an overly architecture. Just using email as an example, the Superhuman example is what is the architecture? I'm going to assume that there's probably a lot of cloud email services there, like a Gmail, powering at least a few of those inboxes. So now, now you're talking about even though I live in New Orleans, and my friend lives in Reykjavik, in Iceland, when I send them an email, it doesn't go directly to Iceland, right? It's gonna stop somewhere along the way. So now we're getting into some of those other pieces of architecture that actually, when I push the Go button, on an email response, or when I receive an email, it's kind of bounced around a few different places on Earth. And hits both hardware as well as software and other mechanisms to get into my fingertips on my phone. Is that…do you think that I'm still following along with this pretty well?
Lauren Malhoit: Yeah, I think so. Um, you know, whenever we're talking about anything involving networking, which of course email does, right? It is going to bounce around, hopefully not bounce around too much, right? Performance is something that we're concerned about. We call that pinning, and we want to avoid that. Especially if we're doing things like daily stock trading and all of that. But yeah, it means in some cases, where an email is sent maybe that it doesn't need to be sent the next second. It's gonna bounce around. I think the important part is that with an abstraction layer, we kind of…Of course, we care how things are architected. We care that the system is set up, such that things like human error, and performance issues, and conflicts are avoided. But the the way we can do that more easily, then, rather than having to let's say, login to every single router, or in your example, log into every SMTP server or, you know, email server along the way, then we just go to one place, this centralized abstraction layer or this overlay. And we can see all of that, and then we can make design decisions for our entire system based on having full picture visibility. Even though again, we're using kind of disparate services, disparate hardware all over the world maybe in some cases, we still get that. And then of course, we also get things like access management control in a centralized fashion too. Policies in general. If maybe if we stick to assign policies in general, regardless of the vendor of the underlying hardware or software.
Mike Krass: Yeah. Let's talk about the audience here. Maybe who's listening to this? Let's say the audience is working in a smaller business, a midsize business, and an enterprise. Who is the audience where their ears should be perking up right now in those three environments?
Lauren Malhoit: I mean, honestly, I think probably everyone, to some extent, could be interested. But if I were going to pick, it's probably going to be the mid market and enterprise folks that have already gotten into the overlay game. We talked a little bit about software defined networking, about SD-WAN, all of this kind of uses that overlay idea, this abstraction idea. But depending on who the SMB is, I don't want to take them out of the equation either. Because maybe they're just running a couple of different sites, but they don't have the time to kind of learn both AWS services as well as their Microsoft on premises services. But I think probably the general target would be mid market.
Mike Krass: And what's your…Just so I know, what's your definition of mid market? Like what kind of size businesses?
Lauren Malhoit: Yeah, it's so weird to, to kind of put descriptions on this, right? Because I kind of ride the marketing and engineering side. So from one perspective, I would say 1000-50,000 IPs. But no one talks about those terms. And how do you even know how many IPs people have unless you have that kind of visibility? So from a people perspective, which is what we usually talk about. When we're talking about who the audience is, I would probably say the standard is 1000 to 5,000- 10,000 people in an organization.
Mike Krass: Got it. So we're talking about an organization of, you know, 1000 people up to five or 10,000 people. That probably puts us in the universe of talking to a title or a role like a network engineer. What happens when we're talking about not adopting an overlay architecture? What happens if that network engineer just decides this is not important? This is not something that they want to invest time and energy into. Or maybe some of their other vendors are providing something that gets them most of the way there. So they kind of just check the box. So what happens when nobody makes a decision to look at this in their organization?
Lauren Malhoit: Sure. So I think one thing that happens is, you know, a lot of these kinds of closed, proprietary hardware vendors are striving for vendor lock in. Generally, they have the largest market share, because this is how we've done it for the last few decades. Here's some hardware, here's some great margins for my sales folks. And by the way, you can't work with anyone else, because we have a closed proprietary system. And you know, I don't care if maybe the public cloud is the best thing for you. Or I don't care if this other service is the best thing for what you're doing today, even though it wasn’t maybe five years ago. But you're going to stick with us because we just can't work with other people. That's our business model. And it's also our technology model.
Mike Krass: That’s the classic Cisco model.
Lauren Malhoit: I wasn't gonna call out anyone, Mike.
Mike Krass: It's okay, I can be the jerk here.
Lauren Malhoit: But it very much leaves…Going back to where does it leave the vendor? But where does it leave the network engineer? It leaves them with technical debt. That’s the name for it. Trying to make a solution that they chose five years ago work with what they're trying to achieve today, which is things like curbside checkout, and putting smart devices at the meter for a utility company and like offering energy saving services to their customers. We're in an experience economy, where so much is expected of IT, and making them kind of use legacy solutions and legacy architectures to try and achieve it.
Mike Krass: Yeah, the utility meter reader is a great example. I remember a few years ago, when I used to see those trucks driving down our street really slow. Sometimes they'd stop at a house and then they kind of keep puttering along. And you could basically do that job in a golf cart, because you're not moving that quick. But that's a good example of something that didn't used to exist. Like it wasn't possible. They had to physically come and read your meter. That's why they call them meter readers.
Lauren Malhoit: Right. And they didn't care. It’s a utility. You just had to buy it. And that's where you were. But now utilities have to offer the same sort of customer experience. Like it was freezing cold a few months ago here. Even though it's 70 degrees today, a few weeks ago it was negative. And I'm getting emails from my ISP, from my electric company, from the gas company. They’re like have your kits ready to stay warm in case something bad happens. Like they care, basically. And that is this experience economy that we're all in right now.
Mike Krass: We've talked about not making a decision. So our brave network engineer has chosen not to make a decision. Great. That question I just asked you is more in the framing, or in the context, of the whole business. And I'd like to re-ask the question, but ask it about them. So what happens? I Mike, I'm just gonna pretend I'm a network engineer. What happens to me if I don't make a decision, or I make the wrong decision? Let's say that I've taken the first step. I've decided, but it wasn't the right decision. Like what happens to me personally?
Lauren Malhoit: Yeah. Every person in IT, the network engineer especially, knows that redundancy is key to everything. When we're talking about disparate systems, though…We're talking about what we're using in AWS or in Azure, what we're using on premises is setting up redundancy for all of those sites. I'm being very vague here but it's security policies, it's your router configuration, your switch configuration, your firewall configuration, your access policies. I mean, just everything under the sun that could… that is required of making packets move through your network and allowing your co workers to work. It's really hard to set up redundancy and replication. Design a system that is going to be redundant, that is not only going to be up, but is going to be performing in the way that people expect as well. And so if we stay with the status quo, then it's very possible that we lose track of things, that we are not setting ourselves up for success in the way that we've designed and built in redundancy, and therefore, the worst can happen. So, for example, if I were to think about DNS, which I always am every day thinking about DNS.
Mike Krass: Of course.
Lauren Malhoit: DNS is something no one thinks about, besides me. Or besides a DNS vendor. But sometimes it's only 5% of someone's job. They have to make sure that new services, new whatever gets DNS names, or maybe a new server on the network gets a DNS name. And then they go on to something else. But the thing is, if DNS goes down, especially your external DNS. If your website goes down, the least of the problem is that you lose trust with potential customers. That they're like, well, I didn't get to your site. And so they just go on to your competitor. At worst, we're seeing numbers like three and a half million dollars an hour in losses if you're like an e-commerce site. Top e-commerce site, I should specify. So there is a true business loss when we don't design systems correctly. And we're talking about things like denial of service attacks, which are just on the rise. But we're also talking about human error. For designing systems that can be shut down because an intern did something wrong, then we're designing them incorrectly. And if we don't have a full picture view, we're never going to be able to design these systems with redundancy built in. Then digging deeper, what does this actually do to the network engineer? Well, if it's something that they have control over…On premises, let's say. That could be a resume generating event for them. Something goes down, their company is losing 1000s or millions of dollars an hour. They could lose their job, potentially. Now, if it happens, let's say, in the cloud, or an external managed service provider. Obviously, they don't have control over that. They can't be punished for that site going down, right? Facebook went down, because of a BGP issue. Dine went down, because of some other human error routing issue. People can't be… If people don't have control over it, then they can't really do much. However, what they could do is build a system that had redundancy built in. And therefore it is kind of on the network engineer to build these systems such that it can withstand this kind of outage or issue. And so you know, I think, the status quo…As we go deeper and deeper into technical debt, we can blame it on the budget, we can blame it on, you know, all sorts of things. But at the end of the day, it's up to the network architect or network engineer to design these systems and hopefully, kind of get that value proposition across to the folks who are in control of the budget.
Mike Krass: Last question before we close this episode out. I've spent the past few questions…I wouldn't say I'm saying unkind things about our network engineer friends, but I've been painting some not fun scenarios. I just would like to remind our listeners, we are a team here. And so I'd like to ask this last question of you, Lauren. How can we support the network engineer? How can we act, whether it's resources, a specific role or function of the organization empowering him or her? Let's end on a high note here. How can we support that individual?
Lauren Malhoit: I love that question Mike. Ended on an optimistic note. I talked about being in technical debt. And part of technical debt is not just the budgetary problem. Not just not being able to buy a new solution or implement the new solution. It's also the training that comes along with a new service that might be more appropriate for what you're trying to do now or what you're trying to do in the future. Now, we all know training is great and offering support and budgetary resources to send your folks to training is always a good thing for new services. But also they don't have time to do it because they are busy trying to make these legacy systems work with modern architectures or with the demands on the increase from digital transformation and the rise of the experience economy. Making sure that you're listening to your network engineer, right. And I'm speaking, I guess, to like the director level and above. Listening to your network engineer on what they think are the best solutions moving forward, what they think will be sustainable for several years to come as well as sustainable to migrate to. Everything. When we talk about digital transformation, everything is a migration project. And migration is risky and painful. No one likes to do migration. But when we can kind of move to these overlay architectures, we see that migration is much easier, if we can embrace these open systems that allow us to kind of use the best of breed services. Or maybe not even best of breed. But best for our use case’s scenarios. And if we did that, is that enough? We can always do more for our network engineers. I have the utmost respect for what they do. I didn't last myself.
Mike Krass: It's absolutely a good start. And I, in particular, like how you pointed out training…and I just wrote a note here down on my notepad…when able. Because oftentimes, the job does not stop just because you are in a training environment. Whether you physically go there or are just remoting into it. That's a big asterisk of like training, asterisk, when able. And it's not money or budget that's usually the issue. It's the issue of how do we fit this into your schedule to keep you up to date on things that you should be knowing?
Lauren Malhoit: And you know what that is? That's a lack of resources. A lack of human resources on the team. And we're expecting more and more while not hiring more and more people. So I would say that's my last piece of advice, I guess, for folks running IT teams. It's hard to expect more with less people doing it.
Mike Krass: Yeah, absolutely. Well, Lauren, we so appreciate you joining us.
Conversation
Mike Krass: To our listeners, that is a wrap for this episode of What's The Problem. We hope you found our conversation with Lauren Malhoit, here, to be insightful, to be informative. Hopefully you can take that last segment, the last few minutes, and share that with your director. We need to staff up. We've got a couple of empty holes here in the team. We could really use some people here. So you can use that and arm yourself. Remember, tune in next time for more discussions on the latest challenges and discussions in cybersecurity. Also, I wanted to give a quick shout out to our host MKG Marketing. MKG is focused on helping cybersecurity companies get found, drive leads, and close some deals. So if your cybersecurity business is struggling to generate leads or close deals, let us help you. To learn more, you can visit our website at mkgmarketinginc.com. Thanks again for listening and don't forget to subscribe and mash a rating, hopefully a five star, for the podcast. We appreciate your support. Until next time, my friends.
Lauren Malhoit
Lauren Malhoit is the Head of Growth and Product Marketing at Men&Mice
