Striding Out To Prevent Misconfigurations

Thank you very much. Very interesting. I don't get think many people bother delving into my background for curiosity. Um well, you know, since uh you kind of ask and everything and that's a silly thing of me, isn't it? I didn't connect the kicker clicker. But there we go. Let's uh let's just use the good old keyboard. At least I've got a keyboard. I'm not that good at tech. Um so yes um well I'll tell you a few things you didn't find out about me then in that case. [gasps] Um so uh um bit about me. So I've been using computers since they came to be possible to be used in your house. Uh had a BBC Micro for my research project

at university where I'd studied chemistry. Um my dad brought home a research machines computer from BT when they were chucking it out. They had a 20 megabyte hard drive and two 10-in floppy discs. Um, and uh when I was um about 15, I used to go into school and uh we had a a pet computer and someone left the manual in the drawer. So I uh programmed a squash court game because it had all the memory locations for the screen in the in the manual and I was able to peek and poke the screen and things. So, uh, that's where my coding goes back to and Pascal on a mainframe at university. Uh, but no, I'm I'm not

really a very good programmer. Uh, I dabble in Python now. But, um, yeah, so done all sorts of things. Wired up coax um, networks. Um, and, uh, been doing information security ever since head of IT came to me, Microsoft Office trainer. uh I'm a bit of a geek at Excel and things as well and said uh we need someone to do our ISO 27,0001 and I then ended up scanning the network for MAC addresses and uh doing all sorts of PowerShell to find out what was on the computers and things and so [laughter] um got into infosc and uh then I was the only information security person for the fire service I I worked for um and that

was through W cry which fortunately our firewall kept us safe from um so yeah been through some interesting infosc days and things right through to the National Crime Agency ringing up and saying we've got one of your your employees passwords. [laughter] So um currently working for Sainsburries we're sponsoring this event but that has nothing to do with why I'm here because uh it was all kind of submitted independently and things but it's really nice as a sponsor to be able to come and speak to you. we do quite regularly hire for roles um and so we you know we do have some true entry level positions um if if you've got reasonable if you can

prove some ability um all the way up to internal pen testers and and everything. Um so keep your eye on sainsbur's jobs if you'd like to work for us. It's a very nice um c culture there. um everyone's very friendly and and supportive and um uh so recently I've been working a lot with cloud-based infrastructure so my talk will be biased towards that um we've been doing a big migration between two clouds and so uh I've been using my threat modeling technique um to do that and it's actually seems to have worked out pretty well really with um our final pen test results coming back with not much wrong with what's been built which It's always nice to see. Um, so I'm on

Twitter all about Cate. Um, these are my personal views in this presentation. And amongst my, um, other skills, um, I've got two blue Peter badges. I can artillery in artificially inseminate cows. So that's what AI means to me. Um, and um, I'm missing 3 cm of my brain. And that's the truth. And it probably explains a lot of what you'll hear from here anyway. If you think it's a bit mad, that explains it. Um, so misconfiguration, and I think you'll probably all see this in your organizations. Um, I see people on Twitter who are consultants for security advice and testing and support and things saying all over the place, people just don't do security very well.

And one of the ways we see this manifested is through our cloud security hub scans, our vulnerability scanners on prem, everything. Um, saying we've got these hordes of um, vulnerabilities. Um, our pen testers find the same sorts of bad flaws over and over again that people haven't fixed at an earlier stage. Um and you know we've got other areas in which there are weaknesses such as active directory and credentials exposed in various uh places. Um and the cloud security alliance recently published a report which showed um that these misconfigurations are often responsible for some of the big impacts uh big events that happen. And so while a lot of the time we're lucky and we get away with it, when

somebody does manage to get in through some method, uh that's it. It's game over because there's just so much opportunity to exploit everything. Um so those are the areas they particularly found um were poorly secured and some of those breaches that were linked to that. So these are the largest personal data disclosing um instance incidents that involve poor configuration. Um so again you know uh storage exposed in the cloud things that haven't been patched um just generally exposing things to the internet where people then can try and attack them and often unfortunately are unsuccessful. So, you know, it does matter. Although we may think a lot of these things are internal, the problem is that you may

not realize that actually something of it is external. And I think that's one of the problems with something that a tool where you've got to build your infrastructure in the cloud and then it'll tell you how bad it is cuz it's already built and it's already out there and could be accessible and being attacked. So you need to get that early stage and and work out um what you need to put in place. And the problem as well when we build a lot of these things in the cloud, our infrastructure has got vulnerabilities just from the moment you you set it up. you you set up some Azure storage and it comes with public access configured, you

know, public um internet access configured by default because it needs a kind of a um a DNS entry and everything. And you you've got to actively put those network controls in to block that access. And if people don't realize that, they just blindly think, I need some storage and they go and spin it up and they don't think about the implications of everything else around that. And there's all sorts of um other instances where things get public IPs by default. Why, you know, can't we put that on afterwards if we do really need it? Um the other problem as well, um the doomed temple of temporal tradeoffs. I wanted to make something that will make you remember this phrase.

Now, um, you know, uh, you know, if I say to you, do you want £50 now or £2,000 in two years time? What you going to take? >> You're very unusual. [laughter] Who would take £50 now? Hands up. Most people do. I I I don't think you're telling the truth. [laughter] I did some research at work. I was actually researching um the difficulties in getting people to build cost effective architecture. Um so often things are expensive to run because people have oversized their compute. They've not used the most cost effective storage. Um all sorts of things like that. Now if you put the effort in, you can build that cost effectiveness in from the start. So I

did a questionnaire and asked people about um how they built things and you know what um what challenges they had and what came out of it was we just want to get it built and we don't put the effort in to those extra things um that would make it cheaper to run. And I'm sure that's exactly the same thing with why we don't get security in. And you probably see it so much of life. The builder that comes to your house and does a job does the bare minimum. They could have gone that little bit further and you know solved another problem without much effort or done it so it would last a lot longer but they didn't.

Um, and then I mean I know they want more work, but you know if it causes you big problems, it's it's not really a very good way of doing it and then it damages their reputation. Everybody just wants to get the job done quickly and so they do things as quick as possible to get the desired effect and which is why most people will take the 50 quid because we get the instant gratification and I'm sure most of you would really if I offered you 50 quid cash in in the hand. Um, so threat modeling, >> so threat modeling, hopefully most of you have heard of it, but if you haven't, go and read up on

it. Look into uh some of the information on the net about it. Um, a process designed to try and help you work out how to secure things as you're building them. And so that it should be a cyclical process that goes round and round again like we've used probably lots of other areas of um information security. So we look at what we're building. We try and work out what could go wrong. We then put in controls to mitigate that. And then we look at does did that do a good enough job? And we go round again until we get to a point where we think we've done a good enough job. Because sometimes good enough is not putting

everything in place, but just enough to make it good enough. And there's frameworks out there that can help you with this. And I'm just introducing you to these now just so as go on the rest of the talk, you've um kind of got a feeling for them. They're ones you might want to go and look in into later. [clears throat] I'll explain more about the names um in a moment. Um so stride is quite good for a small organ organization when you're getting started. Uh looks at some kind of ob obvious categories of issues that could arise um and you try and identify things in those various categories at um various points in your architecture.

Um dread you can actually put some numbers to this. So you may want to work out how bad is this really. So, dread might be a method you could try in that case. And pasta, if you actually want to go on to doing attack simulations and things and actually um get even more mature in how you design your architecture, then that might be the the way for you to go. And maybe that might help you with designing infrastructures that you can use as standard patterns. And again, standard patterns are something that can greatly help in reducing our vulnerabilities. um because everything comes up the same. So stride the letters stand for um spoofing tampering repudiation

information disclosure, denial of service and elevation of privilege and I've got the various controls there that you would use. It is sometimes difficult though to classify problems as to which category they should sit in. Um I mean sometimes people add an LM onto the end of stride for lateral movement because if you don't have LM where do you put um lack of network segregation? Is it elevation of privilege because there's a sort of lack of authorization or is it a tampering sort of thing that the the network is not integrally sound? Uh malware uh vulnerabilities I think they probably would ought to come under tampering because again it's a bit of an integrity issue. Um, I don't think it

really matters too much about where something sits, [laughter] just that you've thought about this could go wrong. But I think it is easy to get hung out of where do I put that particular type of threat. Um dread. As I say, this is more quantitative. So you look at the damage potential, how much impact it would have, how easy you can reproduce this attack, uh how easy it is to exploit, how many users it would affect. That's quite a big one. Probably quite easy to measure for some things. Um and how easy it is to detect and dis to discover. And then um process for attack simulation and threat analysis, pasta. And so this is where

you work through the same sort of stride kind of thing of identifying the threats, but then you get into simulation um and more anal analysis of the the risk and impact. So I just put them out there for you um for a a kind of um uh description of those. And um when we're doing this sort of thing, we might use a data flow diagram like this to help us um analyze our threats. So we just draw our infrastructure out in a very simple way using symbols to represent external entities, processes and data stores and the like and then show how our data flows. And then what we do is we put um trust boundaries

um at the points where we think there's a potential that an attack could take place. So I put one there between my um out external user and uh sorry I'm not drawing very well to put my glasses on. Uh anyway, you get the idea. You you put this here. um where between our external user and my that's my an Azure data factory there and likewise I would put them also on the other information flows so you can do a very simple diagram even if you don't know exactly how your architecture will look um and you can do some basic threat modeling um that way the problem we have I think when we get round to threat modeling

is how we identify what could go wrong. And this is where I think we perhaps get into Rumsfeld's known knowns and unknown unknowns and the like. And so I had a think about this in the area of threat modeling. And I think no knowns developers often do appreciate things some of the things they should do because they do them day in day out. And maybe, you know, if they've been nagged about disclosing secrets or something, their secrets management gets better. And if they've built certain infrastructure of a certain type over and over again, they're probably very good at knowing what security should go in there. But then when they wander off into something new, they're perhaps um

not quite so aware. Um we then get uh the unknown knowns and these are the ones which I really think we need to work to try and surface and they're things like um the best practice that the cloud providers publish. So you go and look at their um document pages and kind of manual pages and you see all this information um on the baselines of how you should securely figure something. But how many developers actually go and search that out and look on it? Do they just build the thing and connect it and it works and job done? So it's an unknown known. We know full well what should be done but it's unknown because someone hasn't

bothered to look or doesn't even know to look perhaps. Then we get known unknowns. So an example of a known unknown is the result of an election. You know the election's going to happen. You just don't know what the results going to be. Um so we know new vulnerabilities are going to come out all the time. We perhaps know with [clears throat] some products more than others that a new vulnerability is going to come out. Uh, I won't mention any names or I'll get in trouble. Um, we know that humans make errors. Um, and perhaps there's things we can put in our system to help reduce that. But the fact is we need to have some sort of patching updating

mechanism in there so that when these things happen, we can deal with them. Um, and then the unknown unknowns, the black swans. Uh but if you've minimized all the rest, then hopefully you're getting less going on from them and when a black swan arrives, you're a little bit more able to deal with it. Now, there's a black swan going on at the moment because nobody knew that myself and Simon Painter were coming to this conference. We live about 20 miles apart. We were on the same module at Open University and we met each other while we were studying that back before COVID and we've randomly ended up miles away from home talking in the same

conference in the same slot. [laughter] If that isn't a black swan, don't know what is. So, um there you go. Black swans, they do happen. So um sources of inspiration when you're looking for those things you should do when you're doing your your threat modeling. Um, I mean, there's been suggestions of, you know, playing card games and uh, using those to remind you about stride, for instance, spoofing, tampering, looking at those categories. Those categories are useful to make you think, but it is so hard for those things to come in your mind. Um, so certainly the policies you have in your organization a very good place to go because they probably already mandate your password length, your

encryption that should you should use, etc., etc. Um, so that might be a few things in there that you can compare. The problem is wading through them and finding those particular nuggets. So maybe pulling them out of a pol of the policies could be useful. Um then this best practice that I've been talking about and say this is where I've really been seeing the benefits because I've taken the infrastructure components my engineers have been using and I've trled through the best practice. There are places where you can sometimes find summaries of of some of the um high level ones that are obvious to apply. Um but I've I've trled through those and then put them into my tool so that I can

um easily bring them out in an architecture diagram and tell people this is what you need to put in place. And that's worked well because those things have then ended up in place. We've had chats about them in standups when there's been issues in implementing them and then uh in the end it's all been resolved and it's gone in place and everyone's happy and we've got better secured infrastructure. Um, MITER Capeek is a nice one and um, particular uh, Brett Crawley's mapping of that to stride. Um, on the last slide I've got some links for you uh, of where that information can be found and I'll show you a diagram of it in a moment. Um

but that can maps the um common weakness uh categories um to stride to then help you when you're going through spoofing. How does spoofing happen in real life? And you know and I because that is all based on previous incidents. I put previous incidents there because as an organization if you have incidents happen it's a good opportunity to grab that knowledge and build it into some central information of when you build this make sure you don't do that. Um, if you've got the luxury of the resources, in-house red teams and the like might come in and help look at your own infrastructure and say, "This is how I would attack it." Um, and give you

some ideas um of what they particularly go for. And then of course, if you've got deep pockets, you can pay for commercial tools which might have done a lot of the hard work for you. But I'm basing this on things that um don't cost you any money. So, I'm just going to go now into uh an example. This is Microsoft's free threat modeling tool, and you can configure it to make your own templates and put threats in in any form you want. You can also add as much information as you like. So if you want to map to ISO 27,01 or map to your internal policies or something like that, you could do for each threat and

that would then help provide a report that tells you why this is an issue um and what kind of standards it breaches. Legislation would be another one as well, wouldn't it? This is required by legislation. Um, so we got there, um, a data factory with some storage and, uh, a key vault. And I bet I forgot to open up. Yes, I'm going to put my glasses on a mate because I did not, um, open up my, um, report from that, which I wanted to show you. So um coming out of that, we can get a an HTML report.

There we go. There's the sample. Right. There we are. So, there's a sample report. Cleaned it up a little bit. One of the one of the headaches with the Microsoft threat modeling tool. Say it's free, but free comes at a price inevitably. it gets rather um anal about sanitizing everything and [clears throat] so it turns every amperand into an amperand amp semicolon um after it's turned HTML into amperand and uh symbol codes and things. So uh you do have to go through and clean it up but I I think it's a small price to pay. Um otherwise it's quite a nice tool. So um there we are. You get the kind of output it produces for each um

part of the diagram. um and tells you the kind of things that can go wrong with default configuration. You can actually put um some uh options on your infrastructure to say what you've got in place and so you can then put conditions in so that if this is in place don't tell them it's not secure. Um so that's how that works.

There we go. If I minimize that, should be able to get the thing I had back before. And there you are. That's Brett Hallow's [clears throat] um mapping of stride to the C.WE. So, it's quite nice how they're broken down under the various categories um to help you with that kind of um inspiration point.

So, um, if you want to get deeper into threat modeling, as I say, go and look on the web. There's lots of information about it, and some of the links, um, you'll have in a moment will give you, uh, some good places you can go. Um, but hopefully from what I've been describing so far, uh, you'll see how this fits in with some of the elements. This isn't the full manifesto. It's just a few that I've pulled out. Um but yeah that that culture of finding and fixing issues the repeatability I think if you're taking the best practice that does give you the repeatability because you can bring it out every time that resource is used and

it will come out with the same advice hopefully. Um and you know the the thoroughess um you've got that uh knowledge built into the the tool to help you with that. Um and uh following your design changes, you can put a new design into your tool and come out with a new report based on anything that's changed. Um the early frequency analysis, I think, is something that as you mature, hopefully you do this more and more and uh you keep um updating your information on what can go wrong u so that you can account for anything new that might happen. So there are some useful links for you. Um I've got some AWS and Azure based uh

sources of information because I imagine they're things that a lot of us use. Uh but also some other threat modeling information outside of that. Uh so I I hope that might be some use to you. Go if you want a free tool to play with, go and get the the threat modeling tool and have a try with it. Um, but you will find that the templates that come with it are very old. Uh, it's been unloved for a long time, unfortunately. And, um, but if you want to build your own templates, it's a very easy thing to put your own information into. Does anyone have any questions for my last couple of minutes? Stunned you silence.

>> There's a lot. >> Trust you. >> Observational question. My understanding was stride was more about the design process and thread was more about tracking bugs. So when you get a bug report in that's where that discoverability because it's how easy is it for students to find that bug and then what's the >> Yeah. Yeah. Yeah, I suppose it's true that still those frameworks could be applied in different situations and will fit different situations better. But again, they're just frameworks. They're just there, you know, to help you with it. And as I say, you know, although stride may help you, as I say, also going to the best practice, I think gets in some of that stuff which because of

the temporal tradeoffs don't get picked up and don't get done, but could be done so easily, right? How do you ensure the evolution of best practice across organization? >> Um still in early stages and you know it's something I I think partly through your measuring and monitoring because if you're then still seeing the vulnerabilities you'll see the the vulnerabilities more in the areas where this process hasn't been done so thoroughly. Um and so then it starts to become more apparent. um that there's an issue in that area and then you can work on getting the process more into those areas and and getting the better results. Yeah. >> Have you any tips how you could organize

sometimes?

>> Yeah. Um well as I say if you get that opportunity to get the kind of low-level design of the architecture just try and get hold of it and try and do some threat modeling and present the results and then say look you build these things in you'll make it more secure than it might have otherwise been um and you know see where you go from there as a start um I think sometimes although threat modeling they often talk about get a group of people to do it. But if you've got some information, doing something is better than doing nothing. >> Start small. >> Yeah, start small. >> Yeah, we'll have to call it the next

speaker and go grab Andrea afterwards and we'll have the next speaker. >> [applause]