Bridging The Gap: Design And Ops Assemble - Paul Spruce

need any microphones. So for the next I'm going to stop watching for the next half hour or so although it's 50 minutes not really taking that long. I'm going to talk to you about design and operational teams not working together and actually what we can do when we actually work together. Okay. So a little bit about me then. I've worked in the predominantly the telecommunications industry for around about 22 years plus um in the milit sector and in the public sector. So the presentation before around the RF radios like I remember some stuff like that and it got quite uh nostalgic. Um I predominantly now work in the design area of security fundamentally around threat modeling.

Um, as it says on there outside, you may have noticed that I have slight loot in my accent. I'm not from England. I live in Aruri National Park in Snowia. Yes, it was a long drive this morning. And yes, I left at 4:00 to get here, but I'm here. I'm a proud military veteran. Um, an averageish ultr runner, and I co-host a podcast outside doing everything else. But we're not here today to talk about me. Thankfully, so our show of hands, who here is within a design space? So what I mean by design space is like your architects, your app builders in dev sec ops, anything like that. Who's in design space? Cool. Yeah. Okay, we've got an issue. I like that.

Okay. Who's in ops then? What I mean by ops is red team, blue team, IMC, uh, anything like that. Cool. And who's in other? So others have GRC like where I kind of sit right thatish bit. Yeah. So quick question. Do you guys talk to each other regularly? Probably not. Some may some. Okay. So that's what we're going to come go have a look at today. But firstly we're going to look at two roles specifically. Design role right and operational role. So if you're not familiar what design security do and what their roles are fundamentally they are there to make sure secure is uh security is embedded right at the beginning of the design of the section

of the idea want to build an application we want to build it successfully and securely there they run along a lot of range of secure by design principles or secure by default or make sure that stuff is secure as possible before it goes out of production. They also look at the fundamentals of your architecture and they build and they put stuff places and everything like that. Build it out. That's what they're there for. It's great. Normally they gather dust in the corner because we don't get spoke to very often. We kind of get rolled out. We build something then we kind of get kicked back in the hood. But that's what we kind of fundamentally

do. And then you got these guys, the shiny guys, right? The operational guys, these are you protectors, you attack us in some cases, right? These are people that protect our front line with the shield. They are investigating their threat hunting intelligence. There are teams when stuff go wrong, right? There are incident management teams. These are shiny guys. All right? And the the issue that we have is we both do the same thing. So the mission so what do we think and now this is a stupid question to a very intelligent audience. What do we think the mission is of these two teams? Do you think they've got the same mission first? >> Some say yes, some say no. Okay.

Who says they have a different mission? Do you care to allow [Music] why why you think have a different mission to design?

>> Not found at all in the back. Okay. Who thinks that they are on the same mission fundamentally? Okay. So what does security do? They build securely. What does operation security do? They protect predominantly, right? We both have I my honest opinion, we both have the same mission, right? Which is to protect at fundamental level, right? Design security. go there and say we want to build this properly so that touch work nothing happens if something happens right and operational security there you know cream in the hair all gelled looking cool as anything swore thank god I didn't um because they're protecting us as well but we're better part no you know we have operation security over here doing

their fantastic stuff getting absolutely hammered every single day from vulnerabilities to people just attacking you all the time. And you got design security over here in that dusty closet like I said building stuff and architecture is like absolutely mega brains going we can do this and can we do that but we're better apart. We've always done this. We've heard this probably heard this in security. Yeah, but we've always done it this way. So therefore it works right. Well, I want to challenge that today and tell you that there's better ways when we collaborate. Now, as part of anyone's ecosystem environment, all right, we we tend to protect one thing or we tend to look at one thing at a

really high level, which is our attack service. Right? When we design it, when we build it out, we want to know how big the estate is. And from an operational point of view, we want to know how bad big is so we can see where we need to put our sort of towers, turrets, ring mains, snipers, whatever you want to call them, right? Those outer edge protections. So could collaboration actually be part of our attack surface? Well, it could be because if you don't collaborate, then there's a an attack vector there of kind of like miscommunication. So then there's delayed response. If design knows something that could be fed up to operations earlier, then it's

it helps that incident change. They get up to speed a lot quicker. It's the same with operations. If they have something of an operational nature that they're seeing day in and day out, that's going to be fundamental for people in design area. So we can start design and building more securely moving forward. So collaboration have a thing. Is that part of your attack? Is that something that we're actually neglecting? Why collaboration matters? play. You've probably heard the approach or heard the phrase siloed security or siloed teams in general. All right, in most businesses, you'll have six teams doing the same task slightly different way and they all think they've done the same thing. It's the best thing since

sliced bread. I do it better than yours cuz mine has a shiny badge on it or I do. Fundamentally, you're doing the same thing, right? It's all about style approaches. Now, why collaboration matters is because you break down that you break down that side of the push specifically between ops and design. Now, I'm not about getting in each other's pockets here, but there is an element of understanding what each others does. So, what happens if you don't? Well, we're at where we are now in by and large, right? So we have operations doing really cool stuff protecting us and then we have design people building stuff sometimes unfortunately pushing stuff out into production that's could have been could

have been had a look at from a from an operational point of view first we're putting chilling out there because from a design perspective yeah there's a gap there that's what we think but what we're not doing is speak to operations and going right you guys know where we're getting hit where we're getting popped what the intel is like what our past incident data is. Where should we put this tool? And they go put it over here. We're going to put it over here. There's no point because we've got X, Y, and Z in place there. Oh, okay. Brilliant. All right. So, having that talk and collaboration just on little things like that helps us understand our

weak points are from a time perspective, but also from an operational perspective, how the architecture lands. And if we don't collaborate, we're going to miss these little tricks and hints and tips. What you'll notice just a side here throughout my slides in fact chasing dogs. Okay. So, there'll be dogs, little happy happy dogs, right? So, the benefits of cross team collaboration. Okay. This is kind of like common sense. Why do we talk? Why do we talk to each other's team? Why do we do this? Right? Share information. The more knowledge we know, the better we are at protecting from a design perspective and from an operational perspective, it makes sense. So how can it work? So there's two

aspects to this. There is what can design give to operations and what can operations give to design. So we'll start with design first. What can design do? What can we do to help operations run us out of that dusty closet? Shake us off and make us get the real cream in our my hair obviously in our hair to make us all shiny and new. So the first thing we can do really simply start talking. All right, have that person have that keynote. Have your principal architect speak to principal in security or even someone that's in INT or someone that's inside. Hi, I'm Paul. I'm from secure by design. This is what we do. Ah, that's

interesting. This is how we can help you and this is how definitely you can help us have that conversation. Start having a conversation. It starts building. starts building and we start building what is called which we go on to in a bit cross cross team champions. So the first thing design people do or what we should do is a thing around collaborative threat modeling. So just by show hands people know what threat modeling is say yes put your hand up no if you don't. Okay so there's a mixture of experience and knowledge around what threat modeling is. So I'm just going to go really really high level of what threat modeling is. Threat modeling is a

process at a design phase where you highlight threats or something cause harm against a thing, right? Whatever you're looking at. This could be an application. It could be all the way right the way through to a whole environment SAS or a whole infrastructure. Right? Once you've got this massive list of threats, you go right need to put some mations in place. What can we put in place to either eliminate that threat completely or if a threat is realized limit limit the damage damage limitation and that's what threat modeling is. Another way you can think about it that some design people use and some red team absolutely hated using this is like a logical pentest. All right, it's a way

of doing a pent test at the design phase. We're not actually pentesting. What we're doing is we have our crystal balls and we try and think to the future and we try and think where threats could happen against the thing that we design. That's what threat modeling is and it's through the design phase predominantly. If you get multiple stakeholders involved in threat modeling in general, okay, you get more people, more lenses, more different approaches on it. So if you're doing threat modeling now and it's just within a design community, you need to open the doors and get other people there. So get your operational teams in there. Get even people from HR from there, right?

Cuz they will bring a different lens on it from whatever you're deal building. It all depends on context. But bringing operational bringing operational teams in does two things. One, it allows them from a really high level to understand how the designers and design security go about their day-to-day. So they're able to understand our network at high level but from an architectural level. Right? From from a design point, we could highlight these threats and they can either challenge them, debunk them or go, we've got another 18 threats we can put on here based upon what we know. That's really good because in the design phase then we can go let's take all these we haven't got to worry about when

it goes into production. So bring them in early doors. What OP can do for design brings us in on security reviews. So P so post instrument reviews get designers in at that stage. Okay. What went wrong? Okay. We got hopped by this this actor there using this method against this system and this was the vulnerability. Why? Oh, because we didn't have X Y and Zed control in place. Is that people? Uh uh yeah. Okay. Now we know now we know next time that that's a prevalent attack vector. That's a prevalent threat. Let's start. Now next time we build this cloud platform, we build this application. We need to ensure that control A and C is now in

place. Not just A and B. architectural decisions. Architectural decisions I'll go on to in a little bit. Bring ops in on them as well. Talk a little bit about before about positioning of tooling and things like that. Build cross team champions. Um I don't particularly like the world champions but just build across team person people like points of contact that can cross that bridge that can make that gap that can make that communication because if you all start shouting each other straight away it's going to be no one's going to listen to each other. So you speak you get that in the initial phases you start getting that collaboration through a couple of people I speak to IMT I'll speak to

Intel I'll speak to the team I'll speak to what I'll speak to and then you share information that way feedback loops feedback loops is massive okay what we find in design if you back up to operations things like hey operations we've got this new cloud platform going online in 3 days. It's full of vulnerabilities, by the way. There you go. Or we go, "Hey, discovery, guess what? We've just found in the data center. We've just found four racks of shadow it. Have fun. Knock yourself out." Right? What we do there is we're giving them early warnings of things, right? So then they're not starting from scratch. They can understand that. They can go, "All right, okay. We've got vulnerabilities

here. What controls are in place? Okay. Do we need to add any more logging and monitoring requirements specifically around this? Okay, let's start building on that operations feeding to us. Hey, Mr. Design people, we just had this whole new threat brief come in that threat after a is now attacking CRM systems with a particular threat using this particular technique. Uh, and they're going and this control doesn't affect it. You need to put this control in place. Awesome. The thanks that gets spread out through design community we start building anyone to work on CR systems start ultimately sharing is caring right share data share information share our own methodologies all right if they can understand what

design people do and we can understand from a high level what they do particularly threat hunters all right and people do threat detection we from a design level um if we can understand how they work through things it also gives us that little bit of an edge to go how I designed this going to be slightly different because I'm going to look at it a little bit different way so we share our secure by design methodologies so I've already touched a bit on this about roing operation teams in to start basically hey guys this is what we do this is what we look at this is how do it when you're going about your day-to-day job. How you could do it.

Now, particularly threat modeling as part of a skill by design methodology is a really good tool um to not only help things like threat hunting playbooks, but also informing logging and monitoring use cases within scenes and socks, but also you could actually use it to scope pendests, providing there's a caveat here, providing that the model is of detailed Right? You can't just go, "Yeah, I found X, Y, and Z threat. There you go. Pentest go for that." But you can use that type of um information to be able to help scope a pent the architectural decision I was on about before. Bring them in. We've got this new shiny tool we've just bought off this vendor. It's cost us 8 gillion

pound. It's military grade. All right. We always hear that word, right? It's quantum based. Okay. It does best things. Yeah, whatever. Okay, where do we need to put it? Oh, we need to put it here. Are you sure? Hey, we right. I know what I'm doing. I I was here when like Windows was invented. I know exactly what it is. It's going here. Well, actually, from an architectural point of view, that may make sense, but from a security point of view, we need to come to a balance here because that's that's dead space. No one looks there. Like, it's even actually segregated. So, it's absolutely pointless. Let's move over here. and you have that collaborative conversation around where

we allocate our specific resources from a security and operational perspective. the two more than anything design risks. You've got secure by design team. We're looking at these designs, architectures, this design security. We find an absolutely horrendous risk or threat, but the business are gone. We need to go live Monday. We don't care. We'll push ahead. Okay. We feed that back up. We feed him. We make operations as part of the design escalation chain. So then we can also go to the business as I'm busting off my dust to say I'm security. They look at me and go whatever. Mr. Guy comes in shiny green. Hey that's not happening. Okay operation point of view we will be

absolutely dead in the water. So bring them in on that escalation. It helps articulate the risk better to the business if we have both parties working together. So that's what design can give to operations. We're sharing, right? It's great. What can ops give to us? Well, we have operational data from a design perspective is absolutely fundamentally key specifically from a threat modeling or specifically when we are architecturally building or designing anything threat intelligence. Now, you'd like to hope that most businesses have some sort of threat intelligence rapper, whether that is an embedded team in large organizations where they have their own socks or seams or whether that is uh outsourced to a third party where

they're able to feed intel in. But that intelligence is is absolutely key because that gives us real time data, real time dynamic data to understand where the actual real threat is from a design perspective. So let's utilize that data past incident data. Now when we're designing and building if we understand what's gone on before what's been blocked before what is dangerous what is not either at a industry level sector level business level or even a device level or application level that's really good it's good for us in design we can go actually yeah we've been ding this all wrong for the last 15 years we need to do this and understanding our past in data what went wrong. All right. Enables

us to build securely move forward for actors of interest. Scary this guy, right? Never trust little dogs. If you've got little dogs, I apologize. Don't trust little dogs. Um, if we understand who's actually attacking us, what we're building, uh, we can also understand what extra controls we have in place. Let's say we are building a application for a oil company right that has its own lane of specific threat actors that may want to attack that application over others. So you'll have your geopolitical or your hackists that may want to go for that as opposed over to your script kitties that won't really bother with it, right? So they have different TTPs how they attack it and then if you understand

that you'll be able to put different controls in place or added controls in place based upon what we're building, based upon what you're attacking your industry, your sector, your business, the application. So what happens if you roll all this data? Well, you'll have this data of sorts. Okay, because especially actors of interest and intel cuz nine times out of 10 it's open source, right? In date, you may not, but if you're outsourcing it, I would like to think you've got some sort of incident around the business you work in because if stuff goes wrong, right, who you going to call? Not Ghostbusters, right? Who you going to actually call? He going to come in and save you.

They'll have that later. How will help though? Just Paul, you've been talking for the last 25 minutes. Really boring. All right. About sharing data, but how does it actually work in practice? Well, from an operations design point of view, it gives us real time updates when we're dining. Check in. Okay, I'm just putting this in place. What does it say? Don't put that in place because we're really vulnerable, please. Okay, cool. It gives us an enhanced threat prioritization. Really fun, long, complicated way of saying what to look at first. All right, you have a threat over here, which is oh my days, the world's going to end if this happens. And you have a little

threat over here, which nah, it's fine. But what you find is the controls over here mean that never happened. No controls over here. here and this how they get it. Nine times out of 10 devices get popped. Firewalls not being configured correctly and everyone the data the data is not encrypted. Cryptography is the last line of guys. Come on your data they've got through loads of gates loads of walls by past everything to get to that data. Start at the outer edge. Start moving our way in. So what may be on fire over here in your head is actually you need to look out here. And that's why threat prioritization is mastered. This is why

we use the operational data to understand which of these threats uh lay in against your business or device or the sector or your industry. It gives us a bit of a motivation and tactic that help us make the design. So this goes back to the threat actor's point of view. If we know what we're building and designing, have a think okay who would want to cause this harm? Who would want actually attack? Do we need to approach our security control deployment a little bit different a little bit differently depending on we have data driven insight so incident data so there's a difference between threat intelligence and incident data threat intelligence is it might happen incident data is it has happened it's

concrete right there's no go back there no it's fact right it is it has happened so we can utilize that concrete evidence to make better design design decisions moving forward. Again, say anything today, collaboration feedback loop, it's it's held in that feedback loop. What can design do? All the data that we're kicking over the fence to operations. Well, it allows us to understand detection capability resourcing or just resourcing in general around security tooling. It helps us provide uh off the back of threat modeling potential login and monitoring use cases. Okay, we have this threat over here. We've got this control. However, if this control fails, all right, you need to look this, this, and this based

on X, Y, and Z. It gives operations an understanding of your estate from an architectural point of view because they don't really see it from an architectural point of view. They look at it and go, "What's pop? Where's that? Who's in charge of that? There we go. Who do I need to speak to? All right. If they kind of understand like cloud team or over here, okay, we're going to cloud. It's highlighting the poor designs. So discovery do this. If you have a discovery function, discovery by and large go out and look for vulnerabilities within your live network, right? They can feed that back in and say, uh, we found this big hole that you pushed out six weeks ago and

you said it was really good. and we're going okay yeah no worries we'll take that back take that away we'll take that learning away yeah okay that's no problem and we give them early onsight of any escalations at all so anything that we think design perspective is going to cause us harm operations need to know about it what this does is if we're pushing out I mean ideally you want to push everything out as securely possible. But sometimes that's not that's not possible. Business needs, you know, you uh you mentioned it before, if you put too much stuff in place, people just going to go around and bypass it and things like that. Put enough in place to get out the door,

make it as possible. But if we find something in design, we make operations straight away. Like it just makes sense because if that does get popped then starting from zero from information zero at the height of 100% of the incident starting at a level they go yeah exactly design told us about this here's the threat model to it right okay does that correspond how we actually got popped no it doesn't okay there's learnings there we can feed that back into design or feed that back into our YP process so key takeaways the days of siloed security it needs to change. I mean it may not be the case in your business but by and large that there is still silo security

right and that needs change and collaboration it's just one factor of that collaboration is definitely part of your attack surface right it is part of your attack surface if we're not collaborating we're missing a trick all right so start talking collaboration is not only essential all right but it's also are strategic. You have to know that's the end. All right. In summary, what I've gone through here is kind of makes sense, right? You might think that's just all nonsense for the last half hour. We talk to each other. And if that's the case, awesome. I met a room full of 15, 20 people that all do that. Great. My job's done. Still worth five and a half hour

drive here, by the way. All right. So, but I would like to have a guess that's probably not. Okay. So, collaboration is key. The sharing of those little data sets. All right. You utilizing specifically operations lend more into this than design to be fair. The more operational data you get into design security early on, the better, the more equipped we are to design more securely with relevant, timely, accurate threat data. Otherwise, we're going I've done it always this way and this is how I've developed from the last 30 odd years. Yeah, we're not looking at what's relevant now. All right, we need to start looking relevant now. Especially how threats are evolving, how new technologies are are being evolved.

Okay, I don't class AI as a new technology. It's been around for donkeys. All right, but things like quantum, probably not going to see it in our lifetime, right? We're probably not going to see it in in an operational capacity in our lifetime. Um, but it's still something that's being developed and like that could just that's absolute game changer that is like rip up the rule book. Where do we start with cavemen, right? >> Thank you for your time. Is there any question? >> Yes. >> Um, so with the talking to each other, how do you prevent the other teams becoming the enemy so to speak? So they just become the people that give you

more work to do by talking to them. >> Uh can you give us an example? >> Uh so like I used to talk to de about you see these security issues and they turn around and say oh you fix them but they didn't actually fix them just your way. >> Okay. So that that's different sort of um angle. So what that tells me is that's poor business behavior. That's poor behavior on those debts. Um what that should go around is it should be we should that should be highlighted up to business and going from a security perspective we're telling them to look at this than actually doing it like get house in order. Okay. How do we stop

from being the enemy? Well, you you need to go there with kind of mindset what I've just said there right? >> The benefits there's no con. I can't see and I I I do this dayto-day in my in my working life. Now, I can't see any cons with not sharing of this data because it helps us design better and operationally from a design perspective. Again, it allows us to understand what's actually going out there. Allows us to open these curtains here, look out the dusty wardrobe and go daylight. Happy days. We understand what's going outside. So, it's going to conversations with operations or I'm design generally it's better to go to the design side or either and go, I've got

this set of data sets here. I think it can help you and start from there. start building. They explain why. Oh, well, if we knew what was happening site, we knew that we'd need to put locks on the door or we need to put fences or we need if we knew that at 3:00 on a Friday afternoon the absolute street gets packed out there, we kind of need to put some sort of lane system in place so then we can move freely and access can be in and out as opposed to just closing the road. Okay, that that makes sense. Okay. So, it's going there with the benefits of understanding the data you want need

because you may not need the intel but understanding they have data sets that key to help us with design. We have data or information that is key to give them early in their warning system within operation from a design perspect. >> Yeah. >> Yes. work >> 100% >> very much. >> Yeah. >> So, and again I don't I really don't like to put people in this camp right but I see design security as proactive and I see operational security as re reactive but but we are shifting a little bit better to proactive and reactive in the operational space. Right? So if we can give them more data, more information to get them to look more proactively things like Intel

tippers, right? What would that looks like? Like getting design involved into exercises, your your tabletop exercises, get design involved at that point as well. All right, makes sense. They understand infrastructure. So you get load of applications and you get a debt that goes, "Yeah, I'd be this way, this way, this way." And the red team and blue team like okay never thought of that way. Well not so much the red team because they're absolutely fine. I'll lselves and do whatever they want. No offense to any red teams in but you know just do what you want teams you know protecting it. So it is about giving them that heads up. It is about giving that putting the

work in now to then prevent any pinch points or pain points moving forward. any others. >> Yeah, I'm in a place where design team does a good job feeding detective team. >> Yeah, >> the op team does a good job of feeding vulnerabilities back design. >> Yeah, >> that's one of the things you point out the design team are not doing a great job of feeling vulnerabilities in design. [Music] how you can opt an escalation plan. Okay, you find a design risk. >> All right, ops are part of that escalation, right? Normally you find a design risk and you go, "Yep, design's a big hole in here over here." And what kind of tends to happen is that go

through the motions and the business go, "Yeah, all right. Okay, just hand it to the risk lead. they'll sort it out and never gets done. 6 years later we get popped from the same vulnerability picked up from design. So we found is if we get operations in at that point okay they're aware and then we can then talk to business and understand from a business perspective why you go ahead with that do you understand the risk firstly right don't just sign off and if they go no actually we need to push ahead operators are aware of it at that point so they go so they go discovery this is coming our way right when it

comes in here mitigations and here's the timeline specifically the design give the business to put this mitigation in place. So we can then go and verify that through operations to go actually why haven't we put this in yet? >> So really those risky events. >> Yeah. So I would say initially a a a risk escalation layer is really easy to slot them in and then build upon that. All right. And you could have some automation pipelines depending on where models go or where your design goes where it sends off a ticket to their system. It flags up on a systemah, right? All depends on how automated you want to do and how quickly. But the

simplistic thing is talk get them into an escalation process of somewhere. >> Any more for anymore? Brilliant. Thank you very much.