Jason Pufahl 01:05
Yeah, that way it’s fair. And what we want to cover a little bit is, I think that sort of age old struggle between, say infrastructure, and you know, sort of keeping things running and maybe implementing new technologies versus maybe that approach that security brings sometimes which is, you know, inspection and, you know, maybe to some degree, you know, prevention of activities.
Steven Maresca 01:30
You mean, just saying, no?
Jason Pufahl 01:32
Just saying no, because everyone knows, a good security person just says no to everything, right, that’s effective security controls. But it is a serious topic, right. And it is one that we run across pretty regularly, which is simply probably working with a company that has a lot more infrastructure folks, maybe not a complete security mindset, but you know, maybe business ownership or regulatory requirements, whatever, require some implementation of security. And so how do you get both sides to work together effectively? Because I think that is honestly a challenge, right? And I think traditionally has always been difficult to do. So I think I’m gonna just toss it over the fence, right to the bad guys, to the infrastructure guys. You know, where is that challenge? I’m sure you’ve been faced with this a lot of times, rolling out projects. Where do you think that friction starts?
Matt Fusaro 02:27
Yeah. And Lou, I think you probably have one of the hardest jobs here, right? Because you’re kind of in charge of our client success. So when people have problems that kind of go right to the Lou Ardolino, right.
Lou Ardolino 02:42
Yeah, that’s correct. And you know, when you talk about the challenges of keeping your customers secure, a lot of times, you know, when you’re in an engagement and you’re contractually obligated to support an environment, you’re kind of in a reactive phase, as far as you know, support services, right. So of course, you’re performing all your patching and your maintenance as well as you can. But unless you have change control implemented from a support standpoint, you can really, you could really hold yourself liable to making some serious mistakes, not documenting what you’ve done, not getting approval for what you’ve done. And that’s just from like the day to day support perspective. The customer wants it done as fast as possible. SLA’s be damned. Priority matrixes be damned. Just get it done. And your engineering team wants to deliver as quickly and as efficiently that they think as possible. And that’s where you kind of get stuck, when it comes from a project perspective, when you’re implementing a widget or you know, you’re doing a network forklift. You stick to the scope of work as best you can, but I think, you know, I think if we took a scope of work from the professional services side, let’s say the infrastructure side, and we ran it, we handed it to Steve Maresca and said, hey, here’s our scope of work for this server firewall switch deployment. We need to get this done in three weeks. What do you think, it would take us about six months to get it gone by the time deadlining everything in that SOW. And that’s where the problem lies because he’s not wrong, right? He’s not wrong. And neither is the the project implementation team. They want to get it done as professionally, as efficiently as possible, but unless you’re really interjecting a security flavor into your scopes of work and into your day to day help desk support of your customers, you can really tie things up from from a delivery perspective, and you could also get yourself tied up from a liability perspective as a company.
Steven Maresca 05:26
You know, I think part of that is simply a reflection of the customer priority, right, you have, their revenue is directly tied, your business success is directly tied to how rapidly something gets rolled out. So, you know, from an infrastructure deployment, whether that’s a internal infrastructure team rolling out a new app, or an MSP doing that on behalf, it’s not necessarily keeping in mind the choke points, or monitoring or secondary things needed to deliver security. And it’s not an afterthought, per se. It’s just responsive to the need to get something out the door to meet a, you know, quarterly deadline or something like that for revenue, right. I think that’s the underlying cause.
Lou Ardolino 06:15
Yeah, I agree. I mean, look at it from even the most basic level of security from a year ago, like, we were trying to sell multi-factor authentication to customers, and they would just roll their eyes because they didn’t want their employees to have to take that extra step to put in a code. Now, their cyber liability insurance policy demands it. And we’re doing it for them now, with, you know, no questions asked, but, you know, that cycle takes a while for you know, because immediately they go, they, you know, they go to the they go to the lowest common denominator, and they think about what’s going to cause them the most pain, not what’s gonna, you know, prevent them from a security incident.
Jason Pufahl 07:03
So, I mean, how much of it really is a client, in a way infrastructure is sort of the here and now, right? It is, you’re implementing a new tool, a new program, whatever the case might be, and maybe end users are clamoring for it, security tends to be a little bit more sort of future-focused in the sense that you’re reducing risk for some indeterminate future state, right. So it’s a lot harder sell and it’s also frankly, a lot less attractive. And in many ways, right, your more traditional IT people, they’re judged on stability, and what have you delivered for me lately, and security doesn’t really bring that.
Steven Maresca 07:45
Yeah, security is more anticipatory of potential risk, which is restating what you said, but it’s, in essence, the main issue here.
Jason Pufahl 07:54
Right, and yeah, and it’s hard to look to look ahead, right. In a way, it’s insurance, right? A lot of people defer insurance, because, well, I could take my 200 bucks a month and spend that on something a lot more fun. So and that’s kind of the business we’re in, in some ways.
Matt Fusaro 08:09
And a lot of times, you know, back when I was doing infrastructure, I always have these internal arguments with my peers too, right? I would always be a lot more security focused, and they would be more, we need to get this done, right. And, you know, I always saw both sides. And quite honestly, I pared back sometimes, you know, what I was expecting out of a secure deployment or something. Yeah, it’s always a struggle, because when you’re doing infrastructure, you have to get it done quick, right? You can’t wait for a security review to be done, or you feel like you can’t wait, you feel like you can’t wait. You always feel like you’re kind of just sitting there on your hands if you’re not doing something all the time. And, you know, a lot of times, that’s what either what’s expected from them. Or if you’re a service provider, you’re expected to be doing work all the time. And when you’re told, hey, stop, I need the security team do something you feel impeded.
Steven Maresca 09:06
Right, speaking from like the customer’s perspective, they’ve greenlit the product, or the widget, or the service. They’ve gone through procurement. They’ve done through the contracting already. They’ve not thought of the vendor risk oriented, the data risk, and they have already passed to the point of saying, here’s our financial outlay. They don’t want to go backwards, and it feels like they’re going backwards if any securities inject late in the process.
Jason Pufahl 09:37
So I think, right, what I wanted to make sure that we covered was, how do you rectify this issue? And I think, Steve, you jokingly said at the beginning, right. Security is taking the position of no. And I think there’s two solutions to this. One clearly is and obviously we don’t believe that security is taking the position of no, but an effective security practitioner understands balance, to your point Matt, which is coming into it and recognizing there’s business needs to get a certain product out. And if you want to make that project as secure as you can, in frankly, the time constraints that you have, or sort of that meet the business needs. And it’s unlikely that you’ll be able to go and implement every security control that you want, or be in the position where you lock it down fully, right, because it just won’t work, right. And then I think the other is, the infrastructure folks do need to bring in security earlier in the process. And I think if you’ve got a team that does show balance, a security example shows balance, there’s going to be an increased willingness to do that.
Steven Maresca 10:41
Especially because risk can be accordingly balanced with effort, because it might be something that can be deferred, rather than baked into an infrastructure rollout. It’s just a matter of knowing, hey, here are some potential risks. We’ve documented them, we’ll return to them next quarter. That’s sufficient in many cases, but that thought behind it is not often practiced.
Lou Ardolino 11:07
Yeah, I agree with you there. Some of our best infrastructure projects have come from customers that have had vulnerability assessments, and they realize the risk that they have, and they’re willing to, you know, take those extra steps to make sure that the deployment is secure as well.
Matt Fusaro 11:33
Yeah, a lot of it just comes down to communication, right? I mean, communicating that, you know, timelines might change, because some security process has to be done for it to work properly, or infrastructure, just communicating, hey, you know, here’s when I have to have this done by, right. If everyone’s talking to each other, and feel that they can put forward their procedures for that to happen, then it’s usually successful. It’s when you feel like you have to hold back where you’re stepping on eggshells to do anything, that’s when it becomes a really tenuous situation.
Lou Ardolino 12:07
Yeah, you establish the customer expectations from the beginning. And you keep touching base with those touch points throughout the project implementation. So the key is, you know, like you say, communication right from the get go.
Matt Fusaro 12:22
Steven Maresca 12:24
I’m fond of talking about the fact that it’s very possible to deploy something that has a security flaw, if it’s business critical. It’s just that you have to have that conversation, to ensure everybody’s aware of it, as long as that’s happened, there’s really no barrier to moving forward. It’s not a technical issue at that point, it’s just an organizational decision to behave in that way.
Matt Fusaro 12:51
The other aspect that gets in the way sometimes is the “Ooh, shiny thing” that both teams have a problem with, right? Something cool will come out in security, and everybody wants to implement it. And the same thing happens in infrastructure where, oh, you know, this new feature solves world hunger, I need this. And both of them have problems, right? The shiny security thing might cause serious usability problems, the shiny infrastructure thing might be a complete security hole that nobody ever should have implemented, right, and balancing those two is always a problem. We had, internally, we had those struggles when we decided on our RMM.
Lou Ardolino 13:33
Yeah, I was gonna just bring that up. Internal projects alone have caused confusion and delay.
Matt Fusaro 13:41
Yeah, and these are things that every organization is gonna have to deal with. And we deal with them internally, too, we always have that struggle, I think we have gotten very good with it over the past year and a half or so. Because we’ve integrated the two pieces of the company so well, and we talk regularly, again, communication really saved the day with a lot of that stuff.
Jason Pufahl 14:03
I couldn’t agree more, it really is no more complicated. I think, you know, communicating, but coming from a from a position of trust, sort of mutual trust, you know, if you can do that, and recognize that, you know, there might not be that perfect solution in either direction, you just find your best balance. I mean, it doesn’t have to be that hard. But it does really come down to communication. I think nothing’s worse than when two groups work in isolation. And then just assume the other one has some mal intent somewhere which we see all the time, right? Well, I feel like we just solved something that I’ve struggled with for a lot of years on exactly how to address all of this. So I’m pretty satisfied with this.
Matt Fusaro 14:43
Yeah, a lot of it is just getting some chemistry with people, you know, putting them in the same rooms more often and getting them to talk more often, being part of a project process from the beginning. It helps a lot. I think that’s avoided a lot of times, we have separate departments, right? We’re not integrated into infrastructure most of the time, we’re not integrated into security, on the other side. Seeing more of that would probably help, and again, making sure that people are part of the process from the get go is helpful.
Jason Pufahl 15:13
Lou, anything you want to add in closing?
Lou Ardolino 15:14
No, that would make my job a lot easier, that’s for sure.
Jason Pufahl 15:20
Well, I think if we can make Lou’s job easier,
Matt Fusaro 15:23
I mean, that’s, that’s the reason we all live. We want to make Lou’s job easier.
Jason Pufahl 15:24
I mean, that’s why we’re here. We figured this out, let’s make Lou’s job easier. So, alright, I mean, I think on that note, right, the takeaway is, if you’re in this IT space, maybe doing some security, really trying to open up those lines of communication. And I think, really, no tongue in cheek intended, don’t be on that side of no, definitely find that middle ground and be willing to compromise. I guess that’s just the nature of life. But, this existential podcast today,
Matt Fusaro 15:59
I think you’ll find that a lot of there’s actually a lot of similarities. Some of the best security people are good infrastructure engineers. So I think both teams have a lot to offer each other and they should talk more.
Jason Pufahl 16:13
Well, as always, you know, if you want to talk about your challenges getting a security project done, or maybe vice versa, right, where you feel that security is being an impediment, you let us know, I think actually, one of the things that we do bring to the table that is really effective is sort of our ability to, to find that common ground or that middle ground and be reasonable arbiters. So do feel free to reach out to us on LinkedIn, Twitter. We’re happy to bring in Lou to a follow up conversation, this skilled people-person. And we will, we’ll continue our conversation from there. But as always, we hope people got value out of this. We appreciate you listening. Steve, Matt, Lou, thanks for joining today.
Lou Ardolino 16:52
Stay vigilant, stay resilient. This has been CyberSound.