My background is as operations and then more into the DevOps side of things. And so actually seeing how we can create proper business value really got me excited. And so that's where I want to try and give away some of those tips and tricks that I've seen in my career. But also as we've heard throughout the day to day about actually that collaboration being also important now I've only got 20 minutes. So you would expect me to take a lot of time going through this and being very proper with each and every part of this. And this is very true. There's a source there. You can go and have a look and read some more. It is culture transparency, and then shared goals and metrics. So really, if I was a consultant organization, I could put this up on the screen, charge you lots of money and then go away and have cups of tea and coffee and think everything was great.
But actually I'm an unco Scottsman, as you can hear. And so instead, I like to look at things as who, why, what and how, and go through those and see what it is that we're trying to do for this software, collaborative software development life cycle. What's this all about? So of course it always starts with who it's the people that make up the organization and that's who are delivering the change and who are actually doing things. And so this is the thing that we really want to get to know people and go, what is it that's going on? So if you're in DevOps and you're trying to build stuff and we want to have this nice software development life cycle, go hug a security person. Although I admit there, I've put it in brackets just to have that caveat perhaps in a socially distant way or whatever is appropriate to your local rules and regulations, of course, and, but hug a security person because you are both on the same side, or if you're not, then you still need to be working towards the same goal.
Ultimately, we are not there as precious individuals who the company feeds in waters because it likes us so much. Unfortunately, we are there to try and deliver something as a company and do something for the organization. So either way we need to come along to the party and we all need to get along. Somehow, if you're in the security side of things, it might be very easy for you to say, well, that's DevOps problem. They should be dealing with this. Well, you should have a look at what's the path to production. How do things work? Just now people don't build insecure software because they think it's a bit of fun, but actually because they have additional pressures that they're working to. So how do your DevOps teams deliver the things and what are the things that they're delivering? It's not enough to now look at things as just a business service, but actually, what is it that makes up that service?
Cause as we've heard throughout the day, there are going to be a number of different ways that those business services are consumed. There could be fancy new microservices, things that are running on different clouds, or even on our, on premises clouds. We could still have nice big workhorses that are sitting in the data center, but they're still being developed and delivered. So what are those things doubtless? There's going to be some version control used somewhere. Are you comfortable with version control if you're insecurity and it's very well saying, wow, I get the idea, but actually what does it mean? How is it being used and honestly going and saying, I can tell you left right and center around all the regulations that as an organization we need to care about is one thing. And actually having DevOps teams say open up and say, well, this is how we're operating.
It's a difficult thing to do, but it starts with the people speak to the people. And then the next thing, there are the metrics. Well, you know, I've very amusingly. Why would be metrics? Why are we, why are we doing this secure software development life cycle? Well, it's not, it's not metrics it's you, you see what I did there quite a, quite a pun. But anyway, that what it is, is that's meant to mean that what's important to one person isn't to another. Now as a dev ops team, I want to see the performance improvements. I want to actually spend less time having to deal with security gates. I want to spend less time having to manage vulnerabilities or compliance issues. I actually want to keep things moving and as security, I want the same things, but I want to see that reduction in risk.
So actually we both want to get rid of the vulnerabilities, but actually one wants to see it in a different way to the other. And this is worth shouting out because it means that we can do fun things we can put in some gamification of security. And yes, I do realize I am going through this and very fast pace, the slides are available. You can have a look through them. I will also am happy to talk to anyone to go, okay, crazy. Scottsman slow down and take me through that point you made, but we can gamify things. If we both realize we're going the same direction, but perhaps different things are important to us then are we able to say things without exposing those risks? So I call this out because if I speak to a security person and say, well, why don't you put in a way of every week show the different DevOps teams and how they've improved and reduced risk.
And that way you're trying to get some, a healthy competition in a friendly way. And of course they then go, no, well then you're telling everyone all our dirty laundry and it's going to be each team. Well that's possible, but you can do it in a different way. You can show most improved and not actually highlight number of vulnerabilities. There are ways of doing this. If you appreciate that top point, which is we're measuring different things to achieve the same outcome. And then equally, if you're in DevOps, how about rewarding security, give security a chance while you're hugging one of those people in security. Why don't you have to think about what would make, bring them into your processes, excuse me. So if you're playing JIRA, tennis, maybe stop and actually instead go, here's our version control. Here's how you can create a pool request.
Here's how you can take part in our, our development process. So what is next? What happens if there are going to be exceptions, there is going to be drift and communications will break down. So what we're saying here is strive for perfection. What we're trying to do is get better. We're striving to do things in a better way. So accept that continuous improvement. Now it's all very well throwing these words about, but what does that actually mean? How are you going to trace that you are improving over time and how are you going to accept that things are going to be bad. Occasionally that's the nature of the business. I'm willing to accept that computers were a mistake and we should never used them, but here we are, we're doing them now, right? So let's see how we can keep making things better. And this is a big point that managing exceptions, there will be exceptions.
So having hugged a security person and said that we're really happy with the what. And having said that we're going to do this way. Pardon me? The who? And then having said that we're going to measure things in a good way, and we're going to gamify security and we're going to have teams collaborating well. Ashley, does that not mean everything's going to be green? Unfortunately it's not. There will be exceptions. Software keeps on having vulnerabilities. There are changing regulations that happen. Actually, Mike Small talk this morning was really interesting to say, to pose that question. What, what would you do if suddenly you were hit with this requirement with, and forgive me, it was something like 12 hours they had to, to suddenly comply. So how are you going to manage those exceptions? What, what will happen when there's an exception and what happens when there's an exception to the exception?
You know, if we've got a vulnerability has to be patched in 30 days, but unfortunately it can for business reasons and good reasons. Well, we need to have a way of feeding that back and keeping that loop active without overwhelming, with just false, false alerts coming through. And that's through having reviews, acceptance, and mitigation. We, we sometimes get caught up in, in it with saying, well, we are, we are it. We're very smart. There's lots of things going on. It must be impossible for people to understand, but actually we can present things as business risks and actually saying, here's how we review those risks. Here's how we accept. Here's how we mitigate. And if we can't, then that's a business risk and have a, have a racy chart to say, this is who's accountable. And I've already said it today. You can't outsource accountability for your security, regardless of what you're doing.
You, you need to hold that accountability. So write that down and next to how everybody loves tools. This is where everyone jumps to. When they want to do anything. I had a wonderful conversation with my wife who started a new job and she turned around to me and she said, do you know anything about access? I think it's a database. I went, yeah, it is. What are you trying to do? Oh, I just want to use a database. And then I had to stop and go. Really, really, we're gonna jump to the tools before defining what the, the issue is. So think about those tooling. It's all too easy for people in security and people in the, the DevOps world to dive into this as the first point. And what happens then is you end up with point solutions. You have point solutions for one little thing that you need to do over here.
And another little thing over there. And then you run the risk of trying to glue them all together. And Kelsey heter on Twitter as a wonderful tweet where he's saying, if you wanna roll your own application platform, then you bring lots of tools and lots of glue, lots and lots of glue design for multicloud that could be private, could be hybrid, but expect that your organization, which we are helping to grow and become a wonderful thing, expect that it's going to have mergers and acquisitions because it's going to grow cuz of the work you've done expect that it's going to try and do different things in different capabilities. So design for that have that ability to say, right now we are using this X technology, but we accept that because of, again, going back to what Mike Small said, perhaps some mandate comes down that says we are no longer able to use that.
So design for being able to be fruitless that might just be having well, well defined and clear exit strategies. That that's what you need to look at. And then when it comes to security, that's where you're then looking at that and saying, right, instead of those point solutions for my cloud security posture management, do I want to have something that will work across the board or what happens if I do have to migrate away or to the public cloud, whichever way we're going, we need to be able to design for that. And in much the same way design for that multi compute. So yes, we might say just now we're a really cool startup. We only have several as functions. None of that legacy nonsense, even VMs for us, our legacy, but actually that's, that's not gonna be true. The, the workloads exist for the different, different compute workloads are there for, for different things.
So Chris, who I was talking to earlier, put it very well. I'm not gonna get rid of my classic car that I have in the garage. I don't, although I might take his because that's used for a different purpose and my family run around that. I have, I certainly don't take the dog out in the classic car, but I do in the family run around. So expect that you're going to have different compute and how are you going to secure that? And so we've got these ideas of cloud workload protection pieces. They exist and they're very necessary. Now in order to do all of that, of course, we would recommend a cloud native security platform. And that's simply because if you're going to be looking at what your functions are from a tooling point of view, do you really want to be jumping into the tools?
First of all, without defining all of that, who's doing what, how you're measuring it and all of that good stuff. You dive into the tools you create, all those point solutions. You try and plug everything together and you end up just engineering for engineering's sake. And I can say that as a recovering engineer, that's the, that's always the temptation, isn't it. I've got an eye on the clock there just to check, but I'd love the, the, the story I was telling a colleague, I bought my son a model railway set, and I immediately went about designing how that model railway was going to look where the little Hills were going to go, what the pretty trees were that you could get. And then of course, he ended up saying he just wanted to play with the train set. And it turned out that he didn't want little trees and he didn't want little Hills.
He just wanted to put a train up and down the track. And then, and generally misused, what I thought was a very fancy to, but is that, you know, who are we delivering for? What are we delivering it? And why do we need to focus on the tools for biggest ROI? Just to shout out, even if you're going to ignore everything I've said and say, Ashley, you're a you're dang, fool, just patch, come on. We we've, we've had this problem for years. And the, the difficulty is when we move into multi compute areas and we move into multicloud is having visibility of all those different things, all those different workloads, but just focus on patching things and focus on misconfigurations. You, you've got very many tools out there to try and help many open source tools such as checkoff. You can pick that up from checkoff.io.
And there are owner ways of seeing who owns something. So you know that your security operations center isn't going to be left in the dark because you've got other tools that are there. And listen, there, there are lots of things here for you to look at. You'll see the slide deck that are there. So the last thing, what about when Ashley? You've never said about when, well, I'm gonna say an old proverb, the best time to plant a tree was 20 years ago. The second best time is now. And we have the information. We have the data there that's available. You've got a link there. You'll be able to pull it up and peruse it at your heart's desire. But ultimately we are seeing an huge increase in cloud usage over the past year for a very good reasons, as we all know, but this is data driven. We have seen that. It's not just anecdotal and we have also seen a much greater increase in the top cloud security incidents to go along with that. So please have a look at that threat report. Please have a look at this and, and come back to me with questions. You've got contact information there for me. Should you wish to reach out, but I will take a breath and a glass of water and see if there are any questions.
