In this episode, Peter Maddison and David Sharrock discuss how to integrate threat modeling into the secure development lifecycle (SDLC) at scale. They cover the importance of shifting security practices left, and how to establish communication channels between development teams and security experts.
Key takeaways:
Threat modeling is a security practice that involves identifying and mitigating potential threats to an organization's assets.
Threat models should be created and maintained early in the SDLC, but don't need to be updated for every minor change.
A mechanism for ongoing communication between developers and security professionals is essential for effective threat modeling.
Resources:
Sooner Safer Happier by Jonathan Smart - https://www.goodreads.com/en/book/show/50343488
Whether you're diving into DevSecOps or just looking to get a handle on threat modeling at scale, this episode is a must-listen. Tune in now as Dave and Peter discuss how to future-proof your organization!
In this episode, Peter Maddison and David Sharrock discuss how to integrate threat modeling into the secure development lifecycle (SDLC) at scale. They cover the importance of shifting security practices left, and how to establish communication channels between development teams and security experts.
Key takeaways:
Threat modeling is a security practice that involves identifying and mitigating potential threats to an organization's assets.
Threat models should be created and maintained early in the SDLC, but don't need to be updated for every minor change.
A mechanism for ongoing communication between developers and security professionals is essential for effective threat modeling.
Resources:
Sooner Safer Happier by Jonathan Smart - https://www.goodreads.com/en/book/show/50343488
Whether you're diving into DevSecOps or just looking to get a handle on threat modeling at scale, this episode is a must-listen. Tune in now as Dave and Peter discuss how to future-proof your organization!
Peter:
Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you today?
Dave:
It's a slow roll into the conversation. I'm doing great, peter. It's good to see you again and have a bit of conversation. I'm really looking forward to this topic that we just kind of thought about as we're coming into kicking off the podcast again. I was asking you about shifting left spread assessments, how that those sort of problems align with, let's say, let's try and tie it into digital transformations as a whole, because I think they're very one drives the other. I would expect quite considerably. I've certainly been, you know, having some conversations around that and I wanted to get your perspective. I think this is your home base in many cases, isn't it?
Peter:
It is a space I spend a lot of time in working with all sorts of size organizations working out how you integrate not just threat modeling but all what I call out-of-band processes and services. So one of the ways I talk about that is, say, if you've got a thousand developers, you'll have a hundred infrastructure people and ten security people if you're lucky. And so your experts SMEs who are the really expert people who truly understand what needs to happen are vastly outnumbered by the people that they need to interact with. So that's one aspect of this. From the digital transformation perspective, that means there's a lot of change happening, and if there's a lot of change happening, that means your systems that you are changing are going to be exposed to new threats.
Peter:
If we're going to take the threat modeling piece, there's lots of other things that fall into this type of assessment that you need to do within the SDLC that occur. What I call, as I say, out of band versus in band. In band stuff is stuff that I want to do on every single release. I don't necessarily need to update my threat models every single time I make a minor change to the system, but I do want to make sure that they're regularly kept up to date, so I understand what those threats are. Or am I making mistakes or other things that I'm potentially unintentionally exposing as a consequence of how I'm changing the system?
Dave:
This reminds me of years ago and I don't see these conversations. I don't have these conversations nearly as much as we used to, but we used to talk about non-functional requirements as opposed to the functional requirements that were being built and those non-functional requirements. We kind of often refer to them as the ilities, the stability and availability and all of these other pieces. But what you're describing is really that the mismatch between the pace of change that's happening in any sort of digital organization is driving changes through, like you said, the thousand developers pushing changes out all the time, which is accelerating and has been accelerating, but the difficulty of maintaining and again, not really the word control, but maintaining oversight over that to make sure that the right processes are being followed, to make sure that the right solutions are coming together. Am I going in the right direction there?
Peter:
Yes, yeah, because this is this sort of push and pull between the two different pieces. You want control and speed, not control or speed. You want to be able to ensure that there's the right oversight, and we need this for a variety of reasons. If you're working in and a lot of the work I do is with financial services organizations and so where you're heavily regulated, you need to ensure that you can evidence this easily and that these things are actually happening.
Peter:
Threat modeling is particularly interesting because you're looking at external attackers attackers like who is it that could potentially attack this, how might they attack this and are my systems and assets built appropriately to protect or mitigate against those? Uh, those sort of attacks like how am I putting these things together? Um, this sometimes falls into like security architecture kind of is sometimes a function that looks at sort of threat modeling, although in different organizations obviously structure those sort of areas differently, and some organizations will indeed have people whose entire job it is to look externally and say, hey, is somebody out there looking at attacking our organization, our type of organization? Is there an additional sort of noise out there about attacks into our type of organization? Where are those coming from and what does that mean for us and the assets that we have? What sort of assets might they be targeting, and are there threat models that we have for those assets? Up to date.
Dave:
So, as you're describing that, something comes to mind which is, broadly speaking, there are threat models that you can identify as a known like denial of service attacks and things like this. They're known what they are and how they're coming in, or something like that, and you can look at waves of them coming in because, again, that's the norm nowadays. They're happening all the time. But there's another aspect of that threat modeling I'm I'm guessing which is more driven by defense than a known attack, if that makes sense that.
Peter:
So there's uh. So threat modeling is, in particular, looking at what might be what might attack us, or what attacks might be coming, based on what's happening Based on known attacks.
Dave:
Based on known attacks, typically Known methods of attack, known types of avenues to maybe.
Peter:
But there are methods where, like red blue teams and stuff like thinking about attacking and defense and all. There's lots of stuff in this space that you could unpack and we'll get into some of the pieces around that, but there's that aspect of it. The other piece you're describing there comes down to what organizations might describe as a secure SDLC, like what's your system development lifecycle and how do you secure that? What is the mechanism whereby you ensure that the right things are happening? If, for example, you've got security policy that says all data must be encrypted at rest, how are you ensuring that that is actually the case?
Dave:
Things like that. Yeah, well, I mean that brings that other thing knowing what to do. And knowing that that is you were mentioning about the sort of how do you audit it? Because there's another piece in there which is not just coming up with a good understanding through the threat modeling, understanding what practices to put in place, what systems architecture, whatever those solutions might be to cut those channels of attack off. But at the same time, there's how is that maintained? How are the conversations as things change, as you bring a new vendor on board, for example, that may be working in that space, how those conversations are progressing and actually happening right, and this brings that people side into it a lot of the time.
Peter:
And it is. It has to be a person to person conversation. It's not especially across a large heterogeneous environment. There's no way you can automate every single possible edge case or use case for what you what you need to do and part of the problem is where you don't, because you haven't started doing it. You don't necessarily know what it is you need to do yet, but you do want to, as you were describing it, shift left and have those conversations as early as possible.
Peter:
So what you need is and remember my sort of 1110 type thing. I like that, because what you don't want is that I've got my security architect and my security architect basically says you're not allowed to make a change until I've given you the right to be able to make a change. You've got to come talk to me, because that just gums up the works. Things will just get stuck waiting because I've only got a few people and there's a massive queue of stuff that needs to happen, and so you've got to work out ways to start to streamline that. And there are a few things I mean the more homogeneous your environment is, the uh, easier for this to do, because I've got consistency and standards and this is so that I can say, okay, if, if you build things on this platform in this way and can show me, though, and with these patterns, then you're good to go.
Peter:
And the problem is that that kind of sort of drives you down a particular path. Um, and I I haven't necessarily seen that work well at scale. It can work for certain areas, but as long as you stick to the sort of primary patterns. There's still then the other ones where it's like well, I'm trying to actually do something I haven't done before, and I need to have a conversation with somebody about what does that look like? And then you need to find a way of saying, well, what's the priority here and how risky is this, and which people do I want to talk to first.
Peter:
And so, because what you don't want it to be is all based off the hippo going like do mine first, do mine first, because that isn't necessarily the right thing to do. So you need a prioritization mechanism, you need it to be transparent and you need the organization to be agreed that that's how they're working together to do this. You also need it to be continuous, because one of the other things that happens as you switch from a project to a product mindset is that you're making a lot of small changes much more rapidly, so you can't say that there isn't a design phase at which we're going to stop and we're going to do this. You're continuously designing the next little piece.
Dave:
So you need that continual conversation, so you need to set up the system to support that I'm just thinking of, where I've seen this in organizations, has to do with a lot to do with less on that sort of threat modeling side and more on the shift left, where you're moving from releases once a quarter or once a month or whatever it is, to releases much more frequently, to eventually releases on demand from, like you said, those thousands of people who are out there.
Dave:
And one of the things that really comes out is the importance of education, of helping people understand the impact those changes can have and the responsibility that they have to be smart about it. I mean, you can't be involved in every single conversation, so there are certainly touch points which are a little bit more amorphous, because there isn't a design phase, like you say, but there does have to be recognition of when those conversations come together, and I think this is it's. I find it quite interesting that we're working in right now in a market which is trying to get more for less and they're they're, you know, really pushing a lot of like emphasis on efficiency, if you like, and it's squeezing out? My fear would be, is it squeezing out those, those conversation and the education elements and the, the bits where we raise our head up and actually look around and think a little bit about what we're up to right, and and I mean this is actually one of the dangers of potentially driving people down into the, just purely into patterns.
Peter:
and if, if I do end up doing something outside of that, how do I know in a conversation? And? And so, yes, there has to be time made for those conversations and it has to be done at the right point in time I talk about it in terms of triggers and when we put these systems into place. And so what are the triggers? What are you going to hang this off? Is it going to be cadence based or is it going to? Is there an actual product roadmap where we can look at that and say, okay, I'm going to look.
Peter:
You need to maintain your roadmap in a way that I can look at and decide whether or not there are things coming up that I'm going to want to talk to you about, and then from there, we can decide how often we need to talk, and so, and then we? Then the other part of that is we. If there are identified risks, things that we see that need to be changed before you push things into production that need to be resolved, then those need to be a part of the work that gets assigned to you. So how do you then embed that into the work system?
Dave:
so that that occurs. And even as you're describing that, I'm just thinking of so many of the conversations I've had where what you're actually seeing is the business. Now we're stepping into the business side of things, where it's sort of the rubber meets the road in terms of interactions with customers and everything, and they often have a lot of will and authority around what they want to see done because their problem is outward focused and what they're really trying to kind of build the relationships and get the whatever the products and services out to the people that matter. But at the same time, they're never thinking about that sort of the technical consequences or the risk consequences of some of the decisions that they're making. And again, it comes down to that education, broadening the net in terms of helping people understand the areas where, when they're making recommendations for changes, they are thoughtful about what the consequences of that are.
Peter:
And another way of articulating you were just saying that is where that big risk comes from is that on the business side, it's the business and the IT and it's not our business delivering a product that enables our customers. And and while that's the case, while IT is software delivery and they're seen as a cost center, because just by the fact that they're called software delivery, they can be seen as a, because it's like well, they just build the thing and so I just have to tell them what I want and they're going to build it and that's. But that's the wrong way to go about it. Make it.
Dave:
So it's just a make it so, model yeah.
Peter:
Yeah, because now you're potentially building the thing, so that that's, that's a part of it for sure. Um, I'm looking more holistically at it. Um, I'm I'm conscious of time because I can talk about it. Yeah, there was hours, okay, so uh, so uh, because otherwise I mean we could start to talk about, um, like open source software and how that fits into this third party solutions, how you you asking about how this bakes into procurement and like what the different aspects of this from a systems perspective are, how you tie this into compliance and GRC, what policy standards procedures look like.
Dave:
But let me, let me tone this like, let's try and put a, you know, wrap this this up. I'm going to ask you to summarize in two key things. One is what are one or two or three things that you think everybody should know about threat modeling and about the shift left conversation that we've just had? What's the couple of key takeaways? Be aware of this, see this happening, ask about X, whatever it might be.
Peter:
Well, for threat modeling in particular, I mean that's a security practice essentially. I mean you're looking at threats to the organization that potentially are going to impact the assets within the organization. What do those assets need to do? And the concept there is that for all, especially your externally facing assets, but for everything really you need to create and maintain and update threat models, and that needs to be done earlier in the system, but they don't need to be updated all the time.
Peter:
The problem is you need to be updated with major changes, but what's a major change? I mean that could be anything. A minor change could be major, depending on what it is that you're changing, so that you can't sort of hang your hat off that as a solution. So what you need is you need to have a mechanism in place where there is conversation, where the SMEs can see what's coming and start to identify what sort of assets are going to, what assets are going to be changing in ways that are potentially going to be impacted by what they see as threats in the environment. So we know that those are the threat models we need to go and look at and update. So that's kind of the piece where those two parts come together to create a piece of whole, and so putting a mechanism in place to do that, I think, is one of the critical takeaways, I would say. And so what was the second part of your question?
Dave:
So my second well, my second question was going to be okay if any of our listeners are thinking I'd like to find out more, whether it's find out more because it's of interest and I'd like to move into that space, or find out more because it feels like I should know more about this. Where would you point them for? Is there a blog or book?
Peter:
or they should give me a call. Okay, that was a very, very easy one for you. That would be. That would be one of the options. But, uh, but also, um, some of the practices I'm talking about. One one, one example where this is talked about, uh is in the sooner, safer, happier book. We've talked about that for chapter six is lean control, which talks about a lot of these types of concepts. So I'd recommend picking that up and reading it, because that'll talk about a lot of these at a high level.
Peter:
There are some other interesting people who are doing some interesting things in this space. Larry Marchione I was messing up his name, but he's got a very interesting perspective on tying coaching into security assessments and shifting that entire model left and the way that he goes about doing that, which he talks about in various videos. Maybe I'll dig out the links and we can add it into the show notes, so that's another interesting one in that space. There's some great stuff on conversational architecture on martin fowler's blog. That that's another good thing to look at as well, because that that starts to get you into the, the concepts around. How do you do these, these more esoteric? I guess these bits that need to happen out of band and make sure that they're happening in a good way and build the cultural elements around that Fantastic.
Dave:
Well, thanks again that's been. It's been an interesting chat, as these things always are. So, if I remember rightly, feedback@ definitelymaybeagile. com and subscribe please Until next time, thanks again, Peter.
Peter:
Yes, thanks, Dave, it's always fun. You've been listening to Definitely Maybe Agile, the podcast where your hosts You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.
