[00:06.200 --> 00:06.720]  Great.
[00:08.640 --> 00:13.140]  So, I'm here to talk about threat modeling and security test planning.
[00:13.520 --> 00:18.360]  So, a little bit of background about me very briefly before we get started in the real, what you're actually here for.
[00:18.660 --> 00:22.680]  I've been a commercial security consultant for about a decade, give or take.
[00:23.820 --> 00:37.940]  And specifically what I've spent a lot of my time on in that decade is research into threat modeling and understanding kind of how the practice of security works and how that works within organizations.
[00:38.420 --> 00:44.480]  And lately I've been getting out of the commercial world and into kind of the NGO and security for high-risk users world.
[00:44.880 --> 00:49.220]  And this talk will be informed by both of those perspectives.
[00:50.460 --> 00:54.200]  So, I don't know how many in the room... can I just get a show of hands?
[00:54.200 --> 00:57.120]  How many people here understand what a security life cycle is?
[00:57.640 --> 00:58.700]  It's not one of those.
[00:59.560 --> 01:00.000]  Okay.
[01:00.200 --> 01:01.200]  So, not very many people.
[01:02.360 --> 01:05.000]  We'll go into this in more depth later on.
[01:05.120 --> 01:17.960]  But the security life cycle is basically how you go through requirements, architecture, development, test, and deployment, and deal with all of the security implications that each one of those phases has.
[01:18.200 --> 01:20.800]  And it's the same if you're an agile or waterfall or whatever.
[01:20.940 --> 01:21.700]  It doesn't make any difference.
[01:21.900 --> 01:23.740]  You still have the same tasks to do.
[01:24.800 --> 01:34.900]  So, one of the things which is actually really surprising is even within the security community, shockingly few people really understand what security is.
[01:36.060 --> 01:38.360]  Security is not about your code.
[01:38.560 --> 01:45.160]  Security has nothing to do with your code because security is about humans.
[01:45.300 --> 01:49.880]  Security is about the people using your code and what they're trying to do.
[01:51.520 --> 01:58.320]  We have this idea and especially you hear it kind of bandied about in like enterprise security organizations.
[01:58.320 --> 01:59.880]  We're going to talk about assurance.
[02:00.120 --> 02:03.180]  You know, we need to maintain assurance on security.
[02:03.340 --> 02:05.880]  We need to know when we're going to get owned.
[02:08.320 --> 02:15.200]  We people spend really shocking amounts of money trying to maintain some kind of assurance.
[02:16.540 --> 02:34.380]  So, the unfortunate fact of our current existence is that unless... if your budget is under about 50 billion dollars a year, and maybe even if it isn't, but definitely if your budget is under 50 billion dollars a year, you cannot afford assurance anymore.
[02:34.520 --> 02:36.080]  Assurance is dead, right?
[02:36.180 --> 02:43.240]  We are living in a world where every commercial operating system on the market has plenty of O-Day floating around.
[02:43.400 --> 02:45.640]  If somebody wants in, they can get in, right?
[02:45.920 --> 02:53.340]  So, if you have meaningful adversaries, you are going to get owned eventually, and that's fine.
[02:53.960 --> 02:56.400]  Getting owned is not actually a big deal.
[02:56.860 --> 03:03.380]  What's a big deal is someone being able to change the outcome of whatever you were trying to do in the field.
[03:04.220 --> 03:05.640]  Outcomes, not assurance.
[03:05.960 --> 03:13.880]  This is a completely different way of thinking about security and security engineering, and it has some serious implications for the way we engineer software.
[03:15.540 --> 03:19.580]  One of them is that in a lot of cases, worse is better.
[03:20.620 --> 03:26.640]  And so, this was a thing that came up on Twitter last night, and it keeps coming up again and again and again.
[03:27.280 --> 03:34.540]  You know, I have folks from the security community coming up and saying, you know, you should only, you know, tether your laptop.
[03:34.540 --> 03:40.340]  You should never try and do anything on a phone because they're completely insecure and you can never trust them.
[03:40.760 --> 03:44.860]  Well, that's true, but maybe that's okay.
[03:46.100 --> 03:58.900]  It turns out that there are plenty of reasons why you might want to slightly raise the bar for an adversary without massively inconveniencing yourself or massively restructuring your life.
[03:59.280 --> 04:17.060]  And when you look at outcomes, when you look at the efficacy of the total system in terms of someone on the ground getting something done, a more secure system does not actually necessarily improve user outcomes.
[04:17.220 --> 04:30.080]  It doesn't necessarily, like even in fairly hostile environments, you know, a lot of the time, what matters is not does my data stay safe for 20 years, it's do I manage to make it to the airport before the shooting starts?
[04:31.060 --> 04:46.180]  You know, sometimes worse, if worse is that much faster or that much easier to use when you're stressed and tired and, you know, can barely remember which way is up, let alone what day it is or, you know, a 30 character passphrase, a lot of the time, worse may actually be better.
[04:46.660 --> 04:53.860]  But to understand how to make those trade-offs, you need to understand what your users are actually doing.
[04:54.720 --> 05:00.300]  One of the things, and this is just a little bit of an aside, we kind of have this notion that, oh, there are security tools.
[05:00.480 --> 05:03.140]  And then there's all that other software, right?
[05:03.520 --> 05:08.320]  Security tools are this thing that, you know, only the wizards write, right?
[05:08.420 --> 05:10.000]  They're the really scary stuff.
[05:10.040 --> 05:11.000]  And then we have everything else.
[05:11.440 --> 05:15.140]  Well, it turns out that you mostly get owned by everything else, right?
[05:15.240 --> 05:17.080]  I'm not going to go in through the front door.
[05:17.200 --> 05:17.880]  Why would I do that?
[05:18.080 --> 05:20.400]  The front door is like alarmed and shit.
[05:20.520 --> 05:21.360]  I'm going to break your window.
[05:23.240 --> 05:33.380]  We don't get to have a distinction between, you know, task oriented tools and security tools anymore, any more than we get to have insurance, because everything is attack surface.
[05:33.900 --> 05:36.180]  Some things are easier to attack, like your browser.
[05:36.360 --> 05:45.340]  Yeah, your browser is probably the single biggest piece of security software you use, because it's by far the single biggest piece of attack surface that you have on your machine.
[05:46.180 --> 05:51.200]  We don't think of browsers as security tools normally, but we should.
[05:51.780 --> 05:53.880]  Or really, we should just erase the distinction.
[05:55.780 --> 06:05.480]  So anyway, if you're trying to figure out security, if you're trying to understand security engineering, you first need to think about, what are my humans trying to do with this system?
[06:06.320 --> 06:12.520]  And that gets you an answer to what secure means in a single system.
[06:12.640 --> 06:14.520]  And it's going to be a different answer every time.
[06:15.740 --> 06:22.080]  So the way we kind of represent that this is what security is, is a security objective.
[06:22.420 --> 06:30.520]  A security objective is basically, these are the things that we've decided to care about in the requirements of the system that are relevant to security.
[06:30.680 --> 06:46.120]  And they're basically statements that say, when one of the guys who we think might be coming after us tries to make something that we really don't want to have happen, happen, then whatever system we're using needs to do something sensible in response.
[06:47.540 --> 06:50.500]  And it's, you know, a more formal version of that.
[06:50.740 --> 06:54.020]  And the way we come up with security objectives is by threat models.
[06:54.680 --> 06:58.220]  So there are a lot of different definitions of threat model out there.
[06:58.500 --> 06:59.720]  This one is mine.
[07:00.060 --> 07:01.100]  I'll go through it.
[07:01.280 --> 07:02.940]  So a threat model is a formal.
[07:03.260 --> 07:08.620]  And by formal, I mean, you can make kind of coherent statements about its correctness.
[07:08.720 --> 07:11.760]  It's not just a bunch of wild ass guesses.
[07:12.600 --> 07:16.900]  Complete in that you can actually tell when you might be finished building the threat model.
[07:17.080 --> 07:23.400]  Because otherwise, you're sort of sitting around and it's like, well, you know, we've been sitting around the table for six hours, do you want to get some beer?
[07:23.980 --> 07:27.920]  And, you know, you're not done with a threat model when you decide you want beer.
[07:28.100 --> 07:29.800]  You're done with a threat model and you're done with the threat model.
[07:29.900 --> 07:31.300]  And your threat model should tell you that.
[07:32.580 --> 07:33.520]  It's human readable.
[07:33.720 --> 07:39.720]  Because if it's not human readable, it's not particularly useful for structuring a security engineering process.
[07:40.000 --> 07:45.140]  I'm not talking about security verifiability or code proofs or any of that nonsense here.
[07:45.280 --> 07:48.460]  This is stuff that structures a human engineering process.
[07:48.460 --> 07:53.080]  It's a model in that you can make... you can use it predictively.
[07:53.220 --> 07:58.540]  You can use it to understand the behavior of the system in response to certain situations.
[07:59.480 --> 08:05.500]  It's a model of the human activities and priorities more than anything else because that's what we actually care about.
[08:05.580 --> 08:10.020]  Remember, this is a model that's trying to surface what security means in this system.
[08:10.760 --> 08:25.240]  And it's also a model of the security-relevant features of the system because, for instance, while you may not have a requirement in your system that it deals with passwords, if it does deal with passwords, you probably want to understand what the security implications of your auth mechanism is.
[08:26.720 --> 08:34.340]  And it's a model of the in-scope portions because, you know, if you say, well, there's a computer connected to the Internet, I guess we better start modeling the whole Internet.
[08:35.580 --> 08:36.600]  Nobody has time for that.
[08:37.400 --> 08:44.160]  So, making a threat model, you know, because you're going to have a structured outcome, requires a structured process.
[08:44.480 --> 08:49.620]  And I'm going to kind of run you guys through it a bit at a fairly, you know, fairly high level.
[08:49.800 --> 08:51.520]  We're moving somewhat quickly here.
[08:52.480 --> 09:01.480]  So, for a threat model, and this is using the TRIKE methodology, which is what I've been working on for a long time, there are other methodologies out there.
[09:01.480 --> 09:05.140]  If you want to know why I'm not very fond of any of them, we can talk after.
[09:06.820 --> 09:10.280]  So, for a TRIKE model, you start with the requirements layer, right?
[09:10.800 --> 09:16.140]  And we look at requirements by talking about actions, assets, and actors.
[09:16.900 --> 09:22.400]  Actors are most of the time people, but they're also any kind of autonomous agent.
[09:22.500 --> 09:25.040]  They can be other systems in the network that you interact with.
[09:25.680 --> 09:29.900]  They're things that interact with the system in some meaningful way.
[09:30.100 --> 09:34.520]  And assets are the nouns that you talk about in the system.
[09:34.540 --> 09:36.480]  And they're the things that you actually care about, right?
[09:36.980 --> 09:45.080]  If I'm building a web-based billing system, it turns out I don't actually care about the passwords in the web-based billing system.
[09:45.280 --> 09:56.240]  Because the only reason there are passwords there is to limit access to the things I actually do care about, which is to say money and personally identifiable information and God knows what else, right?
[09:56.380 --> 09:59.000]  I don't care about the passwords, so the passwords aren't an asset.
[09:59.320 --> 10:02.220]  Now, if you're building a password management system, they become an asset.
[10:02.340 --> 10:06.520]  And we definitely look at them at the At the architecture level, but at the requirements level, they're not relevant.
[10:07.320 --> 10:12.100]  And so then we start talking about which actors can do what kinds of things to which assets.
[10:12.720 --> 10:15.220]  And this is where we get a set of intended actions.
[10:15.460 --> 10:26.200]  We use a control vocabulary of normally create, read, update, and delete to basically give us a structured way to think about who can do what.
[10:26.520 --> 10:30.560]  And you get this matrix, you can see on the lower right.
[10:31.260 --> 10:40.880]  And that's basically a matrix of, like, this user can always create and read comments, but they can never update or delete comments.
[10:41.120 --> 10:49.380]  And this user can sometimes update and delete comments, but only if they're comments that they created or that are on their blog, right?
[10:49.460 --> 10:52.060]  So you have a set of rules that kind of get associated with these things.
[10:52.200 --> 10:57.860]  And this gives you not a perfect mapping for the requirement structure of an application, but good enough.
[10:58.660 --> 11:07.340]  And with a lot of this stuff, what we're trying for is formal enough to let us make meaningful statements but without getting bogged down into the code-proofability nightmare.
[11:07.840 --> 11:12.340]  So from this matrix, we can come up with a set of threats.
[11:13.140 --> 11:17.740]  And so threats basically come in two kinds.
[11:17.860 --> 11:20.820]  They're either elevation of privilege or denial of service.
[11:20.820 --> 11:20.900]  threats.
[11:21.840 --> 11:25.120]  Now, these are basically negative outcomes in the system, right?
[11:25.740 --> 11:34.780]  Anything that can go wrong is either someone being able to do something they're not supposed to be able to do, or someone who's supposed to be able to do something not being able to do it.
[11:36.020 --> 11:43.700]  We don't bother specializing threats out on a per-actor basis, because it just gets too complicated.
[11:43.880 --> 11:52.620]  And we found that when you're looking at basically ranking them in terms of how critical they are, it generally doesn't matter.
[11:52.620 --> 12:04.360]  You know, if there's an elevation of privilege around deleting accounts, you know, if anybody who's not supposed to be able to delete an account can delete an account, it's about equally bad in all cases.
[12:04.740 --> 12:08.620]  You know, there's details, but again, we put fuzz where it's useful.
[12:09.040 --> 12:17.140]  So from this ranked set of negative potential outcomes, we can now build our security objectives.
[12:18.740 --> 12:28.880]  You know, because we can say when some actor attempts to instantiate a threat, the system will respond by doing something sensible.
[12:29.160 --> 12:33.080]  Here we have another controlled vocabulary, which is either...
[12:33.080 --> 12:35.360]  Oh, and one of them is rolled off the button of the screen.
[12:35.960 --> 12:40.280]  Which is either prevent the attacker from launching the attack in the first place.
[12:40.520 --> 12:43.480]  The one that's fallen off the bottom is thwart the attacker from doing it.
[12:43.480 --> 12:53.100]  And this is mostly what you're, you know, if you want the authentication system to reject bad passwords, you're thwarting the attacker from, you know, instantiating that threat.
[12:53.360 --> 12:55.080]  You're not preventing them from launching the threat.
[12:55.200 --> 13:00.020]  That would be, say, preventing the user or the attacker from ever talking to that interface in the first place.
[13:00.320 --> 13:06.460]  And then you have three detect and log, detect and alert, and rate limit that are mostly about denial of service.
[13:07.200 --> 13:11.220]  Because for a lot of the time, you know, if it's a denial of service attack, you can't necessarily You can't really do that much.
[13:11.780 --> 13:17.980]  You just have to tolerate it or, you know, alert a human who can then try and reconfigure the system.
[13:18.920 --> 13:23.500]  So, from this set of things, we can get a set of security objectives for just about any system.
[13:24.680 --> 13:27.820]  So, the next thing we build are data flow diagrams.
[13:28.260 --> 13:31.720]  So, I don't know how many of you here are familiar with them.
[13:31.800 --> 13:36.360]  They're a fairly standard way of representing the structure of a system.
[13:37.300 --> 13:39.100]  You've got your external interactors.
[13:39.160 --> 13:40.600]  In this case, it's just the users.
[13:41.240 --> 13:46.180]  And you've got a set of trust boundaries, which are not in standard DFD, but they turn out to be quite useful.
[13:47.200 --> 13:48.420]  You have a process.
[13:48.580 --> 13:52.940]  In this case, it's a nested process because that's actually a bunch of stuff under the hood that we care about.
[13:53.520 --> 13:56.100]  But this is just kind of the upper context level.
[13:56.220 --> 13:58.060]  And then we have some kind of data store.
[13:59.520 --> 14:08.340]  And about the only real structural rule is that data stores can't talk to each other and external interactors can't talk to data stores directly.
[14:08.580 --> 14:12.240]  Because there's always some kind of process in front of that.
[14:12.380 --> 14:18.000]  A database, you know, in our DBMS is really a process plus a data store.
[14:18.700 --> 14:22.020]  So this is a more zoomed in view of what that might look like.
[14:22.260 --> 14:31.000]  Where you've got a set of different interfaces and different actors or different external interactors who are supposed to be able to talk to each of those interfaces.
[14:32.320 --> 14:41.280]  And normally, when we're building threat models, we sort of drill down until you don't have a process that contains any trust boundaries.
[14:41.280 --> 14:44.320]  That ends up being a good granularity of modeling.
[14:45.860 --> 14:55.380]  So once we've got an understanding of the sort of structure and data flow of the system and what we're trying to do, then we start looking at use cases.
[14:55.740 --> 15:00.520]  So use cases are how we actually implement all of the different parts of the system.
[15:01.020 --> 15:04.800]  In this case, you've got a name and description, some pre and post conditions.
[15:05.400 --> 15:19.280]  And one of the really interesting things, as you start filling out pre and post conditions, this is where you start realizing, oh, we've got all these other things that we're doing in the system that aren't about the requirements.
[15:19.280 --> 15:22.180]  They're about what you have to actually do to implement the system for real.
[15:22.620 --> 15:28.900]  And this is where you get, oh, you know, you've got a user can communicate with the server and the user's logged in.
[15:28.960 --> 15:30.700]  Well, that means we have to have a login use case.
[15:30.940 --> 15:35.180]  And now you start bringing in, oh, there must be a data asset that's the password.
[15:35.180 --> 15:37.380]  And you start, you know, kind of filling this out.
[15:37.540 --> 15:39.300]  Filling out the architecture of the system.
[15:41.280 --> 15:45.240]  You know, and again, like just basic sort of communicating with the server.
[15:45.460 --> 15:53.120]  And one of the things which is interesting about the way these stack up, as we start going into them in more detail, they sort of recursively compose.
[15:53.480 --> 16:00.240]  So that you can have, you know, you have an initial couple communication ones with the system that end up being quite complicated.
[16:00.640 --> 16:04.460]  And then you're just modeling the actual sort of business logic of the system.
[16:06.640 --> 16:13.640]  So the next thing we look at are kind of use cases and details, right?
[16:13.840 --> 16:33.740]  And this is basically walking through the data flow diagram on a given use case and looking at everything that gets sent back and forth at each case, you know, in not in full granularity, but in enough granularity that we can, for every place where we had a condition that was supposed to be enforced in the intended actions,
[16:34.260 --> 16:38.940]  understand what component of the system is responsible for enforcing that condition.
[16:39.360 --> 16:43.000]  Because that's, it turns out, where we start running into our security issues.
[16:43.820 --> 16:48.380]  The next thing we look at is how all of these different components can fail.
[16:48.620 --> 16:54.520]  This is another structured vocabulary tool called HAZOP analysis, short for hazards of operations.
[16:54.720 --> 16:56.160]  It comes from the chemical engineering world.
[16:56.500 --> 16:59.800]  And here in this case, we basically look at each one of these things.
[16:59.800 --> 17:01.800]  Okay, what if you sent something else?
[17:02.040 --> 17:03.320]  What if you sent something additional?
[17:03.640 --> 17:04.700]  What if you sent something less?
[17:05.040 --> 17:07.920]  What if someone other than the user sent the right thing?
[17:08.080 --> 17:08.680]  What would that do?
[17:09.300 --> 17:16.900]  And you start figuring out for each of these, you know, does this violate any of our security objectives if it was successful?
[17:17.460 --> 17:18.540]  Is it meaningful?
[17:18.920 --> 17:20.960]  Can an attacker influence it?
[17:21.540 --> 17:24.520]  You know, is it something we really care about?
[17:24.520 --> 17:25.580]  Is it mitigated?
[17:27.140 --> 17:37.020]  And this is how we build out an actual understanding of what our architecture actually gives us as a security model versus what we thought it was giving us originally.
[17:37.540 --> 17:44.780]  And one of the issues with a lot of the the threat modeling mechanisms out there is that they don't actually tell you anything you don't know about the system.
[17:45.020 --> 17:49.300]  And it seems really dumb to spend a bunch of time building a threat model that isn't going to tell you anything new.
[17:49.480 --> 17:57.180]  So this is where we start really learning things that we didn't understand about the system beyond just what you learn by putting data into a structured form.
[17:58.600 --> 18:00.460]  So this is a lot of work.
[18:00.680 --> 18:02.760]  It is a non-trivial amount of time.
[18:04.560 --> 18:11.460]  But it makes a huge impact on basically every part of your security life cycle.
[18:11.580 --> 18:15.980]  And this is where we start seeing how you structure that life cycle.
[18:16.560 --> 18:24.960]  So in the requirement stage, if you don't have a threat model, you don't really understand what security means for your system.
[18:25.160 --> 18:30.960]  You may have a rough idea, but you certainly don't have a formal actionable understanding of what security means.
[18:31.400 --> 18:35.980]  You're going to have a very hard time detecting issues at the business rules level.
[18:36.160 --> 18:40.260]  And this is true whether you're talking about an open-source app that doesn't really have business rules, whatever.
[18:40.720 --> 18:41.560]  You know, it's the same.
[18:41.560 --> 18:42.260]  It's the same thing.
[18:42.360 --> 18:45.520]  You're going to have a hard time detecting requirements level security issues.
[18:46.180 --> 18:51.340]  And, you know, I've had commercial engagements where that's gone a long way down the track.
[18:51.340 --> 18:58.860]  And, you know, all of a sudden I'm getting pulled in to do a security audit like six weeks before a giant application goes live.
[18:58.880 --> 19:04.560]  And we have to tell the customer, like, look, you have a fundamental incompatibility in the design of this application.
[19:04.560 --> 19:09.740]  You're trying to let your users share this thing over here and absolutely prevent them from sharing it over here.
[19:09.740 --> 19:21.640]  And, you know, that company ended up axing a project team with 60 people on it after two years because they hadn't actually thought through the security requirements issues in their system.
[19:21.800 --> 19:24.280]  So this stuff does actually happen at that level.
[19:24.620 --> 19:33.240]  And there's a lot of more subtle security bugs around like, oh, are, you know, the rules of who's supposed to be able to do what are just slightly wrong that come up.
[19:34.580 --> 19:38.960]  Having a standard form for defining security requirements, if you do have a big team, is huge.
[19:39.340 --> 19:41.020]  I think this is also really true.
[19:41.120 --> 19:50.400]  If you have a very decentralized, distributed open-source team, it's really important to be able to, you know, make sure that everybody understands what their goals are.
[19:51.860 --> 20:01.880]  If you're, again, if you're in a business environment, you know, you're going to have cost trade-offs of like, you know, how much is it worth spending on this set of mitigations?
[20:02.060 --> 20:04.100]  Well, what's the business impact?
[20:04.280 --> 20:06.220]  What does it actually hit at the requirements level?
[20:06.680 --> 20:09.220]  And again, this is also true in the open-source world.
[20:09.620 --> 20:13.240]  You know, are we going to go to the effort of building Tor?
[20:13.460 --> 20:16.600]  Or are we just going to spin up an open VPN server and call it good?
[20:17.000 --> 20:19.480]  Well, okay, we have unlinkability as a hard requirement.
[20:19.600 --> 20:21.500]  Great, we're gonna, we're gonna do the hard work.
[20:22.240 --> 20:27.340]  And it's also great for making a case for costs, because everybody has to do that at some level.
[20:29.260 --> 20:39.460]  At the architectural level, having this kind of structured analysis is pretty critical for defining a design that makes sense.
[20:39.760 --> 20:46.700]  If you've got a small system and you're an experienced designer with a fair bit of intuition, you can wing it and you'll probably be fine.
[20:47.860 --> 20:51.420]  Experienced security architects are f*cking hard to find and they're expensive.
[20:51.860 --> 20:57.560]  And if you have a big system, you probably can't wing it, you know, no matter how good you are.
[20:57.640 --> 21:01.500]  Eventually, you cannot keep the whole system in your head at the same time.
[21:03.060 --> 21:11.140]  And that's really true if you're starting out when you don't have that intuition and you don't, you aren't used to kind of juggling all of this stuff at once.
[21:11.640 --> 21:15.600]  Having a structured process makes a huge, huge jump there.
[21:15.800 --> 21:19.400]  And it also lets you do the analytic side, which is kind of the other half of design.
[21:20.820 --> 21:27.860]  The other thing, and this is again something that, you know, people come up with ad hoc ways of doing, but it's iffy at best.
[21:28.100 --> 21:31.860]  You need a way to communicate the security and variance of your system.
[21:31.980 --> 21:44.520]  If you have things that architecturally are really critical and absolutely have to be maintained structurally through the engineering process, you'd better be able to make sure that your engineering team understands what you're talking about.
[21:44.680 --> 21:48.080]  And that means you need a way of showing it to them and you need a way of documenting them.
[21:50.460 --> 21:54.300]  Every design effort has trade-offs at some point.
[21:54.400 --> 21:58.480]  There's always some kind of what-if analysis of, well, we could build this, we could build that.
[21:59.240 --> 22:09.400]  Having a tool that lets you analyze the impact of those trade-offs at the requirements at the outcome level, you know, at the human level, which is what you actually care about, again, very, very useful.
[22:10.520 --> 22:17.020]  Once you're in development, now you have a formal checklist of everything each developer needs to look at, right?
[22:17.340 --> 22:28.900]  So you're still going to have some platform level issues, but everything that is related to the application as opposed to the platform that you're developing on is represented in your threat model.
[22:29.100 --> 22:34.680]  And you can just build a checklist straight out of that of like, okay, you are developing the user auth component.
[22:34.680 --> 22:41.100]  It has all of these expected things, oh, and for some reason, you know, we put quota management in there as well.
[22:41.300 --> 22:47.420]  So great, you know, you now have to be, you now have to make sure you get all the quota management rules right, and you know to think about that.
[22:49.640 --> 23:03.700]  One of the things which is often difficult for developers, and leads to a lot of hopefully caught in test errors, is when developers don't understand the reason and the rationale between a set of requirements.
[23:04.000 --> 23:10.620]  Because they're not clearly flagged as security requirements, and they don't understand why they're, you know, why they're set up the way they are.
[23:10.780 --> 23:16.940]  So being able to trace that back to the architecture and the requirements in a coherent way is useful.
[23:17.600 --> 23:23.400]  And also, this lets you reasonably split off what each developer needs to know.
[23:23.580 --> 23:35.140]  Because you can say in a coherent way, you over there, you don't need to understand this big chunk of security architecture, because you know that they can't screw it up from where they're, from where they're writing code.
[23:35.560 --> 23:43.020]  It means that not every developer has to understand the whole system, which again, any big team, any loosely structured team, really important.
[23:44.180 --> 23:47.380]  In test is where this starts becoming really useful.
[23:47.680 --> 24:00.340]  You now have a checklist for requirements oriented security tests, which is something that vanishingly few coding projects, you know, of any kind actually have.
[24:00.680 --> 24:05.280]  And you can have meaningful coverage guarantees for requirements level tests.
[24:05.520 --> 24:09.000]  Again, nobody does this, and everybody pays the price.
[24:09.780 --> 24:20.640]  And a lot of cases, if you have a complex enough security integration problem, this means that it's actually possible to do security integration testing that goes all the way up the stack.
[24:20.780 --> 24:23.840]  Because a lot of time, you just can't test it, because you don't understand the system.
[24:25.200 --> 24:33.400]  In deployment, you get to carry over that same list of invariants and understand the ones that impact your deployment environment.
[24:33.620 --> 24:46.940]  You know, if you have some hard assumptions that like the auth backend will never touch the DMZ, because if it does, all sorts of bad things happen, it would probably help if your operations engineers understood that.
[24:50.080 --> 24:54.580]  It means you have some basic documentation of how the f*ck the system works.
[24:55.520 --> 25:01.760]  The number of times I've shown up at a client and asked for a network diagram, and they've been like, well, let's get out a whiteboard.
[25:03.460 --> 25:05.580]  You know, and I'm not even talking about switches.
[25:05.740 --> 25:07.680]  I'm talking about, well, do you have database servers?
[25:08.380 --> 25:09.220]  We think so.
[25:10.900 --> 25:11.380]  Yeah.
[25:11.680 --> 25:22.980]  So having something, some kind of documentation is going to be really useful if you then need to go and bring in anyone outside your kind of little bubble.
[25:23.380 --> 25:28.940]  And it's also really useful, one of the things you can get from this is an understanding of the criticality of different systems.
[25:29.520 --> 25:40.880]  And while your ops team probably has a pretty good idea, you know, of like what system is is critical in what kind of way on the basis of what they get shouted at when it goes down.
[25:41.340 --> 25:43.440]  It's nice to have something a little bit more formal.
[25:44.920 --> 25:49.240]  So when it breaks, and it will break because we've already covered that you're going to get owned.
[25:50.700 --> 26:04.500]  If you've got folks who are not up to speed on this particular system, because it's, you know, especially if you're in the like one sysadmin per 50,000 boxes, you know, SRE kind of world, they don't necessarily know what matters.
[26:04.680 --> 26:07.360]  And your incident response team may have never seen this system before.
[26:07.600 --> 26:11.920]  So you need a way to communicate to them in a hurry, what they're actually dealing with.
[26:13.480 --> 26:21.160]  You've already done the work to figure out negative business outcomes, and how those are linked to specific potential kinds of compromise.
[26:21.500 --> 26:23.640]  So you can do triage a lot faster.
[26:24.300 --> 26:35.080]  And if you say, get notified, you've got a, you've got an 0-day subscription feed or something, and it's like, wow, okay, we've got, you know, 100,000 of these boxes deployed around the world.
[26:35.860 --> 26:38.840]  And we now have to patch them all.
[26:38.920 --> 26:40.080]  And it's an ugly patch.
[26:40.260 --> 26:41.500]  What do we hit first?
[26:41.940 --> 26:46.220]  You can start doing what if scenario analysis a bit more easily in that kind of context.
[26:48.100 --> 26:48.620]  Strategy.
[26:49.000 --> 27:04.700]  If you are, if you are a big enough org that you actually have security strategy, you can now balance between different entire systems and start thinking about business impact of systems in a way that's actually rigorously tied to implementation.
[27:05.120 --> 27:09.840]  You, again, let the business side start understanding about security trade-offs.
[27:10.440 --> 27:26.160]  And if you're in a, let's say you're in a bank, and you've actually got a business risk department that actually tries to understand and model risk at an, at a large organization level, now you can start maybe trying to integrate security requirements with other business risk.
[27:28.640 --> 27:34.400]  So a lot of this, you know, the easy example is kind of waterfall structured.
[27:34.520 --> 27:36.140]  We've done this with agile teams.
[27:36.280 --> 27:37.440]  We've done this all over the place.
[27:37.960 --> 27:45.000]  Um, you know, where each step happens changes a little bit, but it's basically the same system.
[27:45.840 --> 27:47.920]  Um, open-source is a little bit different.
[27:48.080 --> 27:50.580]  It's a little, it's sort of like agile and then a bit more.
[27:50.800 --> 28:01.820]  Um, requirements tend to come a lot later in a lot of open-source projects, you know, maybe six months or a year after people start writing code, sometimes three years, they figure out what they were writing.
[28:02.220 --> 28:15.020]  Um, and I think that this is actually entirely reasonable because of the kind of structure of how requirements are motivated and communities and all of the, you know, the kind of the, the way we build these tools.
[28:15.400 --> 28:19.900]  Um, so it does change the way you build threat models for open-source projects.
[28:20.000 --> 28:31.100]  You know, you're much more likely to come in later, you're much more likely to just do the requirements, hold off on architecture, you know, kind of, um, bounce back and forth.
[28:31.260 --> 28:32.520]  It's much more exploratory.
[28:32.700 --> 28:33.620]  It's more of a living model.
[28:34.000 --> 28:40.200]  Um, the benefits end up being about the same though, you know, in the end, it, it does roll together in pretty much the same way.
[28:41.660 --> 28:57.800]  So, um, I want to talk a little bit now about the kinds of testing that this does not necessarily guide and kind of about how this plays into outcome oriented security at a higher level.
[28:58.220 --> 29:07.140]  Um, so one of the things that your threat model is not going to tell you directly is what bug classes you need to be aware of on your platform.
[29:07.800 --> 29:08.500]  You know, great.
[29:08.640 --> 29:09.420]  You're writing a web app.
[29:09.660 --> 29:09.740]  Okay.
[29:10.340 --> 29:12.640]  CRSF or CSRF, XSS.
[29:12.860 --> 29:14.800]  You've got, you know, your kind of list of stuff here.
[29:15.040 --> 29:16.320]  You know, you're writing in C.
[29:16.440 --> 29:16.660]  Okay.
[29:16.720 --> 29:17.960]  You've got buffer overflows.
[29:18.180 --> 29:19.560]  You've got this, that, and the other.
[29:19.780 --> 29:25.340]  Um, so you need to understand which bug classes are, are things you need to care about on your platform.
[29:25.340 --> 29:34.440]  Um, in general, and this is, this is just true regardless of whether you're looking at the threat model impact or not.
[29:34.700 --> 29:39.900]  Um, you know, there's a, there's a lot of effort these days.
[29:40.280 --> 29:43.080]  You know, we're gonna, we're gonna hunt specific bugs.
[29:43.240 --> 29:47.520]  We're gonna, you know, it's the, it's the kind of zero day centric understanding of bugs.
[29:48.600 --> 29:56.340]  If you ever have the choice to kill a class of bugs versus going and fixing a bunch of individual bugs, dear God, don't fix the individual bugs.
[29:56.480 --> 29:56.840]  Do it right.
[29:57.240 --> 29:59.180]  You know, you will save so much time.
[29:59.900 --> 30:11.640]  And here frameworks, anytime you can just shift your platform, add a framework, whatever, and get rid of a class of bugs, you're, you're, um, winning by, by miles.
[30:12.740 --> 30:16.180]  Um, parsers protocols and state machines.
[30:16.620 --> 30:24.100]  If you have any code in your system that was written by a human that tries to parse something, you have a bug.
[30:24.820 --> 30:25.340]  Really.
[30:25.380 --> 30:36.840]  You have a bunch of bugs, but the first bug that you have is that you let a human write a parser because humans don't write parsers, um, very specific humans write parser generators.
[30:37.760 --> 30:50.220]  Um, and then you can write formal specs to what you want that parser generator to accept and then you can go review that formal And ideally somebody else has already written the formal spec, if you're lucky.
[30:52.440 --> 31:00.000]  There's an entire, I guess, kind of movement called LangSec, which is like basically language theoretic approaches to security.
[31:02.140 --> 31:09.720]  If you... any time you have a parser, you're going to find bugs.
[31:10.080 --> 31:15.040]  So if you didn't pay attention on the last slide, now you're going to pay for it with fuzzers.
[31:15.460 --> 31:20.100]  And this, again, is testing that's not directly driven by the security model.
[31:20.980 --> 31:38.840]  Any non-human generated or any human generated protocol or parser needs to be fuzzed, almost regardless of how simple it is, because you would be just shocked at how little code you need to write a protocol parsing bug.
[31:40.160 --> 32:03.040]  If you have any interface or protocol or APN, an API endpoint, even if you think it is, you know, even if it is a formally specified protocol, even if you think you really understand what that API is supposed to do, if you can't come, if you can't explain it to somebody who's totally not familiar with your specific system in less than five minutes in full detail,
[32:03.240 --> 32:04.760]  you need to put a fuzzer on it.
[32:07.100 --> 32:09.980]  We all know that you don't write your own crypto, right?
[32:10.280 --> 32:12.240]  This is... everybody gets that.
[32:12.720 --> 32:16.660]  If you write your own cryptographic algorithm, you are living in a state of sin.
[32:17.280 --> 32:20.780]  If you write your own cryptographic protocol, you are living in a state of sin.
[32:22.600 --> 32:25.220]  You will know if you are an exception to this.
[32:27.900 --> 32:32.320]  Except sometimes you do end up writing your own cryptographic protocol, and then you need real help.
[32:33.780 --> 32:41.780]  And not necessarily just, you know, You know, psychological help or, you know, like a long, long vacation.
[32:43.300 --> 32:48.240]  But you're gonna need it audited and you're gonna need it, again, formally specified, right?
[32:48.560 --> 32:57.160]  Anytime you do some kind of anything novel around crypto, it has to have a formal spec.
[32:57.600 --> 33:00.700]  And that formal spec has to be openly vetted.
[33:00.920 --> 33:15.560]  If you are writing novel cryptographic protocols and novel cryptographic primitives and pretending they are trade secrets and not opening them up to outside review, what we call you is the front page of the New York Times.
[33:17.500 --> 33:25.880]  If you're just using normal protocols and, like, doing the thing that they're supposed to do, any normal audit team that's qualified should be able to audit that protocol.
[33:25.940 --> 33:28.580]  You probably want them to, but it's not a huge deal.
[33:30.580 --> 33:32.460]  When you need to bring in experts.
[33:32.960 --> 33:40.140]  So the thing I left off of this slide, a lot of the time it is really useful to have someone else come in and do threat models.
[33:41.160 --> 33:42.320]  They are a pain.
[33:42.620 --> 33:48.280]  They are not as intuitive as I would like them to be yet.
[33:49.860 --> 33:55.200]  But it may be a lot faster to just bring someone in and have them pinch hit for that.
[33:55.820 --> 34:00.260]  And kind of on a, you know, skipping along as you go through the dev cycle sort of basis.
[34:01.220 --> 34:05.040]  Regardless, if you're trying to ship secure code, someone other than you has to read it.
[34:06.240 --> 34:08.140]  I cannot audit my own code.
[34:08.320 --> 34:11.020]  I've been auditing code for a very long time.
[34:11.040 --> 34:12.900]  If I wrote it, I won't see the bugs.
[34:13.120 --> 34:14.500]  And this is true for everybody.
[34:14.700 --> 34:16.880]  You know, you do not audit your own code ever.
[34:18.940 --> 34:37.980]  When you are doing requirements, and this is especially true if you don't have the kind of, like, specific business need, somebody's already done the market research, you need to do field outcome sanity checks to understand that the security properties that you think your user will want,
[34:38.080 --> 34:39.800]  they are actually going to care about.
[34:40.100 --> 34:47.980]  And that the user experience that you think is going to be understandable to them, they are actually going to be able to deal with.
[34:48.160 --> 34:52.660]  And that this at all maps to the deployment scenarios where your system is actually going to get used.
[34:53.580 --> 34:55.640]  I cannot stress this enough.
[34:56.140 --> 35:14.180]  You know, especially if you are trying to write some kind of secure comms tool or, like, you know, significant adversary host security tool, and you have not done field outcome sanity checks with people who do not look like you and who do not live in your country,
[35:14.180 --> 35:20.900]  you are doing it wrong and your tool and all of your time is almost certainly a complete f*cking waste.
[35:20.900 --> 35:22.740]  Don't waste your time.
[35:23.000 --> 35:23.860]  Do the work.
[35:25.220 --> 35:30.740]  As soon as you have a coherent architecture, you want to get an architecture review done.
[35:31.600 --> 35:37.880]  This can be done more informally, it doesn't have to be a huge heavyweight thing, but you need something.
[35:38.200 --> 35:48.440]  There's this lovely curve of the cost of, you know, when a bug is introduced to when you fix it, and it's an exponential curve.
[35:48.440 --> 35:54.840]  You know, if you introduce architecture bugs and you find them in deployment, it's going to hurt.
[35:55.140 --> 36:02.540]  You're looking at maybe a hundred times what it would have cost, maybe even a thousand times what it would have cost to fix them during architecture.
[36:04.100 --> 36:12.600]  If you're writing secure communications tools, and you don't get an architecture review done before they ship, we call that thousand X cost a body.
[36:12.840 --> 36:14.300]  Don't make bodies, please.
[36:17.140 --> 36:31.540]  Ideally, if you can afford it, you'd really like code review by beta, and again before release, you'd really also like to have mitigation reviews done to make sure that you actually fix the bugs you thought you fixed.
[36:32.260 --> 36:37.580]  Peer review and specific cryptographic audits for anything novel as soon as you can do them.
[36:40.640 --> 36:53.500]  So, one of the fascinating things about threat models is that if users don't understand what your threat model is, they can't use your tool properly.
[36:54.500 --> 36:59.760]  And they do not necessarily need to understand all of the technical architecture.
[36:59.760 --> 37:12.180]  There is sort of a user threat model that's basically, this tool will provide you with these kinds of properties under these kinds of situations, unless these other kinds of situations happen.
[37:12.440 --> 37:17.260]  And this is how you can tell if one of those situations has happened, and this is what it means.
[37:17.700 --> 37:22.620]  And that's basically what your user needs to understand about the security of your tool.
[37:22.620 --> 37:37.580]  If your tool fails in a manner that your user cannot correctly diagnose from whatever information is available, what is going on, it is not a secure tool.
[37:37.740 --> 37:44.540]  It does not provide the properties you claim it does, because they cannot react appropriately in the field.
[37:45.700 --> 37:47.000]  Now, worse is better.
[37:47.340 --> 37:51.200]  That doesn't mean that it may not still be a totally reasonable tool for them to use.
[37:51.440 --> 37:57.300]  And especially in larger mass market tools, sometimes, you know, you make decisions for your users.
[37:57.380 --> 38:00.600]  You just assume, well, you know, we're not going to let you diagnose this problem.
[38:00.600 --> 38:14.600]  We're just going to fail closed, or, you know, we're going to provide best effort security, because anything more would be, you know, categorically unreasonable burden on the user in the deployment environments we see it being used in.
[38:14.740 --> 38:17.860]  So, like, trust on first use is a great example of this, right?
[38:18.280 --> 38:23.160]  You know, you just say, well, we assume that you weren't man-in-the-middle the first time, and then we'll detect it if it happens later.
[38:23.400 --> 38:27.900]  This actually turns out to be really reasonable a lot of the time, because you're probably not man-in-the-middle the first time.
[38:27.900 --> 38:31.400]  And then you give the user something reasonable they can do later.
[38:31.860 --> 38:35.480]  But, yeah, they don't have enough information to diagnose if they actually got owned.
[38:35.680 --> 38:38.060]  But remember, you're going to get owned, so that's fine.
[38:41.720 --> 38:48.880]  So, you may have noticed that most of the stuff I've talked about we don't actually do, even in our security tools.
[38:49.240 --> 39:01.840]  There are vanishingly few security tools that are supposedly aimed at users with nation-state adversaries, that even have threat models, sadly.
[39:03.260 --> 39:05.240]  So, some of this is money.
[39:05.600 --> 39:06.780]  Security is expensive.
[39:07.800 --> 39:11.520]  So, just to kind of put a ballpark on there.
[39:11.660 --> 39:20.060]  If you've got an app that's maybe 300,000 lines of code, you can expect to spend about $30,000 on a code audit.
[39:21.200 --> 39:24.420]  And you're going to need to get those done repeatedly over the life of the application.
[39:24.760 --> 39:30.500]  So, if it's an open-source hobby project, this is going to cost real money.
[39:31.600 --> 39:41.400]  We have a duty to our users if we are shipping tools, especially if we are shipping tools that are intended for either mass dissemination or high-risk users.
[39:41.400 --> 39:44.840]  You don't get to tell your users what to use your tool for.
[39:45.880 --> 39:49.780]  And, you know, some dumb kid is going to use it to try to start a revolution.
[39:50.240 --> 39:53.460]  And you would really like to not get him killed.
[39:54.860 --> 39:55.880]  Audit your code.
[39:56.120 --> 39:57.360]  Don't be libpurple.
[39:57.820 --> 40:02.080]  Don't be that thing that we've been telling users, hey, yeah, this is awesome.
[40:02.200 --> 40:06.440]  This is a tool that you should totally use for your secure communications with OTR.
[40:06.440 --> 40:07.460]  It's going to be great.
[40:07.660 --> 40:15.400]  And that we've also been telling people, hey, this is a really great library for learning how to write malware on because it's got thousands of f*cking bugs.
[40:15.700 --> 40:16.940]  Don't be libpurple.
[40:19.600 --> 40:27.880]  They add cost up front, but in the long run, doing threat models will radically reduce your security costs because it means that you understand the system better.
[40:28.940 --> 40:40.300]  Similarly, you know, especially if you're in a startup and you actually are throwing money around, you know, if you've got five people and you try to hire a senior security guy into your team, you can't afford them.
[40:40.440 --> 40:41.960]  You don't want to afford them.
[40:42.400 --> 40:43.600]  Just bring in a consultant.
[40:43.740 --> 40:46.200]  You'll pay more per hour, but you're going to save a lot in the long run.
[40:46.660 --> 40:48.520]  You'll know when you're ready to hire somebody.
[40:50.620 --> 41:01.180]  One of the reasons we don't do this is there's this long-running understanding that security is a negative feature, that security is just a cost, and you do as little of it as you think you can get away with it and as late as you can.
[41:02.480 --> 41:17.260]  If you are understanding the world in terms of efficacy, if your understanding is that you are trying to help your users accomplish a task in the real world, security is a feature because if they get owned halfway through that task, that's a reliability bug.
[41:17.500 --> 41:22.600]  You know, you can just open a ticket, user got shot six steps in.
[41:23.380 --> 41:30.140]  You know, security is not actually a negative feature when you start thinking about efficacy and outcomes.
[41:32.520 --> 41:42.100]  So one of the reasons why we don't do requirements modeling and requirements analysis is that the 0-day market has killed Blue Team.
[41:42.480 --> 41:50.140]  You know, we've spent 30 years, 20 years, whatever, giving props to the guys who find new instances of bugs.
[41:50.140 --> 41:57.700]  Not to the people who find new classes of bugs and then kill those classes of bugs, but it's like, wow, you dropped 0-day on full disclosure.
[41:57.860 --> 41:58.500]  You're so cool.
[41:58.660 --> 41:59.580]  No, you're not cool.
[41:59.660 --> 42:01.120]  You're wasting everybody's time.
[42:01.360 --> 42:03.800]  Go get a real job and start fixing shit.
[42:05.540 --> 42:09.120]  Security requirements in particular are incredibly underdeveloped.
[42:09.220 --> 42:12.300]  There is a community out there thinking about security requirements.
[42:12.300 --> 42:15.180]  They don't talk to the rest of the security community.
[42:15.320 --> 42:16.340]  They're mostly academics.
[42:17.440 --> 42:25.940]  This is terribly unfortunate just because of the expense and the scale of requirements level issues.
[42:26.860 --> 42:36.100]  And security requirements is one of the big places that new, you know, bug class killing mechanisms come from.
[42:36.800 --> 42:44.240]  And architectural analysis is one of those places, you know, yes, we absolutely need to do enough red team work.
[42:44.400 --> 42:48.060]  Enough bug finding so that we fully understood a class of bugs.
[42:48.180 --> 42:50.100]  And we need to go look for new classes of bugs.
[42:50.320 --> 42:53.820]  Once we've understood those classes of bugs, we don't need to do it anymore.
[42:54.320 --> 42:56.180]  We need to put the effort on the other end.
[42:56.980 --> 43:06.300]  One of the other problems and one of the other reasons why we do this less is that, you know, that kind of bug hunting, that kind of, you know, I'm going to break this thing.
[43:06.400 --> 43:06.820]  That's fun.
[43:07.520 --> 43:09.840]  A lot of folks enjoy it.
[43:10.440 --> 43:15.900]  And it doesn't have to be... it's not about the same kind of structure and discipline.
[43:16.960 --> 43:18.700]  It's much more solo work.
[43:19.540 --> 43:23.880]  This kind of stuff requires you to actually work with a whole dev team in a structured way.
[43:24.120 --> 43:25.500]  It's kind of boring sometimes.
[43:25.500 --> 43:35.360]  So, you know, the last thing that I get a lot from people in the security community is why should I care about usability?
[43:36.040 --> 43:37.440]  Because it's not my problem.
[43:37.700 --> 43:40.120]  And it's not really my bailiwick.
[43:40.300 --> 43:46.000]  Like, you know, the enlightened folks are like, yeah, there has to be a UX person.
[43:46.120 --> 43:48.800]  They can do all that usury stuff over there.
[43:49.160 --> 43:51.940]  And I'm just going to go do the security stuff over here.
[43:53.280 --> 43:57.860]  And then you also get another group of people who are like, usability, why would I care about usability?
[43:58.180 --> 43:59.360]  This is a security tool.
[43:59.600 --> 44:09.200]  You know, anybody who's actually using it should clearly, you know, know how to do, you know, large modulus hex arithmetic in their head, right?
[44:11.640 --> 44:23.680]  If you don't understand the requirements of the system that is kind of at the core of usability, and you don't understand the usability impact of security mechanisms, you cannot design security mechanisms.
[44:23.840 --> 44:25.460]  You cannot design countermeasures.
[44:26.780 --> 44:35.320]  You know, and I'm not saying that everybody in the security community needs to go become a UX person, but they need to learn the language and they need to meet halfway.
[44:35.640 --> 44:38.360]  And this is true of the usability folks, too.
[44:39.920 --> 44:47.080]  One of the other big issues that we run into is security folks thinking that they do understand their users, when they don't, actually.
[44:47.800 --> 44:49.560]  You know, this is GPG.
[44:49.860 --> 44:51.280]  Johnny still can't encrypt.
[44:51.460 --> 44:55.500]  It's been going on 30 years now or something.
[44:55.760 --> 44:56.360]  It's ridiculous.
[44:57.460 --> 44:57.980]  Yeah.
[44:59.680 --> 45:03.180]  None of us understand the perspective of other users until we go ask.
[45:03.180 --> 45:06.400]  I do not understand the perspective of other users until I go ask.
[45:07.980 --> 45:16.820]  And in a lot of ways, if you have spent too much time in this world, unless you ask in a structured and formal way, you're just going to end up making a whole bunch of assumptions that are going to be wrong.
[45:18.540 --> 45:20.440]  So, I am happy to take questions.
[45:20.680 --> 45:22.880]  I know I've covered a lot of material fairly quickly.
[45:23.940 --> 45:30.020]  If you're interested in OctoTrike or in the threat modeling methodology, it's at octotrike.org.
[45:30.560 --> 45:35.020]  Unfortunately, the best implementation we have that's current right now is an Excel spreadsheet.
[45:35.280 --> 45:36.140]  It's kind of hideous.
[45:36.620 --> 45:38.800]  It has a few million cells in it.
[45:38.880 --> 45:42.620]  There's no macros, but it's got disturbing things done with formulas.
[45:43.120 --> 45:49.720]  There will eventually be a proper implementation again, as soon as we get some time and some money to actually write code.
[45:50.340 --> 45:55.240]  And then, if you want to send me mail or get at me on Twitter, I'm dymaxion on Twitter.
[45:56.080 --> 45:58.860]  Website's dymaxion.org, email address, et cetera.
[45:58.860 --> 46:01.720]  So, questions?
[46:02.760 --> 46:03.340]  All right.
[46:03.540 --> 46:07.040]  So, Bill, security during the building process is really sexy.
[46:07.280 --> 46:08.980]  And breaking things is super sexy.
[46:09.520 --> 46:12.280]  Maintenance is not very interesting at all to most people.
[46:12.440 --> 46:18.660]  How do we, like, emphasize continual review of, like, security threat modeling and security practices throughout the center part of it?
[46:21.820 --> 46:26.200]  So, the question was about how do we encourage security work during maintenance?
[46:26.200 --> 46:31.260]  I mean, I think partially this is, you have to have an understanding that a threat model is a living document.
[46:31.540 --> 46:35.040]  And that as code changes, the threat model needs to get updated.
[46:35.260 --> 46:39.340]  And this is why agile is not that different from waterfall in the end.
[46:39.580 --> 46:43.100]  Because even if you're doing pushes, whatever, there's always bug fixes.
[46:43.240 --> 46:44.880]  There's always, you know, small code releases.
[46:46.560 --> 46:48.500]  You just, it just has to become a discipline.
[46:48.640 --> 46:50.460]  And this is, this is where you get into the boring bit.
[47:32.560 --> 47:36.700]  Yeah, that's, and that's a, you know, I'll, I'll just repeat for the stream.
[47:36.700 --> 47:50.680]  You know, if you're, if you're outsourcing, actually building requirements, security requirements into what you give to the people that you actually outsource the code to means that you get what you wanted, not what they felt like building.
[47:52.920 --> 47:53.660]  Anybody else?
[48:14.290 --> 48:18.550]  So, for risk assessment, so I don't believe that risk exists, right?
[48:18.550 --> 48:21.370]  Because the risk of getting owned is eventually one.
[48:21.590 --> 48:23.770]  You're trying to predict outside human actions.
[48:23.990 --> 48:25.630]  It's, it's not something we can really predict.
[48:25.870 --> 48:27.970]  What you can predict is exposure, right?
[48:28.070 --> 48:41.970]  And so that's basically what we're modeling here when we start looking at, at the impact of a negative eventuality is, you know, business exposure or, or, you know, negative outcomes, you know, the severity of a negative outcome for a user.
[48:41.970 --> 48:45.250]  And so that's something that we can actually understand structurally.
[48:45.450 --> 48:47.650]  I don't think we can understand anything beyond that.
[48:47.910 --> 48:50.450]  And I think that's all we've got time for.
[48:50.570 --> 48:53.750]  So I'll be out in the hall, if folks have more questions.
[49:04.920 --> 49:05.320]  Oh!
[49:05.960 --> 49:06.620]  We've met them.
[49:07.020 --> 49:07.640]  We've met previously.
[49:08.380 --> 49:09.100]  Oh no, that's right.
[49:09.420 --> 49:10.000]  Yeah, yeah, yeah.
[49:11.920 --> 49:12.320]  Yeah.
[49:13.240 --> 49:13.440]  Yeah.
[49:13.440 --> 49:13.740]  Thank you.
[49:14.640 --> 49:15.320]  Thank you.
[49:15.320 --> 49:15.400]  Thank you.
[49:15.460 --> 49:15.500]  Thank you.
[49:15.500 --> 49:15.860]  Thank you.