Watch this episode on YouTube.
Reasonably Accurate 馃馃 Transcript
Good morning. Uh Everyone's having a great day. I was off yesterday because I was in uh National Harbor Maryland um at the Gartner Security and Risk Management Summit. Um I was there giving a talk uh called Security in a Dev Ops World.
Um Now that talk and a bunch of content sort of spilling out from that talk is gonna be available on the trend micro um channels shortly. Um Over the next couple of days, I'll be publishing a ton of stuff there. I'll make sure to link it out um on my Twitter Mark NC A and add it into the comments.
Um If you're seeing this post on youtube or other places, um when that goes live, what I wanted to tackle uh in this episode of Mornings with Mark is just a quick overview into the development process because I think for a lot of security teams, um there's a bit of mystery there, there's a bit of bit of fog.
Um Not so much understanding of how software actually gets created or it projects are actually delivered. Normally security gets pulled in. So right before a project gate of you need security's approval So, you know, the day before they're like, hey, security, we need you to approve this as opposed to being involved early.
Um And then again, right before it goes to production, they need security to sign off on it. So again, security gets pulled in. But I think there's a really important lesson to be learned in understanding the development process itself because there's been a radical shift over the last few years where the additional method of development is shifting into a more modern approach.
And there's substantial differences there and there's a huge amount of security advantage if we're involved. Um The advantages are around sort of the shortened feedback loop. So I'm going to switch over to my ipad right now. I'm going to show you that a little bit of a different visual look for those of you on the podcast.
I'm going to narrate this as we go. Um so that you're not left out. But this development process essentially in a waterfall. What used to happen was that you would have uh software be created and then just sort of bubble down, bubble down, bubble down, bubble down.
And this is why we call it a waterfall is that at each stage, there was another release or another phase of the process. And essentially you would end up in sort of month zero all the way to kind of a 12 month cycle for a lot of folks.
Um And over the course of this time, you know, you would require, you would gather requirements at the start of the project. Um And then by the end of the project, months later, you would come back to a customer and say like, oh, hey, here's all this stuff that you had wanted months and months ago.
And of course, they're like, well, hey, the business has changed. Everything is very different by now. Um It doesn't really work that well. So, um there's been a huge push for a thing called Agile or Scrum. There's many iterations of it.
And essentially what that's done is shorten those feedback loops so that people are involved early in the process. Um that businesses understand um sort of the business units, understand what they're getting as opposed to um development, leaving and coming back months later saying, here you go.
Um And now the common way to put this um sort of visually is in cycles. So you'll see this kind of this donut wheel very much an infinity sign going back and forth where people are saying, you know, hey, this is how development works.
Now it's you're developing stuff and you're in this short feedback loop. So there's left side development, you finish it, you push it over to the right side of the infinity wheel and that's where we get this continuous process. Normally, you have something that we call AC I CD pipeline, which is a continuous integration, continuous delivery pipeline that implements this kind of a flow where you're going through various development stages in short quick iterations to get stuff out into the hands of your users quickly.
And of course, in the SASS world, in the cloud world, they've pushed that um all the way to um multiple times per day. But a lot of enterprise organizations that I talked to have gotten their sprints down to um somewhere between 1 to 4 weeks, depending on what makes sense for them.
And even at four weeks, that's significantly better than the normal 12 month cycle. So you're getting feedback quicker. And I think that's absolutely critical. Now, what I wanted to, to talk about um in this video, um understanding that, you know, short on time because we keep this one, this format pretty quick.
Um Was that there is a, a set of steps on each side of this wheel. So if you're looking at the dev side of things, um we start with number one is planning. So we're gonna plan out, what sort of a feature are we gonna build?
Then we're gonna actually code it up, then we're gonna test that code, then we're gonna stage it. So now we've completed the left side of the wheel is that we plan, we code, um, and then we uh test and we stage so we figure out what we want to write, we write that code, we test it and we stage it once it's finished and approved in staging.
Then it goes over to production. This is now the right side of the infinity wheel. Here we run. Um We ideally detect any issues. Uh we uh respond to any issues. My writing of course is horrible for those of you on the podcast.
I'm saving you this. Um And then we mitigate any issues. So here we have the opposing wheel and these wheels run in different ways. Um They run counter to each other, one runs counter clockwise, the other one runs clockwise. So we've got this sort of integrated wheel.
And in each of these stages, there's an opportunity for security. And the problem that we've had is that by and large, there's just a solid wall where security has worked almost exclusively in the production environment, right? We work on run, detect, respond and mitigate this is where we work and this is where we're comfortable applying security controls.
We have essentially ignored the development wheel much to our detriment because things are significantly cheaper on this side. If we go on the development side, it's cheaper and cheaper to fix the problem. So we need to shift left, we need to move from one side of the wheel, from the production side of the wheel.
The idea of shifting left is moving over and applying security controls in the development stages. So in the planning code test and um staging phases of all this, and that's really what this is about what this push for pushing security to shift left for getting involved earlier is understanding this development process and realizing there's huge wins to be had there.
That was a key point in the talk I delivered yesterday, we got a ton more coming out. Um Like I said on the trend micro channels and I'll echo them on my own. Hit me up at marknca. Um What do you think about development?
Uh as far as being a security pro um Are you used to development for developers that are listening? Do you ever talk to your security folks or is it just at the end of the phase is at the end of the gate?
Um Let me know, hit me up online at marknca comments down below or as always by email me@markn.ca. Um I, I think this is fascinating. I think this is where we need to go from a security perspective.
We uh it's very complicated because it's a lot of people work. Um But it's work well uh worth doing. Um And I think we need to shift our focus from security and I think uh we need to work hand in hand with developer and operations folks to make sure that all of our systems work as intended and only as intended.
I hope you're set up for a fantastic day. I will talk to you online and uh see you on the show tomorrow.
