Effective Threat Modelling - Andrea Jones

Right. Well, thank you all for coming along today. Um, some of you may have heard a similar version of this at uh besides leads or steelcom, but uh personally myself, I I I listen to lots of talks over and over again because you pick something up you didn't see before um things you missed. But um anyway, I'm going to talk to you about effective threat modeling and at least uh how I've been applying it. um and hope it might be helpful to you and might explain some of the things in life as to why security is so hard. So um little bit about me. Um I'm a I'm pretty ancient. Um I was the first person in the country

to get a cattle passport electronically in the days before APIs or Google. So it kind of shows you how old I am. Um but yes uh been doing um information security mostly in the uh public sector for emergency services and things. Um but now I've gone into the private sector and I'm working for Sainsbur's. Um there'll be a slide at the end for our job site. We do recruit fairly regularly. So do keep an eye on that uh if you're looking for an opportunity. And um at work in sainsburries, threat modeling is something that we use a lot. Um and it's something that developers ask me to do with them to uh look at their infrastructures and find it

helpful. So I'm going to share with you um some of the way we do it. Uh and on Twitter if you want to get in touch afterwards. So, I'm sure when you've been looking around your estate, you see all this sort of thing, don't you? Um, your vulnerability scans are full of the same old same old stuff. Uh, your cloud security hubs that tell you all this best practice isn't being done unless you're using something that spots it and configures it the right way automatically for you. Uh, but some people worry that will break things. So, it's very hard to get the balance between both. Um, and your penetration tests are finding the same old thing

over and over again. Um, the trouble with this, although often these things don't actually immediately cause a problem, the more stuff you have vulnerable, the more chance probably that there's going to be something there that will get you breached, isn't there? Um, and the other thing is the alert fatigue because everybody gets so used to seeing these things that they start ignoring them and then when there's one that really should be looked at, it gets missed because it's buried in all the rubbish. Um, so this is some research recently by the cloud security alliance and their top issues for reach recent breaches. Um, one of them was this misconfiguration and inadequate change control. Uh, as well as all the other

things about insecure software development and the like. Um, and so, you know, that then shows itself out in those breaches where the most data is disclosed. This is this here are some of them. And you know, again, there's a lot of misconfiguration going on here that if people had done it right in the first place, um hopefully these things wouldn't have happened. And part of the problem is that when you set up um your infrastructure, especially in the cloud where you can just click a button and get something, it comes with all sorts of stuff that can make you more vulnerable and that you don't necessarily need the number of resources that when you set them up, you

know, give you a free public IP address and you've got to go to lots of extra effort to put firewalls in front of it or turn the IP dress off, you know, but by default that's what you get. Um, so you have to actually do a lot of digging and find out all these things and um what you need to uh remedy and uh this is a a meme that was uh pointed to me by my good friend Daniel Card who's doing the workshop this afternoon. Um and uh things that don't exist, threat models um and you know it is very easy um to not do it well. I'm not saying that I do it

well, but I think from what I've been finding it's getting better and something I'll talk to you about later um about this will hopefully demonstrate that. But you know with anything uh where we're doing a kind of compliance check it's very easy to find a few things that tick the boxes and say you're compliant but actually while doing that you've managed to leave an awful lot that really makes you non-compliant but you've got some things there that you can say yeah we're doing this we're doing this we're doing this but then there's a whole mass of other stuff that really makes that not very much use at all. So, the root cause of most technical

debt. Um, this is where I didn't get something out my bag. Let's see if I can find my propped my uh prop. Yes. So Jim. >> Yes. And >> so, if I offer you £500 now, >> Scottish or English? >> Um, these are euros actually. So ready for when you go into Europe. Um or or two thou five £500 now or £2,000 in um two years time. What you going to take? >> I'll take the 500, please. >> Everyone does that, right? I'm not giving it to you. >> Maybe later. I'll get >> anyway. Um it was useful having him here. >> Um but yes, everybody's like that even though they might think they're not. Now

this comes out of some research I did. Um I recently complete completed an MBA technology management and uh for my final dissertation uh it was on the technical and cultural issues uh around um difficulties in reducing cost in the cloud. And I surveyed our engineers to find out various things about why they didn't design things that were cheap to run in the long term. And in the end it came down to this, well, we just want to get it done. We just want to make something. As long as it works, we don't care. And it's funny because I was talking to one of our um supplier account managers just the other week and he told me that one of our

previous chief technology officers had said, "You either pay your tax at the beginning or you pay it at the end." So if you pay your tax at the beginning when you're designing things and you do it securely and you do it so it's going to save you money. Yes, it's a spike um but it's for a short term but then that long term the cost becomes a lot less. Whereas if you don't do that you're not paying your tax at the beginning and you're thinking yes it works and everything but then suddenly over the long term it just goes up and up and up. especially if you get a breach that then spikes the cost right up there.

So, this is an actual uh phenomenon, temporal tradeoffs. So, uh just think about that thing, the £500 now or the 2,000 in two years time. Everyone wants the £500 now. And that's what makes it so difficult. So, I think you really have to put things in people's faces and say to them, look, this is how you do it. do this and you'll be okay. Um, so threat modeling, this is the kind of process that uh it goes through. What are we building? What could go wrong with it? So if what we building, get yourself an architecture diagram or a data flow diagram at least. Um, then you look at what could go wrong particularly in those areas that are most vulnerable

to attack. And then you look at what controls you can put in place. and then look at whether you've done a good enough job. And also it's a good idea perhaps to come back and rethreat model things. I think Microsoft do their threat models on things about every six months. Um the tool I'm going to show you is Microsoft's tool and it's something that they do still use even though it's a bit out of date um and needs a lot of careful handling. Um so here's a data flow diagram and so we have various symbols for the different components within it. Um so external entities and things like the employee on the left are shown as a

rectangle. Processes are shown as circles and then we have um data stores which are shown as the two parallel lines. There's a link there if you uh want to and I have got a link to the slides at the end so if you want to download them later you can. Um and then those red dotted lines are the sorts of areas where an attack might cause an issue. Um and so that's where you can look at the various things that might go wrong in those places. And so to help you with that process there are various frameworks you can use. I'm not listing them all here, but this is just a sample of the kind of

ways um some of the main ones work. Um so stride, that's a pneummonic for spoofing tampering repudiation information disclosure, denial of service and elevation of privileges. And that is actually often a component of lots of other uh frameworks. those key attack sort of methods um are still within that. Um dread is more about measuring the potential impact. So that can be quite useful for the how bad would that be? So it could be useful for helping you prioritize what are the main things to concentrate on first in in fixing. And then pasta um is more involved and kind of involves a kind of more of a a red teaming process on your system and and actually

um physically trying out whether these attacks you've looked at um stand true. So there's the stride components I spoke about earlier. Uh so when you're counteracting mitigating those for spoofing you're looking for good authentication you're tampering you're looking for things that ensure integrity and uh repudiation that's often about logging and things you know so nobody can say weren't me mate um information disclosure so you're looking at encryption there to maintain confidentiality and then denial of service so availability so it's not just DOS that's the things like backups or um resilient um architecture where you've got failovers and things um and then elev elevation of privilege where you have to have authorization. Now when you're looking at particular

threats some of these things you can actually end up falling into two categories. So for instance if somebody steals a key from a key vault is that a spoofing issue or is that an information disclosure issue? Let's have a show of hands. Who thinks it's spoofing? Who thinks it's information disclosure? Yeah, it could be seen either way, but it doesn't really matter. This is just to help you look at what could go wrong, where you put things, you know, doesn't really matter. When I'm looking at things like, you know, a network not having enough controls over um ingress and egress, it could be an elevation of privilege. You could count it as that. You could also count it as tampering. Um

but as long as you kind of use this to help you think of these things um and uh just out of interest those trust boundaries I showed earlier um when you're looking at data flow diagram you tend to find that the various elements of stride don't all don't apply to all those uh different ele elements. So this can just be a helpful table to help you work out where you should be looking in each of those places. So there's dread. Um so the DR A damage potential reproducibility, exploitability, how many affected users and how easy is it to be detect detected. So by scoring those you can get yourself a kind of overall feel of

the how bad it is. And for those of you are pentesters, you might find this useful when writing reports. Um, if someone asks you, well, how bad is that vulnerability you found? Quite a nice framework for that as well. And then with pasta, um, process for attack simulation and threat analysis. So here you're actually go all the way through and then simulate some attacks and see what happens. So that's why it tends to be a bit more involved and more resource intensive really. Uh but I just put them there just to kind of um give you an overview of them. So famous old saying, there are no knowns. There are things we know we know. We also know there are

known unknowns. That is to say, we know there are some things we do not know. But there are also unknown unknowns. The ones we don't know, we don't know. Donald Romefell. And that's a problem when threat modeling because we're humans. Um, and that's why when we just leave people to build things themselves, they just do what they know off the top of their head. And I think that it kind of falls into this sort of um diagram. So our developers, they have their known knowns. So they know about how to do their standard encryption and that sort of thing and um SSO and things. They can do their secrets management maybe maybe not all the time but yeah they they

don't do know how to do it and that they should um but then um we get the uh known unknowns um and you know they're things we don't know what they are. We don't know what's going to blow up but we know there's a chance they'll happen. We can't do much about those. All we can do is configure things as well as we can. Um but you know look at previous events that have happened, keep our eyes open for things uh being published, you know, vulnerabilities in the software libraries you're using, that sort of thing. On the human error side, well putting in all those controls, as many controls and checks and balances as you

can to make so sure someone doesn't do something stupid. But these are the ones that I think are the most where the threat modeling can bring the most value, the unknown knowns. And so if you just tell a developer to go and build something, there's all those unknown knowns. There's all that good practice which is saying this is how you should configure this thing, but they don't know and they can't be bothered to go and look. So they just do their best and you know they're spinning something up. They're doing their Terraform. They see the options. So they set them to what they think is probably right, but they haven't gone to the kind of book of

words and found out, well, what's what does good look like? And then we've got our unknown unknowns. And yeah, that's the um the black swans, you know, uh the COVID 19s of the cyber world and things that just hit us out of nowhere, AI going mad and all that sort of thing probably in the future. Um, so I think the unknown knowns are the real problem. Uh, and a lot of that stride stuff I was talking about, a really good source of information for that is the kind of security baselines. If you're doing cloud development, then the Azure security baseline or the AWS config rules, they all give you that visibility into what's the good way to

set this up. And so what I do is I use the threat modeling tool and I set up templates to incorporate all that best best practice. And so for that um when you're doing that sort of thing here's some other things that you you could use. So uh your organization policies um like I was just saying there the best practice um miter capek is a nice nice one and if you have a look at Brett Crawley's austering.com blog he's got a really nice kind of tree structure there of capek and how you can relate it to stride. It's a brilliant resource. Um, and where you've had things gone wrong before, if you can build that into your

threat modeling, into a tool that's going to tell you you're using this resource, this has gone wrong before, make sure you do this, that can really help you as well. And then stuff from red teaming inhouse and what they find out, you know, bit like the pasta sort of uh um stuff. Um, and of course commercial tools. If you want to pay a lot, um you can get tools that will do this for you. Now, I'm just going to see if I can quickly uh do a demo. I'm not sure how I'm doing for time, but hopefully we'll have some time. So um you know what? It's gone messed up now. Presentation mode. Oh dear.

Oops. Sorry. I'm going to end the presentation and uh see if that what makes it easier. Right, there we are. Right, so um this is the threat modeling tool, Microsoft threat modeling tool. I'll put a link to it at the end. Um so I'm going to open up template here. This is just a fairly basic one. And um so what you have in here is you have stencils. So you can create your own icons to represent something. Um and within that you can also uh put some extra configurations and the likes. I've got Azure data factory there. Um, so I've set some properties where the user can choose what kind of services that's connected to and that might help me work

out are you using a self-hosted integration runtime which would then um pose extra um issues and things. Um then we have threat types. So these are organized under the headings of stride not in the stride order but um there we are. Um and so basically there you can say what sort of target have you got and um what could go wrong and how you might mitigate this. Now many of these here are ones Microsoft have provided for me but I add my own to them. Uh you can also configure this form. So I've configured it to add my own threat reference to help me kind of keep a database of them all. Um and uh

you could also do things like put links to policies or links to your um standards that you you follow and that sort of thing to help you u with those as well. Um so when you've made your template you can have a uh put a diagram in and uh so there was my data lake um storage. I haven't got the drop down on this one, but uh um sorry, the data factory. There we are. Um for some reason it's not showing here, but uh if I'd have applied that other template, I'd have had drop down here. Um there we are. Um so there's key volt. So I've got uh some settings there about what have you got set in the way

of your network access and that sort of thing. Then we can go into analysis view. we can see a nice uh list of all the threats it's found and we can export that to CSV and I do that and then I dduplicate them and uh use that as a list of for all the resources these are the things that you need to do and then going back to design view we go to report and create full report and there you can choose what to include including your custom fields if you've added any there and then when you've done that that's the sort of output that it does produce. Um, so you can have all kinds of things.

Um, I normally put nice hyperlinks in in mine as well, but there are issues with it because it goes absolutely mad about sanitizing h um any URLs you put in it. uh but with uh a bit of judicious find and replace you can remedy that and I think it's worth the effort. So let's see if we can get back to uh this now. There we go. Um so yeah, I find that's quite a nice tool. um is a good way of getting all that best practice in and bringing it out when it's needed and you can build on it as time goes on. So here's a few useful links um for some of the security baseline type of

information and also I've got the um miter capek um and austering uh stuff in there for you. And so by pulling things out of that and thinking, you know, how does that link to stride, you can um get them categorized and make some relevant threats around them. Um so the threat modeling manifesto has been created to kind of set out how threat modeling should be done. Um it but you know that it it it encourages you to use a kind of a team approach. Um, I know it's not always possible to get everybody around the table and, you know, work out what could go wrong, but I think even if you've got the best practice, it's a good start.

And even if you're a small organization, that can just help you to bring out those things you really should be looking at. And you know the way this has uh affected the area I work in. When I joined the organization, I was noticing lots of S3 buckets that were routinely not configured the best they could. They weren't actually totally vulnerable. Um because things said at account level were okay, but then below that wasn't quite so good. And I noticed from the names of these buckets that they were all created by the same Terraform platform. And then the engineers that were looking after it came to me and said, "We're going to rewrite this." And I was like,

"Yeah, my chance to get them all coming out nice and shiny." And that's when I really started applying all the best practice in the threat modeling and went to them said, "Right, when you're making your Terraform, make sure you've got these things here." And now when those S3 buckets come out, they're all shiny without fail and so much more secure. So secure that sometimes people moan they're too secure. Uh but that's how you know you've you've done the a good job. Um and so yeah, do have a look at the the threat modeling um manifesto um and consider whether you could start implementing something like the threat modeling tool to help you with that. Um, so some more useful u resources when

you're actually making the templates. Um, the tool itself there and uh say is very old, not very loved, not updated very much. I would say if you do use it, make sure you back your templates up to a separate folder. They tend to reside in your profile and every time the tool does get updated, it bl it blitzes them. So if you've customized the default template, it will get replaced with the old one and you'll lose all your changes. So do keep your template somewhere else. Um and the icons um very nice to be able to get hold of them from Azure and AWS. Makes life a lot easier. Also helps you know what actual

infrastructure is out there and what you need to add to your your list. So um I think that's everything. I'm happy to take any questions if anyone has in them apart from no you can't have my euros. Yes. >> Um a couple of points really. One, it' be good to get a show of hands to see if how many people do actually do threat practice. And secondly, >> um I used to do threat modeling for 30 products. So working across mock software teams. >> Yeah. >> One of the challenges was making sure you get actionable intelligence out of process. Like how you you managed to crack that nut and sort of persuade the developers this is a practice worth

doing that there are dividends and how did you how have you solved that problem? >> Well, as I say that when once they've seen the threat model output um on a project and then kind of worked with it as they're developing they then come to me with their next project and say will you threat model for this please? Um, also it's helped us kind of find things where maybe even our cloud provider isn't doing things the way they should. Um, so one was working with u machine learning stuff. Um, you know, I don't want you using um tokens anywhere with this with your storage. We should all be doing everything through managed identity and you know that sort of

thing. Uh however, Azure in the back end are still using SAS tokens in some particular places. Um and we you know we couldn't get around it but they actually came to me and said what are we going to do about this? Look it's not as it should be according to the threat modeling. Uh so it really does get them appreciating what's needed. Uh we even went with a preview feature. you know, there's a risk of using previews, but threat modeling, we'd come out with this, and they said, well, the only way we can do that is to plump in with their preview. And we thought, let's go for it. You know, it's a much better to try and do

the right thing. Um, so, you know, I' I found it's been very well received. Um, and yeah, uh, people they do act on it, particularly if you give them a spreadsheet of all the things that they need doing so that they've got a nice, uh, simple list of it all. Andrea, sorry, two questions. One, one about more business side of things at Sainsbury since the Marks and Spencers wipe out. Have you saw things differently as Sainsbury sitting up and taking notice of your type of area more than they were? Have you got more kind of like strength, more power to your elbow, more more money perhaps, more euros? And then the second question, what about secure by design? that

initiative that's telling vendors that everything should be locked down >> by default so that you have to make it insecure by almost deliberate action. >> Yeah. Um well, I say the the breach um you know it hasn't uh hasn't led to any more money or anything. No, I think security has always been something that's been appreciated. So that was uh you know it's good. It's it's not nice when it happens to anybody in your industry and you know we feel for everybody. Um but uh it's always good to have wake up calls and to have another look and review everything. Um and your other question by design. >> Yeah, secure by design. Yeah. Uh yeah, I

mean yes, it would be nice if vendors would make things more secure, but I mean a lot of how I see secure by design is doing the threat modeling and securing it as you're designing it because there's so much that a vendor they can't account for every way you're going to use a component. All right, hands up who who does threat modeling? Yeah. So probably about yeah probably about um I don't know 15% of you probably. Yeah. >> So uh great talk Andrea. What I what I'm interested to to understand and and hear how you overcome uh some push back from the business in terms of prioritizing threat monitoring within the engineering teams versus prioritizing initiatives with with go to

market and salesdriven monitor. How did you overcome that? >> Well, I think you know any business knows that if you're not secure then your bottom line gets hit when that gets breached. Um also uh what I was talking to you earlier about you see all these hordes of vulnerabilities often in many businesses they are still um something that's monitored and used for targets. Um so the business will still appreciate if they've g been given goals around security and um you know they they need to meet those and if you can help them do it with this sort of thing uh certainly I've been seeing in the accounts the findings in the accounts that have had threat modeling applied to

that that product um are hardly there at all. a few low and maybe the odd medium finding, but nothing that's standing out and saying it's horribly vulnerable. And by the way, the QR code there that has a link where you can download my slides and also there's some resources there from when I ran a workshop for Steelcon this year. So, you even got a little PDF manual that you can get hold of and a sample threat modeling template to get started with um and some other information. >> Just a follow-up question to the gentleman in front there um for privacy by design. Have you actually applied a combination of stride and lend together in order to actually enforce privacy by

design? >> Um I haven't yet. I'm still working through the basic stride stuff. There's a lot to do. Yes. Sorry, I'm very aware of timing. >> Um, where would you integrate it in an organization? The threat process because that's a little >> um you do it as part of your kind of project workflow. So at that stage where you've decided what you're going to build and you've got that basic diagram, you can then start your threat modeling. And I even find that um I might get someone who comes to me with a fairly basic diagram of how it looks and I do my best my do the threat modeling best as I can on that. Uh but then you know a

few weeks later and they've refined it and added some more stuff to it and so I go back and revisit it and redo it and you know uh update it. Um, but yeah, get it done before they actually start um really I mean they can they can start doing a bit of the building, but before they're moving it to production and everything else, you want to get in at that stage and and get it it built and then you can test it, do some penetration testing on it, make sure it's configured securely. Um, and then you you can go on to production. All right, >> Andy, a brilliant talk. Thank you so much. Thank you.