B2B Tech Talk with Ingram Micro
B2B Tech Talk with Ingram Micro

Episode · 2 months ago

Listening to understand and building collaboration-based cultures with Dave Sirrine


If you want to save time, energy and resources, don’t wait until the final hours to bring in your security team. Bring them in early and bring them in often. 

Your security team is more than the “no” squad—they have more to offer and are a critical part of any project development. Create an environment of genuine collaboration and unlock the full potential of DevSecOps.  

Shelby Skrhak speaks with Dave Sirrine, principal solutions architect at Red Hat, about: 

- Getting to “yes” by engaging security early and often

- Recognizing the humanity of IT professionals

- The importance of culture and building relationships 

To join the discussion, follow us on Twitter @IngramTechSol #B2BTechTalk 

Listen to this episode and more like it by subscribing to B2B Tech Talk on Spotify,Apple Podcasts or Stitcher. Or, tune in on our website.

You're listening to B two, B tech talk with Ingram Micro, the place to learn about new technology and technological advances before they become mainstream. This podcast is sponsored by Ingram Micro's imagine next. It's not about the destination, it's about going someplace you never thought possible. Go to imagine next, DOT INGRAM MICRO DOT com to find out more. Let's get into it. Welcome to B two, B tech talk with Ingram micro. I'm your host, Shelby Skirt Hawk, and our guest today is Dave Serene, principal solutions architect at Red Hat. Dave, welcome, thank you for having me. Excellent. Well, today we are talking about creating a yes mentality of devops with red hat. But let's start with some definitions then. So our audience knows devops. So then what is Dev Sec ops? Yeah, so, you know, people understand devops as the combination of development side of the House and operations side of the House. What DEAV SEC OPS seeks to do is build in a foundation of security, right, you know, across your devops practice, you know. So, in order to ensure there's security built into the development process and security built into the platform, into the life cycle of the environment. Right, you know, it's it's security first instead of bothed on and that that makes a lot of sense. That looking at security. I mean when we look at a Dev Sec ops department, practice, whatever you wanna call it, does Dev sec ops have a maybe a rigid definition from from Gardner, for example, or do you find it's it's more fluid from company to company? And I guess if it is more fluid, does that create a challenge if devops is operating very differently than other departments and other companies? Would sure, yeah, deaf SEC options does have a pretty standard definition. I believe Gardner does have a standard definition what deaf psych ops actually means. But you know, when the rubber meets the road, everybody's going to be implementing it in a different way. Right. You know, Deaf Sec ops is going to be implemented in a way that fits in existing companies culture and existing companies processes and policies. So it's it's gonna vary widely, you know, across the board, but it's going to have a pretty standard foundation to do it. Well, you know, I asked that because, you know, in looking at the importance of Dev sec ops. Yeah, of course, that that can be understated, the importance of security. But I understand that, Dave, you give a presentation about Dev yes ops, getting to yes by engaging security early and often. So when you say getting to yes, what are you referring to? Yeah, so oftentimes it's in my experience, security is brought in late in the process, right. You know,...

...a project has been worked on for, you know, weeks, if not months, if not longer, right, and when the project gets to a point where it's ready to go into production and ready to start getting, you know, tested at scale, you know, that's when security gets brought in and said, hey, here's this thing that we're going to deploy, we need you to approve this. And as technology becomes vastly more complicated, with a lot more moving parts, a lot more interconnections, it becomes harder for security teams to just kind of rubber stand those things. Right. So what do I mean by getting to guest early? Well, bring in the security team early, right, you know, start developing those relationships, start developing those reputations with the security team to get them involved in the project from the ground floor. Right. Because you know, while I talk about getting to yes early, sometimes getting to know is just as, if not more, important, because we're trying to accomplish things very quickly, right, we're trying to deliver new capabilities to market, we're trying to, you know, improve our customers experience with our products, right, and we don't want to waste time by working on a project for weeks, months or longer just to have security say that's a hard no. Right. So, you know, we need to be able to start encouraging these relationships earlier on in the process get security involved. You mentioned the rubber stamp and I think often, especially now in this zero trust era, it may feel like, you know, it's the security team kind of has just a rubber stamp of no. How do you combat that? I mean, if there's already that mentality that, well, you know, as soon as we bring in security, they're gonna they're gonna poke holes so everything and raise challenges that, if you're the project manager, if you're trying to get this off the ground, yeah, those are the those are the minutia in your mind that you're like, I don't want to deal with it. So I guess how do you overcome that? Yeah, well, I mean first it's understanding that your security team is there, are people to write and I think that's that's something that's in that that may sound Glib right, but I think that's something that gets missed sometimes where, you know, security develops this reputation of being, you know, the folks who wield the no hammer, right. You know, they come in and they're like actlutely not, you know, we're gonna put the brakes on, we're gonna slow you down. You know, we're gonna slow innovation. I know enough security people to know that they don't want to do that right. You know, they want to be able to help you deliver new capabilities faster, but they need to do it in a way that is risk tolerant. They need to be able to reduce the risk to the business while helping you get done what you need to get done. And if you think about security, security is all encompassing rights, this giant umbrella that covers the entire business...

...right, not just information security. And so you know we're not just talk about security around networking and, you know, the actual applications themselves or you know anything like that. But they also have to be concerned about physical security. You know, People's security, you know, all of those types of things. They can't know everything about everything all at once. They depend on us, right, the folks who are actually doing the work to deliver these new capabilities and these new technologies for the business, to help educate them. And when you bring them in early into the process, it just gives them a much longer road to understand why you're doing what you're doing right and it gives them more opportunity two then turn around and explain to you why certain, you know, configuration or deployment models or, you know, architectures may have higher risk to the business then others. Right, you know, so you can work through these differences throughout the entirety of the process, so that way you're not losing time by having this big back and forth late in the process. Can we talk about the fact that security and technology departments? They're people. I mean seriously, I cannot Um. I'm sure that every listener is going yes, you know, I have a name. I'm not. Hey, this is broken, Hey, I need this. In the food service industry you never hear about the good things. It's always Oh, you know, this was bad or this order was messed up or whatever. You know you rarely hear about the good thing. Same thing applies to, you know, the I t world, right. Same thing applies to technology, where when things just work, you cease to exist. When things are broken or you're slowing people down, you become Publican to me, number one. Right. Well, that kind of lead me to the so within this give, yes, ops talk that you give, you talked about, you know, there's three pieces of the puzzle. Then I mean technology, getting that right, that right technology in place. That's one piece of the puzzle. But the other surprising pieces, at least to me, were process and culture. I want to get to culture last because I think that's the most intriguing. But let's let's talk about process. I mean, you know, can you expand a little bit on we know that that processes everything, with companies, with you know, Well oiled machines. So can you expand a little bit on why is process the such a key factor in making sure that every piece is talking to each other and every piece is optimized? I guess sure. Yeah, so, you know, when we talk about process, process is one of those things that, you know, as with technology and as with our development into play methodologies, as we move more agile. Right. We...

...need to adjust our processes to follow suit. I've worked for a ton of organizations in the past where, you know, the processes have been in place for years, if not, you know, decade or more. We need to start building out processes that are flexible, right, that can grow with the business, that can grow with the requirements needed to, you know, continue to be relevant in today's market. Right. You know. And when when you look at kind of your standard devops or Dev sack ops, workflows or life cycles, right, you know there's gates at each one of those. You know there's gates all along that that flow. We need to start developing processes that can quickly address issues at each one of those gates. Right. And you know, this is where the people in the culture aspect really tie in, because you can't quickly address those process constraints if you don't have good working relationships with the key stakeholders for this application. Right. You know that that includes all the way up to senior management. You know, because you need to make sure that senior management understands, you know, why there's risk to this particular process the way it's done today and why it needs to be changed. You can't move quickly if you don't have good processes in place to adjust on the fly. Well, you know this, this culture of collaboration, making sure that there's open communication happening. You know that that's a two way street. So I wonder if if we can talk about why a collaborative culture is so helpful and important when it comes to building a security policy practice. You know, whatever, however, whatever scope that you're talking about, I mean we we already know that technology departments are stretched, then in secure. Pity is is definitely a problem that that keeps the corner office, the C suite up at night. So, with all of those things to to worry about, why worry about culture? Yeah, so you need to worry about culture because it's it's about speed right. You know, when you have disparate groups within your organization that don't talk right, that don't collaborate well together, you know that's really going to slow you down. And one of the key differentiators in today's market is how quickly you can get to market with what new you know. You know killer features that you need to deliver to your customers. One of the things that I often get pushback on when I talk about these things. It's like, well, you know, we're busy enough already. You know, how are we supposed to carve off time to build these relationships? It doesn't take let me, let me not say doesn't, right, you know, because what we don't deal in absolutes here. It shouldn't take a lot of effort to build these relationships, right, you...

...know, you don't have to have an official, standing weekly call that's an hour on the calendar and you have to drop whatever you're doing. It could be a five minute hey, you know. Can we just have a quick call? Just want to see, is there anything I can do to help you? Is there anything you know, especially from from us, from the devops side, the Dava sec outside, you know, the practitioners, the ones doing the work. You know, it oftentimes is incumbent on us to put our hand out right to the security team, to the networking team, and say hey, you know, we know you guys are busy. Is there anything I can do to help? Is there anything I can do to to, you know, help you understand something a little bit better? Is there something I can do to, you know, demystify some of this technology for you or whatever? Right, you know, it takes just a five minute, you know, email, right, just to say hey, just check it in, seeing how things how things going? Is there anything I can do? If you want to set up a regular cadence called great, but start small, right. You don't have to boil the ocean, just start small. Start with that, that phone call that says hey, I understand you guys are busy. Is there anything I can do to help, anything that you need for me that can make your life easier? Right, and those little gestures go a long way in helping build those build those trust relationships between the key stakeholders so when it comes time to bringing them into a project, they're like, oh, hey, I know this person, I know that they're going to do what they can do to help us do the right thing. So let's engage instead of saying, oh, they're going to try and hide everything from us because they don't want us to know, because you're trying to sneak something by us. You know, it's gonna take time, it's gonna take effort, right, but it's gonna be up to the individual and how much effort really needs to go into it. Can really start small with those little gestures of how can I help alleviate some of your pain, and I might even argue that you could go even smaller to make a long way. I mean, yes, I think the certainly the best practice would be, you know, doing those kind of regular check ins with departments and saying, you know, how can I help? But I think even smaller would be maybe just it sounds so trivial to say, but being friendly, being someone that's that's approachable. I mean my husband has worked in technology all his life and you know, standing next to somebody that is, you know, constantly no, is constantly annoyed, just constantly, know, basically just talking down to to whoever needs help. And then if, if he's the friendly one, yeah, it means that he's got more work because more people are coming to him. But I wonder if you could maybe just talk a little bit about the importance of that, because yes, in in the moment, the practitioners might think, okay, yes, mean, but that's...

...that's all well and good in theory, I should be doing this, but can you speak to the long term benefit that that doing this would have and how it can actually improve a company's depth set offs? Absolutely right, you know, and this is this is kind of the hidden benefit of of doing this kind of work. Right, you know, to your point, when you are earnestly open and honest and and you know you honestly care about that that other individual on the other end of the phone, there it really brings those walls down, right, and as those relationships start to develop and you really approach it from a place of I like to say you listen to understand. Right, this is one of those kind of stereotypical, you know, kind of issues you run into between the practitioner and the security team where it's you're listening and you're hearing no and you're like you're just trying to slow me down. Right, it becomes adversarial, right. But when you listen and you hear no and you ask, okay, explain that to me, talk to me a little bit more about why that's no. Right, once you start going down that road and you listen to understand and you listen to really try to comprehend the why, it becomes a lot easier. And once you start understanding why, you start going back to the security team the next project you have. You say hey, I understand that you guys have these constraints from the last conversation we had. Here's this project we're working on. We've already accounted for this, this and this. You know because I'm listening to you and I'm listening to what your requirements are. So we're trying to account for those ahead of time. Right. You want to talk about ingratiating yourself with the team when you go to them and say, Hey, I heard you last time when you said that these are these are some constraints. We're building that into our process going forward and we are accounting for that going forward. It makes a ton of difference. But the only way you can get there is listening to understand, right, listening to really understand why, why these constraints are these constraints and if you're listening for the why, if you're listening to understand, the other value here is there aren't many organizations that I've worked with that don't have some sort of exception process. Right. There aren't many rules that are hard and fast and set and stone. If you're listening to for the why and you're listening to understand and you understand and you can explain why what you need doesn't fit in that or why this may be an acceptable exception. It helps move things forward a lot more quickly instead of just saying, Oh, they're just trying to slow us down, we're not going to include and we're gonna do with what we want to and just hope it passed this inspection later. Right. Well, bring this kind of full circle then, I mean we've we've had a great conversation about theory and about kind of best practices and how to strengthen Dev setox and security just across the board.

How does then, red hat help partners, help Ingram micro partners with all of these challenges? I guess why? Is this conversation good to have with Red Hat? Absolutely, you know, professionals with red hat technology, with that whole that whole umbrella. Yeah, that's a great question, right. And one of the things I think sometimes people miss and would go a long way to understand is red hat works very closely with a whole variety of partners, you know, with the security tooling to build into your architecture, to build into your DEBV SEC ops pipeline, to build into your debt sec ops workflow. You know, if you're talking about building in automation right to your debt SEC ops process, your deb SEC ops pipeline. We partner with a ton of different vendors, you know, to help you do that. You know, think things like, you know, Arista and Palo Alto, for you know, your your networking needs. Think about folks like twist lock and Aqua Sac and and and those types of folks. We have a tremendous partner network that we work very closely with, two to help build seamless deployments for our customers, to help ease those burdens on both the practitioners and the security teams right and the reason why we do that is a lot of organizations they already have their their tool chain set right. They already have their tools in place and well, one of the things that I see is is, you know, a lot of the C suite folks I've talked to, they're trying to consolidate tooling. So, you know, if we can help you implement the tools you already have and put those into the into the pipeline, along with red hat technologies, see less lye it just makes the process a whole lot easier and makes that conversation a whole lot easier, you know, with the business and with the those folks who are responsible freshly to playing. Well, as we start to wrap up our episode, is ask our guests the same final question, and that's where do you see technology going in the next year? So broad by design. What do you see happening in the next year? Sure, yeah, over the next year, I mean, if I were to pull out my crystal ball, I would say that you're going to see a huge focus towards, you know, tooling that's going to help ease the path towards zero trusts, right, you know, with a number of executive orders that have been uh issued in the recent past. You know, the funny thing is, you know, people look at that and say, Oh, that's just you know, for federal government and federal you know systems integrators and partners. Well, it also often applies to folks who do business with the federal government, right. So you're going to see this...

...really start to spider out across you know, even even in the commercial sector. Yes, so I think. I think we're going to see a pretty heavy focus on things that are going to really drive towards a zero trust type model. And you know that's gonna be around you know, API driven development. It's gonna Focus real heavily on edge, edge computing, edge workloads right because you know, the edge is something that's been forgotten for so long and these requirements are really going to help you force us to focus on those things as well. So I think that's that's kind of the direction we're gonna see. We're gonna see a big push towards, you know, more cohesive automation and zero trust. Well, excellent, Dave. I appreciate the conversation and uh in the insight today. Thanks so much for joining me. Absolutely thank you for having me and thank you, listeners, for tuning in and subscribing to B two B tech talk with Ingram micro. If you like this episode or have a question, please join the discussion on twitter with the Hashtag B two B Tech Talk. Until next time, I'm Shelby Skat Hawk. You've been listening to B two B tech talk with Ingram micro. This episode was sponsored by Ingram Micro's imagine next. B Two B tech talk is a joint production with sweet fish media and Ingram micro. Ingram micro production handled by Laura Burton and Christine Fan. To not miss an episode, subscribe today on your favorite podcast platform.

In-Stream Audio Search


Search across all episodes within this podcast

Episodes (476)