Mike O’Malley, SenecaGlobal | DevOps Experience 2022

Hi, my name is Michael Malley. I'm the SVP of strategy for Seneca Global and I want to talk to you today about employees everywhere devsecops for distributed teams. Thanks for joining me.

What I want to talk about today is how the world has changed right? If you look at what's happening, you know with distributed workforces and coming out of covid, right? We've got more and more Independent Business units independent agile groups that work independently and maybe geographically very independent from each other.

They're all different developing different applications within a company. And so because of that we get much more growth but much more distributed Workforce. And as part of that they're really good reasons to do that.

First of all, you know with covid right? We saw more and more people weren't coming into the offices and we're then in distributed teams, right either physically distributed teams or virtually distributed teams. And the big reason to do that is growth right as you move into a smaller well-skilled team, you can get more things done right think of it as a group project versus doing something on your own you can get something on your own done very very quick.

It's probably not as thorough as what you're gonna get done as a group project, but it can be done quickly and you can think of decentralization very much in the same way right instead of big slow moving organizations organizations started to decentralize and break down their positions that break down their teams into smaller growth units. So they have more autonomy you can do different things. And so that's great from a growth perspective and that's great from an innovation perspective, but the one area that Not great for is security posture.

And the reason for that is because the security posture can't keep up. So if I look at what's the overall effect of the security posture, right? The change here is when I was centralized, you know, this was the great old world of security right?

Everything was centralized and everybody was in buildings. And in that type of a model right? I've got a very well defined perimeter.

I can put things like firewalls and things like that outside the perimeter and I could protect everything inside because that's where everybody is. Now if you I start to fast forward that now when I move to a decentralized group and I have different groups everywhere. Well now I have multiple different perimeters and that makes things slightly more complicated.

But now if I add decentralization to that from an agile software development standpoint now, I've got everyone decentralized but effectively everyone doing their own thing and what that means from an agile software development standpoint is now I've got individual groups of people that are trying to innovate and code up new features and software development, but they're not using the same framework across that they're making their own trade-offs in terms of the applications. They use maybe the summer teens they call for if they're using open source code, maybe the different open source code platforms that they're using and so what you end up is from a software development standpoint you end up with six or eight or ten totally different things instead of one unified object and what that does is security stand. From a security standpoint is it gives you a very very different threat surface and what the threat surface is a threat surface is what we use in security to kind of Define what are all the doors and windows into the software that a hacker could potentially get in and what we see is when we start having multiple different agile software developments.

We get a lot more doors and windows a lot more things to secure we call that the threat surface and we see the threat surface grow quite a bit in these decentralized organizations. So we've we've tried to solve this in the past and the most comprehensive way to solve this in the past has been devsecops. And what devsecops is basically combining security with your devops group?

So think of it as I'm doing agile software development. So I have a Sprint of three or four features that I'm going through on. Let's say a bye weekly be basis and every time I do those work on those features, I'm looking at the security of those features and I'm patching vulnerabilities and I'm looking at what's the best way to do that as those features are our developed and released right?

And so it's a good idea and and has helped quite a bit because then I'm not doing what people used to do which is not take Security application development into the last minute. And what we used to see is we used to see people develop features or group of features. And after the feature was done or maybe even some taste times done and released.

That's when they would start looking at security and then they would start doing things like bolt on Security Solutions at the very very End of the process on a software application to try to fix all the problems and it's effectively, you know trying to secure a house after you've built it right not a very good way to do things. And so what devsecops was trying to do is take that now and break it down and build security into the code developments. And so that each time a new feature is being developed.

I would then turn around and I would look at the security implications and patch that now that sounds good. But now as I get more and more decentralized units the software gets very very complex and it becomes very hard for each individual Sprint unit to catch everything, especially when we start talking about regression testing what a new feature may break in an old unit old load of code. It becomes much more difficult to catch everything and it leaves Enterprises and each Sprint teams vulnerable.

So the fix is something called plant secops and this is a new and evolving concept and what it is is it's a security framework so it goes before devsuckoffs. So before I start writing code and looking at features and deciding what I need to do to secure those features, this is something that I do before a single line of code is written. So the benefits of it are are pretty simple.

It gives you plan security across all software development business units. So now even though I I am allowing my software organization. Let's say to break into business units be very decentralized and be very aggressive about going off in its own Direction and growing.

I have an overall security framework that it operates with it. Meaning as all features are coded up and software is developed. It comes within that same security framework so that I know from a security standpoint that I'm in a good position basically to patch all you know to lock all of the doors and windows in the same manner on all the different lines of code and I don't have everybody just running off doing their own thing and creating this nightmare of new doors and windows that are left unlocked.

Right and so the idea is from an architecture standpoint. It's the idea of building. House, but now building a house and building security into the architectural plans as opposed to devsecops, which is more of a role where I'm taking security and I'm building it into the carpenter group and I'm building it into the plumbing group and I'm building into the electrical group, but they all may do it differently, right?

This is one unified way to do it from the beginning and make sure it's done consistently throughout So there are a couple of different ways a couple of different implementation models that companies may want to look at for plants cops. And the first way that that we see the companies want to do is do it yourself and that sounds great. But in the current environment, especially now with a very tight labor market there are multiple millions of security jobs right now that remain unfulfilled there are multiple millions of software development jobs that remain unfulfilled in this environment.

It's really hard to do this. And so the problem there is kind of threefold first. You have to find these people second you have to be able to lure them from their old their existing job because it's very highly unlikely that they're unemployed.

So you have to hire them away from their own companies. They're existing companies which can be expensive and then you have to retain them. And this is the biggest problem that we're seeing companies have is even if they can find and hire them away from their existing company, then they see another company do the same thing to them and hire these people away.

For yet something else and so they end up being on this hamster wheel where I'm just constantly trying to find Higher and retain these people and I'm just in a recruiting cycle where I'm constantly looking for these people and nothing's getting done. Right? But if I can find these people the next thing I do is I do an audit to assess the current interest security infrastructure and determine basically what architectural plans I need to buy in, right?

What do I need to what do I need to lay out and what needs to be built into the overall to the overall segment and then I need to take that to someone for with authority in order to drive it within the organization and typically in these decentralized organizations that I need see so buy it, so I'm taking this to the CEO see so I'm showing the architectural plans and I'm using that then to sell the value of a plan secops model and get that in place and then once I gotten that buy-in Bad, I want to build and plan a change management system to basically take the organization from a very decentralized View and a very decentralized software development model to a decentralized model with a security framework or a plant second architecture that gives it a framework to be much more secure in the way that it goes after growth and innovation. Now the other way that you can do this and this is the way that we recommend is finding a good security technology partner. Someone who's got experience developing security software and can eliminate the stampster wheel, right?

It can improve time to Market. It can accelerate your jump moving forward to Planning and Building change management. It can give you options for ongoing support and it gets you out of this problem of finding hiring and retaining people that are very difficult to find and almost impossible to retain it gives you this option to be able to take that now and go to a security partner who already has these people is using these people across multiple software developments, you get all of that experience across multiple companies for you.

And then at the end of the project you can use a smaller subset for ongoing support, but you don't have the problems of continuing to have to maintain and keep these people happy and keep these people hired because that's a very difficult job. So that's my overall talk on devsecops moving to plan sick ops in this type of a decentralized environment, and I'll be happy to take any questions or questions for the Q&A session in the next session. Thank you for your time.