When product development teams build new software tools and systems, they like to start with the end in mind by nudging quality assurance and security scanning closer to the early stages of the process. Paul Connaghan, Principal Application Security Consultant at RiverSafe in London, UK, says this “shift left” approach goes straight to the heart of business operations by embedding a security mindset in the underlying architecture, in UX and UI design, and in the QA and app hosting apparatus.

In this episode of Product Momentum, Paul sat down with Paul Gebel and Jonathan Coupal, ITX’s VP of Infrastructure, stressing the importance of moving security considerations to the earliest possible phase of the SDLC (software development life cycle).

Shift Left
“Shift left has been something of focus for clients a few years now,” Paul says. “Once we’ve actually written some code, we want to test that code as soon as we can.”

Paul’s passion for app and system security, and threat modeling specifically, is obvious. It’s a task typically performed by security folks, Paul adds, as it can be quite involved to produce threat models for things that we don’t entirely understand. Nonetheless, he advocates for teaching product teams to do this for themselves.

Build a Security-Focused Culture
“It helps us address the skill challenge, because there’s just not enough people in cyber to effectively secure all the applications and products that are out there,” Paul shares. “But it also gets teams into the habit of having daily conversations about security, which is fundamentally really the thing that’s going to help close the [security knowledge] gap and build a security-focused culture.”

Question: within each sprint, how much capacity does your team allocate for security? None? 5%? More? Be sure to catch the entire episode to learn Paul Connaghan’s expert recommendation.

Learn more about application security and threat modeling by catching our earlier Product Momentum episode, with guest Chris Romeo.

You can also watch our conversation with Paul Connaghan on the Product Momentum YouTube channel!

Podcast: Play in new window | Download

Paul Gebel [00:00:19] Hello and welcome to Product Momentum, where we hope to entertain, educate and celebrate the amazing product people who are helping to shape our community’s way ahead. My name is Paul Gebel and I’m the Director of Product Innovation at it, along with my co-host Sean Flaherty and our amazing production team and occasional guest host. We record and release a conversation with a product, thought leader, writer, speaker, or maker who has something to share with the community every two weeks.  

Paul Gebel [00:00:43] Hello and welcome to the pod. Today we have the privilege of being joined by Paul Connaghan. Paul’s the principal application security consultant at Riversafe, where he brings a wealth of expertise from both in-house and consulting roles within large global corporations. He spent over three years leading BP’s developer security team, and now spearheads the application practice at Riversafe. A seasoned expert in threat modeling, CI/CD testing and cloud security, Paul’s passionate about instigating change throughout a people-focused approach and agile methodologies. He’s experienced as a speaker and recently took part in a debate in the Houses of Parliament as part of the panel of selected experts to address the cyber threat facing the UK. Paul, thanks so much for joining us today. Appreciate you being on the show.  

Paul Conngahan [00:01:24] You’re welcome, Paul, it’s great to be here. We’ve been waiting a while to get this discussion going, so I’m delighted for we’re finally connected. This chat I’m looking forward to it. 

Paul Gebel [00:01:34] Absolutely. To get this started, I’m going to toss it right over to to my co-host Jonathan to get us going with some ideas to lay the land.  

Jonathan Coupal [00:01:41] Paul asked me to sit in on this one. I’m the security guy here at ITX and I was really excited to have another security guy to talk on the product development side of the the business. One of the big things that there is in constant discussion is this idea of shifting left or shifting security left. And for those of our listeners who might not be aware of that term, the idea is to move some of those nonfunctional requirements that get tested in the quality, or the quality assurance end of the spectrum, back into the intentional design end of the process. I’d love to hear from you a little bit about your kind of feeling, about the shift left concept, and maybe how it plays into a lot of common misconceptions that we see in product design.  

Paul Conngahan [00:02:26] Yeah, sure. I mean, you know, shift left has been something of focus for clients six, seven years now. So, you know, I think it’s one of these things where, you know, we often think about shift left being like, you know, just about security scanning. So like when we’ve actually written some code, you know, we want to shift left and test that code, as far left as possible, left to right being the, you know, the sort of SDLC, but actually you can go further left and not right. And that’s one of the topics that I’m really passionate about, which is threat modeling. Typically threat modeling is, you know, something that’s conducted by security folks like you and I and cyber organizations and, you know, it’s quite hard, quite involved to go and produce threat models for things that you don’t understand. Right. So it takes a lot of time and a lot of effort.  

What I advocate for is actually teaching the app teams, the product teams, and do this themselves. You know, that I think is beautiful in a number of ways. One is it helps us address the skill challenge. There’s just not enough people in cyber to actually effectively secure all the applications and products that are out there, but also it lets us get into the habit of having everyday conversations about security, which is fundamentally really the thing that’s going to help close the gap. We’re still developers out there, software engineers out there, product folks out there who don’t have this kind of baseline knowledge of what it means to deliver a secure product and, you know, Houses of Parliament event? I was at another one last night, actually. And, you know, this topic came up and it’s about trust, really. Right. You know, so the eventual outcome of all the products that we create is we want consumers to use them. Now, they’re only going to do that if they believe that it’s secure. And I would attest right now to the fact that there’s only going to be secure if we start thinking about security and some sort of checkpoint and integrate it into daily work. So, you know, for us, we advocate for threat modeling within sprints, you know, in increments that teams use anyway, I’m just asking some basic questions about, you know, what new faces have we got here. And we had a discussion about, you know, as a security team do we need to think about controls for threats that exist, etc.  

Jonathan Coupal [00:04:46] Yeah. How do you get development teams enrolled and the idea of shift left or of designing security, especially considering their practices are already kind of grounded in, so to speak. You know, they have habits of how they do their development work and how they write stories. Are there any tricks or techniques that used to get people enrolled and opening themselves up took more of a bigger picture.  

Paul Conngahan [00:05:10] Yeah, it’s all psychological. So a lot of this stuff saw, you know, I’m a bit of an outlier and will tend to stress things because I’m talking about these really soft, subtle things. But you know what? If I’m wrong when I program, when we want to change developer behavior with our students, that is a behavior change. And think about how humans actually think at heart. So some of the things that I do, you know, are very, very subtle. I want to dive into the craftsmanship of software development. 

Nobody comes to work thinking, hey, I want to make an insecure app. Nobody comes to work, and says I want to create lots of problems down the line, or I want to spend six months creating this beautiful thing for some guy to come and racket down the line – no one wants that. But equally, they don’t want people walking around the big lists for, hey, you know, you’ve got lots of vulnerabilities. Fix them now. So for me, it’s all about taking a human centric approach.  

But we have to accept that these teams have processes they already use. You touched on that yourself, right? So the first thing I would say is from a cyber point of view, unless you’ve got that attitude, the absolute earliest anything’s going to happen is two weeks from today. And then the next increment, then you’re already losing, right? There’s nothing about what we do from a cyber OpSec point of view. There’s, you know, more important value these applications and products bring to the organizations. So we have to respect the processes. And also we need to use subtle language and words to help these developers, engineers and product folks understand that we care about helping them. We’re not here to be a barrier. You know, we actually understand what their craft is and how it works. You know, the subtle thing I always start my conversations with, with every team. Now, they don’t realize that this infinite template that seems not sure why that’s it, but it’s pretty much hundreds of teams over thousands of apps. So it’s probably, you know, from a cyber team, blah, blah, blah. I know nothing about your app. So before we get any further, can you just take 5, 10 minutes and speak to me a little about your app and what value it brings to the organization? That seems like a really subtle thing. Straight away, emotionally, they’re like, oh, this guy cares. And that’s important, right? You need to build up rapport and social collateral with people. So that they want to do it, right. You know the reason. […unintelligible…] Typically, that’s what I’ve seen, right? Responded well to that and all of that enticement. And I feel that flattery will sure go a long way. So, you know, engage with them on a human level first, build that rapport. And I’ve found that, you know, they often want to do the right thing. You just want to keep meeting together.  

Which is the second part of, of the dynamic beyond doubt in that solid sort of first real human connection with them. You also need to make sure what you’re asking them to do is kind of feasible, right? They have to be able to do things and days and weeks, probably days, you know, so it needs to be small. Don’t want to be using extra tools. Ideally you want to meet them where they’re already at. So like no one wants you to give them a new portal of any description for last two, three, four portals for sure. It’s tools, right? They’ve already got 16, 17 different tools for development. So what we what we specialize at Riversafe is keep the tools that you’ve got. Let us worry about the security side and we’ll give you things in there that you should pay attention to. You know, we’re helping you to see the signal from the noise.  

Paul Gebel [00:08:56] Yeah. That’s an excellent segue into a topic that I wanted to pick your brain out for just a second. The idea of shifting left, I think, can go even further to when, you know, beyond development and product design specs into really a user centric design model and user centric design, meaning sort of the the end to end experience, not just the look and feel and components and buttons and fronts, but the actual the experience of the journey through an app in a technical ecosystem. So thinking about this aspect of designing secure products, what are some examples even further out than sort of the, you know, developers don’t come to work wanting to build an insecure platform? How can designers take a page from that same playbook and think about other examples where keeping that user as the center of good product design and architecture can start at the that user-centered design phase of thinking about really foundation up of of an app.  

Paul Conngahan [00:09:51] I would use an example that takes us even away from software, something that’s quite easy to talk about. You know, so if you’ve got an electric vehicle and you want to install a charge post at your home, I think it goes without saying that you don’t want your neighbor to take your […unintelligible…] and charge their car, right? You know, so this is a fairly obvious user requirement that you might find if you’re going to do research users about, hey, you know, we want to charge post in the room. What are your concerns? I mean that’s a slightly different technique to the ones that we might typically use in terms of, you know, you could draw the charge post ecosystem and do stride or something like that to enumerate potential threats. But I bet you if you were to do user research, people would say things like that. But what makes you reluctant to install a charge post, right. In a, you know, there’s someone at the event yesterday that they’re dubious about having a smart fridge because like, you know, all this connectivity, you know, this IoT connectivity, you know, comes in, there’s an attack factor. You know, nefarious actors can affect your life or, you know, impact your life by leveraging these connected devices. 

I can actually attest to the fact that the general public are thinking about this stuff now, and some of them are maybe overly worried about it because the potential’s huge for for harm to happen. Like, you know, it’s definitely a hot topic here in the UK. People are thinking about all this stuff. I think the geopolitical situation across the world makes, even more of a point of issue for everyone, where organized crime groups and state actors are, on the rampage to get money and to cause harm.  

Jonathan Coupal [00:11:30] Yeah, honestly, anybody who’s gone through a nasty divorce can probably tell stories about poor security on user connected devices have let alone or the threat actors and the people with that kind of animosity. I wanted to touch on something you mentioned a couple times, which is threat modeling. The tooling of threat modeling includes a bunch of ways of thinking about stuff like you mentioned stride. Sometimes we think about like, what does a threat actor look like? Or identifying threat actors. What’s some of the tooling in your threat modeling process that you teach your development teams that you work with, that you find them or that they find to be more effective?  

Paul Conngahan [00:12:10] Or I’m not sure if everyone’s going to like this answer, but actually the tool is very much a secondary issue to me. So the only tool that you need is a pen and a piece of paper and people that want to talk. Right. And that’s where I always start as a point of maturity. Right. Especially when you think about enterprise. Right. You know, when you’ve got thousands of, you know, software engineers and product folks and large organizations. The first challenge, I think, is actually not to get caught up in which tool best, and that applies to all app sectors. It’s not just about modeling, right? The differentiation between one, two and another was very subtle often. And the question of whether that’s the right tool for that organization or not, has many different perspectives that you have to consider. So it isn’t like a right or wrong answer. Sure, there are better tools, you know, top-right quarter of the Gartner quadrant and all this sort of thing. But actually the tool isnt’ going to save you, right. What’s going to save you is the people and process aspect of it. And that’s what we spend a huge amount of time focusing on. So the first thing you’ve got to try and break down the barrier on when it comes to threat modeling isn’t which tool you’re going to use. It’s like, how can we actually get these teams to have this conversation? Let’s not over complicate it.  

The only tool that you need is the ability to draw circles and lines and rectangles – i.e., a data flow diagram. Something that’s going to remind you of what the state categories are. And then you can go, right, and you can roll this stuff out all across the globe. And you know, I remember speaking to some guys and they were like, this is really cool because we were having more shallow moments after the training when we were like, you know, what are talking about the potential threats, and I’m just building them out. Like my heart just warmed to hear those words because that was exactly what we were intending for. And, you know, when you get into, the point when the conversations are natural and happening frequently and then you want to say, well, actually, these drawings are constraining. I want to be able to be used. Models are intelligent, clearly models. And at that stage, I think that’s where tools come in. And you know a lot of the tools are much or much less okay. You know, the things that might help a client to choose a tool over would being far more sort of organizationally specific. You know, tool A versus tool B, might be because it’s got a better integration with the ecosystem that they’ve got.  

Paul Gebel [00:14:37] Hey, product people. Some exciting news to share about product momentum. We’re teaming up this year with Mike Belsito and Paul McAvinchey eventually, and all our good friends at Product Collective, beginning in the Big Apple on April 18th, will be recording live at the New York Product Conference at The Times Center, with conversations already booked with a great April Dunford, Holly Hester-Reilly, and many more. In fact, the product conference is only the first of three Product Collective / INDUSTRY events where we’ll be recording with their amazing keynote speakers. We’ll also be in Dublin for INDUSTRY Europe in mid-June, and then in Cleveland for INDUSTRY Global in late September. To stay in the loop with these events and more, head to itx.com and sign up for our newsletter. And now let’s get back to the show.  

Jonathan Coupal [00:15:17] Let me ask a little bit more strategically about threat modeling. If you look at a lot of the materials that’s built around threat modeling, especially a lot of foundational stuff like Stack Row, it really looks like it’s the process is tuned for people who are doing stuff that looks a lot more waterfall. How do you translate that into agile, where you may have product design occurring well into the design cycle well after you’ve originally done your first model or written your first data flow diagram or whatever, how do you translate it down into something that’s constantly changing?  

Paul Conngahan [00:15:57] Yeah, I mean, that is a great question. The techniques that we’ve used to handle that is to black box stuff, that’s a start. I mean, there is no silver bullet here. The threat model for an entire application in the modern day is a complex, large thing. And just as with anything agile is, you can only get there incrementally, right? So you have to, you know, focus on what is going on now, I think is probably what I would encourage. Yeah. You’ve got your stuff that’s already been built. Sure. But the point is to try and change the patterns for new things and change your way of working so that you don’t get into that. And eventually, over time, you’ll build up a larger model that represents every flaw in the system. But we still do it actually, when we’re taking teams through this, we say, through use cases, And actually bringing some security experts alongside the development team, the product team, to build a first state of flow diagram and threat model on certain use cases. So it might be logging in.  

And, you know, let’s think about it, I don’t know, a crypto wallet, for example, I want to buy some […unintelligible…], you know, or booking a holiday. I want to book a holiday, you know, something fairly basic that touches components across the architecture. And then we’re having powerful discussions about  […unintelligible…]. But just like the team is delivering in small increments and you know, you should threat model in small increments as well. You know, and I think that’s something that, you know, you can also add this to your check list. Well, give me a threat model and thus do we anticipate any significant interface changes. Not every change. It’s a threat(?) model update or threat model at all. But you know, you should have enough scale within your team to identify. And if I, I don’t know if we want to cross a trust boundary here, is there a reason for us to have this discussion?  

And, you know, and invariably all applications touch other applications and sometimes those applications are outside the org. Sometimes they’re inside the org even if there are inside the org, you know, that interface between two teams is where we want to say let’s stop and have a chat. And even if it’s one line between two components on one use case, you can start a really powerful discussion about what do we anticipate the threats might be here? The techniques that I would always use to not get bogged down, keep it quick, as the first thing you’re trying to do is brainstorm the facts right. Assess the controls against the threats afterwards, but take the power of collaboration with them to say, what are all the possible things that could go wrong here, as long as you’ve got someone there to seek some proper mindset? The makers, i.e: The people who are creating this stuff, they’re in a far better position to talk about, you know, what could possibly go wrong? I mean, we’re just there really, to help them think broadly about things that it might not naturally do. But yeah, I think, you know, to summarize breaking down threat model into smaller pieces. As we’ve got a big legacy piece, put it in a black box and just say, we’re not modeling this just now. We’re only modeling […unintelligible…] Model and then obviously pass unit actions when you’re doing sprint planning for example. Hey, does this feature team surely might need to implement training to get to the point where you do that, but usually people could find that work from with the team. For me, I mean, we trained teams how to do this in three three hour sessions conducted over the course of a week. That’s totally doable inside agile. So we can train them how to do it from zero. And i’m in a sprint. So why can’t they maintain the actual practice inside sprints. There’s no reason why they can’t. So yeah that’s what I would say. I think that. The reluctance because they over engineered in the head what’s necessary for it to be valuable. The truth is, if you can identify one interface, one use case, and one threat has been useful. You know, I’m not saying it’s, job done, and it’s to be continuously part of everyday work. 

Jonathan Coupal [00:20:20] Something is better than nothing.  

Paul Conngahan [00:20:23] For sure. You know. Exactly. And this is the reality. The reality is, most teams aren’t having these conversations all at the moment. And, that’s when I hear.  

Paul Gebel [00:20:32] My next question is a bit of a two parter. And you can answer it in whatever order feels right. First, it’s sort of zooming out. I’m curious, just as you’re called in to speak, both in governmental and in industry and certainly your client spaces, what’s been changing in the enterprise that’s different now, you know, over the past couple decades, what feels different in 2024 and then specifically kind of zooming back in from that question, most of the folks listening to this episode have product manager or product owner in their title in some way, shape or form, taking that context of how things are changing and where we’re at in the current landscape. What do you wish more product managers knew about security going into their conversations with their team?  

Paul Conngahan [00:21:14] Yeah, sure. I’ll go backwards on that one. Yeah. I think the first one’s a much more generic answer. You know, in terms of product managers, product owners, you know, one essential technique and I would appeal to our product managers, would be to speak with your agile coach or scrum master, whoever’s helping you on that delivery side, you know, make sure that you’re. Except there has to be capacity allocation for threats. That’s right. Now, a lot of teams don’t do this. They complain, you know, forever. Oh, we need to deliver feature value. The reality is, you know, when we find defects in software that’s tech debt. And I’ll take that in one form or another as potentially a security concern.  

So if I could only ask for one thing, it would be like, get 20% of your capacity on every sprint, protect that, commit to it and have one backlog. Prioritize all your features and all your bugs and tech debt and one backlog to fill the capacity allocation. Now for some teams that may be like, you know, okay, we need to put more focus on that. We’ll go 30 – 40%. Other teams might be saying I can’t afford that. I need to get more value. It needs to be 10%. I’m saying no than less than 10%. You’re probably just pretending in pretty much service to it. But ideally, if you could say 20% as two days of sprint, this should be doable, right? And actually that will have compound impact over time that will address these problems. You know, if we can get people in cyber to also accept those sorts of time steals and the fact that the security issue backlog is no more important than the feature value platform and both have to be addressed continuously over each increment, then we’ll win them, frankly. And that’s what I would ask for. I think that the biggest change, if we want to set up for decades, I think, you know, the adoption of agile and certainly some which is […unintelligible…]. But thinking about what’s the same. Right. The same thing for me is it’s all about people, right? You know, people get caught up in tools. They get caught up in tech. You know, they think that everyone that works tech has to be a software engineer, they’re on the command line and they’re spinning up servers, and which is not true. I believe that we still lack diversity, in the industry, cyber, probably more accuratley than tech, in general.  

You know, a lot of it has to do the misconception, right? So, you know, I believe in diversity of thought wholeheartedly. And, you know, I think we’re making progress, but there’s way more to the, you know, the insatiable thirst for people with tech talent was never led to them in the the 23 years I’ve been working, I don’t see it relenting anytime soon. I think if we can encourage more people from more diverse backgrounds to join the party, you know, it’s just so integrated into our daily lives that, you know, you don’t want to leave any innovation on the table by having a closed mindset. You want to have an open mindset. And as long as you’ve figured out the techniques to do those things well, I promise you good things will happen. All right. You know how many high performing teams before I was in cyber, I was a product manager myself. So I’ve done that stuff. I found nothing more satisfying, truly, than, you know, starting that journey with a team. Nobody knows each other. And you go through that process and then before long you’re like, we’re cooking with gas here, this has really taken off. It fills my soul, frankly, to go through those things.  

And actually it is all about people. People use software. People make software and people break software. So absolutely, it’s all about people and nothing to do with tech or tools.  

Paul Gebel [00:25:05] I can’t think of a better way to end the conversation like this. Just in closing, I’d love to turn it over to you, to point our listeners anywhere you think would be a benefit to your work at Riversafe, any of your writings. Where can folk find you and more information on this that you’d think would be inspirational to them?  

Paul Conngahan [00:25:21] Yeah, I mean, I’m on LinkedIn, thats sort of where my presecnece is. We are, you know, often doing press related stuff on there. You know, if anyone wants to talk, I’m a real human guy, so, you know, if people want to drop me a message on LinkedIn, I’ll be delighted to hear from them. We can arrange a call. We can head over to Riversafe.co. You can check out what we do at Riversafe. We work with household names. I’m sure people will recognize the sort of large enterprises that we work with over there. For me, it’s all about trying to collaborate as an industry and move the conversation forward and get to greater levels of sophistication. So if anyone wants to chat about that, I can chat forever.  

Paul Gebel [00:26:08] Well, it’s been a pleasure chatting with you today, Paul. I really appreciated the time. Your insights are really kind of taking this up to, Mount Everest and back into the Valley and made it all practical. So I really appreciate your perspective. Thanks for joining us.  

Paul Conngahan [00:26:22] Thank you very much, Paul. Thank you.  

Paul Gebel [00:26:26] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world just like you’re doing. Thanks everyone. We’ll see you next episode.