BSidesCharm - 2019 - Liam Randall - The Declarative Future

OK, Google, please play Rick Astley, Never Going to Give You Up. Hey Siri, please play Never Going to Give You Up. You'll need to unlock your phone. Well, there we go. Some things are more secure than they seem. And welcome to the day two keynote for B-Sides Baltimore. And today I'm going to do a talk that's quite a bit different from the ones that I usually do. I look around the room, and I actually have had about 30 or 50 of you in my classes before and you know that I spend a lot of time working on large-scale network monitoring. But I really wanted to use this as an opportunity to kind of look forward.

And before I do that, let me start with a quick disclaimer. And that's that the opinions expressed today are solely my own and do not reflect the views of anyone else, especially my employer. So who am I? So my name is Liam Randall. I've been in tech for over 20 years. I got my start at a university and I very quickly was called towards security. I'm probably most well known for taking a little language out of Berkeley that used to be called Bro to market. But I've also was the seed investor on OS query, if you're familiar with that, out of Facebook. I've recently sold, a couple years ago I sold critical stack to Capital One. And I sort of work now as an

angel investor and I run an innovation portfolio for Capital One Bank, which I love. It's a phenomenal place. We're hiring all the time if you're interested. I talked to Katie or myself afterwards. I'm a husband and a dad, and I wanted to talk really quick about my own personal journey. because it gives me some insight into some of the frustrations I think that many of you feel if you've been in security for a while. And I got my start back in the mid-90s working for a large university, actually a mid-sized university, Xavier, as a network administrator. I had about 6,500 hosts. And I learned some really critical lessons early in my career, and that's that I could never visit every single workstation. So I started writing my own tools

that ran in our Novell 312 logon scripts to do network monitoring and some of my first challenges were migrating to TCP IP from IPX SPX. From there, I went on and I started to get into product development. One of my first products, I ended up doing around $150 million on a recurring basis annually. That was around the turn of the century. And from there I went into large scale network monitoring and this is where I sort of met most of the people in this space and I had the opportunity to work with hundreds of other companies. Many of the internet majors, over half the Fortune 100 and pretty much for about ten years I just tapped all the things. I went around and I got

to see these patterns of failure across a huge variety of organizations. And that's what has really driven the sort of most recent stages of my career. And that's in moving into the productization of security, into declarative security. And for me, this really came to me like a calling. And that's a strange word to use at a technical conference because the word calling is usually reserved for, you know, religion. But for a lot of the people here, on a Sunday morning no less, on the weekend, you're not here because your employer wants you to be. You're here because you love it. And that's that passion that drives us forward is going to be our only hope to sort of get out of this. You

know, passion is this great precursor to expertise. It's the passion to stick with it even when it's Sunday morning, when you stay with it and you go from there. So before we move through the agenda, I'm going to do a quick little state of security. I'm not going to spend a lot of time there, because we all know what the current state of security still is. And it's the exact same state that it was in 20 years ago. I'm going to talk about what I think is the most important thing, which is the changing landscape and the opportunities in the changing landscape. Then I'm going to do a demonstration on a timeless technique, a web shell, when it meets the sort of declarative future. And then finally

I'm going to do a call to action and try to inspire you guys on to what are some of the low hanging fruits and opportunities that you should be taking in your career. So at this point I assume that the state of security is completely self-evident and that's that on a lot of levels we're just at a complete and utter failure. There is, you know, the strategy of

Protection is helpful, but only when paired with rapid detection. And most of my talks, if you go on YouTube, or if you come to one of the network monitoring classes that I teach, I'm teaching you how to deploy NSM, you know, Bro, Shirokata, Stenographer, or at Shmukon Epilogue, we did a talk about our new endpoint security monitoring, which is OS query plus Sysmon, plus Elasticsearch, and running these things at large scale. But the ultimate TLDR is that In today's infrastructure, it's incredibly hard, it's bespoke, and it's relatively expensive. And that's a general word. I think you can do it a lot better yourself with open source than with stacks of commercial products. But ultimately, we're just not at a good place. And we can't solve today's

problems with the same level of thinking we used when we created them. And that's the old Albert Einstein adage for the blue team. But it's especially hard. Because when I would go from large organization to large organization, bad is a matter of policy. Because what you accept in your environment, what you do in your environment is all bespoke. So the portability of things like AI models and ML models, I'm very skeptical that many of those models are going to be highly portable. Because there are things that are normal in one network, in network A, that are completely abnormal and would be a red alarm fire in another network. So I do spend a lot of time working and developing AI and ML using Bro and Shurikata and

OS Query and Sysmon Data, but I think that there is a precursor step that we should be taking before we move there, and that's that declarative future. Now I'm going to come back to this one, but ultimately this technology problem is compounded by people problem, and it's that users are the weakest link. And there are some reasons for that that we'll review and more, but we've all got limited working memory. When we're looking for information or reading blogs, we scan. We don't actually read and consume. We look for trigger words like our names, some of the things that trigger the reptilian brain. And it's not that people are lazy, they're just concerned with making progress

in their lives. And they are a little lazy. They're also social. And at a deeper level, many of our decisions are unconscious and can be easily manipulated. And I think that there's obviously a crisis in social media with manipulation at the moment, but that's also an opportunity. And we're actually going to dive into that a little bit. So let's talk about the declarative future and what that actually means. So when we're looking at, look across the last 30, 40 years of infrastructure, there are these big computing epochs that we're sort of rolling through. And many of us started our career back in the full PC days when you would actually spec out the RAID array,

and you would be bounded by a single machine, and you would treat these machines like they're your pets, and you would love them and care for them. And if they got sick, you would feed them and try to fix them, and they were important to you, SQL 01. was a precious little asset, and his little brother, SQL 02, was the next generation. And when virtualization came along, it was a big step. And we start to see this trend of giving developers and application delivery teams less and less responsibility and having a greater shared surface. If you look at that chart there, you see the straight line going across. And even though virtual machines have been out for a long time, that's still mostly how people use the

cloud. Most people just think of the cloud as a big virtual machine store where I can rent servers. And that's their model. Now, there's been a big paradigm shift with containerization. And what most people haven't ultimately considered is that when we're moving to these containerized solutions with things like Docker, you're not just moving the security boundary from the CPU to the Linux kernel. You're also moving the networking boundary. And that's a radical shift. with what we've been doing in security. And that's going to continue to drive things forward. Now, serverless is a great idea, because if you think about it, it's even less things that the developers need to be responsible for. I'm of the

mind right now that serverless and containerization are essentially being smashed together. If you're familiar with what Kubernetes brings to the table, I'm not going to talk a lot about Kubernetes, but I will actually use it in some of my demos today. the weakness with serverless has been that it's not portable. But with the rise of Kubernetes frameworks like Knative, or even the native serverless project, or some of the other CNCF projects, the Cloud Native Computing Foundation, we now have portable serverless. So we're seeing this trend where, with the infrastructure, we're bringing the responsibility up here. And this is moving us towards a more declarative model. Now, in these declarative models, you sort of The dream is that you can simply just leverage the capability. You define the end

state. You say, hey, here's my container. Just run this. And if you're familiar with some of these vendors here, the less declarative models are the ones where you need to explicitly tell them how you want them to work. So on the far left side of the screen, DevOps is king. And on the far left, there's sort of a decline of DevOps. It doesn't go away, but it's certainly falls behind the veneer of these declarative interfaces. So if I'm a team that's building the containerization platform on Kubernetes, or if I'm building the serverless platform, I have DevOps people co-located with my team, but you don't need the DevOps people in order to build them. And that's

a little bit of a shift from where people have been building their infrastructure. Now, we'll look at what a container is, but these are these little modular and isolated application delivery items. And they're coupled with that shift again of moving the security boundary from the CPU, this boundary of the network, think down here on the left side. That is where almost all of your security controls today work. Your common security controls today aren't designed to extract metadata and information from inside the Linux kernel. And that is a huge opportunity on the product side for sort of rebooting everything that's out there. But if we think about where this trend starts to take us on the technology side, and we combine this with the trend of what's happening on

the application side, infrastructure in the very near future looks radically different than it does today. And this is not an imagination. If you're in large enterprise right now, there's a breakneck switch that reminds me of what happened when virtualization was first introduced into the ecosystem. of people moving to these technologies. There's huge efficiency gains to be had from a higher application density. There's huge cost savings to be had. And there's huge simplicity for the developers, for the application execution teams, and so forth. So let's talk about these containers for a quick minute, and then we'll get into some actual demos to make this a little bit more interesting. So when you're comparing these kind of big ontologies here, the weakness in serverless has traditionally been that

it wasn't portable. And I've just changed that to red yesterday, because now I feel like with some of the frameworks that are out there, that is becoming portable. But when you think about what is the attack surface, the attack surface is getting smaller and smaller. At least what the attack surface that you, as an application developer, are responsible for. If you're running on virtual machines, if you're deploying into EC2 or some raw compute resource, then you also need to be concerned about the operating system. Now maybe you have a team that patches it, but if you can raise yourself up into the containerized world, you can leave behind as many of these things as possible. And you can execute in a world with a minimal attack surface. That's

what that trend line is really going there. Now if you, just real quick by a show of hands, who's using containers today in production? A lower number than I would see at cloud events. At a reInvent, obviously, that would be a place where you would find lots of cloud people, but I think that's a big opportunity in security itself. When you're building these containers, they essentially come as layers. So think of it like a cake, right? You can start with an underlying piece of cake, like you could say from Ubuntu, or you could say from Golang, or you could say from Alpine, or one of these containers here, and you just add the minimal amount of layers that you have there. So on one hand we have the

infrastructure getting smaller and smaller. And on the other hand we have the applications that are getting smaller and smaller. And what I'd like to show you is what happens when these two things meet the current sort of state of the art in exploitation. And let's look at an example here. We're going to use a web shell. This is a timeless and true tactic. I will do a little intro here to sort of set the scene. The application team has successfully deployed their application, and the CISO can sleep at night because all is good in the world. And then fortunately, there is a threat actor that exists in the universe that has decided that they want to get all of your data. So the

company's happy because they're saving lots of money. They've opened this portal on the web where their customers can come 24-7 and sign up for a new account or apply to join their team or whatever the case would be. However, they've also opened up some huge exploits into their environment. Now, this technique, it's unbelievable that this technique is still as common as it is. But if you're reading a poise exploitation reports from any modern incident, it's still the same things. And these are, if you go back to the 90s, we were using web shells back in the 90s, and this technique still hasn't gone anywhere. So what we're going to do is, I'm first going to

walk you through what a web shell looks like. As I know not everybody spends all day actually deploying these things or responding to these things. We're going to switch devices here, so hopefully we actually train back up on the video.

So let's see. This trains back up here. Signal. Tiny screen. OK, better. So this is what a web show looks like. So typically a company will, you know, this is the company here over on the right side. They're operating, you know, this web page with a customer account portal. And in this case, we'll say that this is a healthcare company. And this is actually based on a real incident that I helped respond to a few years ago. You may have read about it in the news. And what happens is normally a person can come in, And they can sign up for a new account, and they can upload their application to the company. And you actually can fill out a piece of paper if you want, and

you can scan it in. And the developer checks and says, hey, is this app, is this end in .gif, .jpg, or .png? And what happens is a threat actor comes along. And when you think about advanced persistent threat, people oftentimes focus on the advanced piece of this. But I'll tell you that it's typically the second piece. It's the persistent piece that comes into play. And I'll show you bro logs from this incident here in just a moment. But let me walk you through what it actually looks like. So the threat actor visits the web page. And let me change my pen to red here. And they first try to upload a file called login.asp.

And they put this up on your server, and the developer checks, actually look at this, and they say, I'm sorry, this doesn't end in .png or .jpg or any of the other things. So I'm not going to accept that file. And they're sitting on their healthcare portal here, and the web server actually then throws a, it doesn't throw an error here. So the threat actor then uploads another document, and this one they rename to login.asp semicolon.gift.

Now, what they're exploiting here is this is, in fact, an ASP file. But the web developer is not doing MIME type checking on this particular application. It's a common flaw. So they're not looking at the contents of the file. They're just looking at the name of the file and assuming that the two things line up here. Now, in this case, the threat actor accidentally uploaded a web shell for the wrong version of ASP. So when you look at the logs, you'll start to see alerts firing here. that, hey, I've got a 500. This doesn't execute. So the threat actor continues to try web shells, almost as if they're just brute forcing the problem here. And eventually, they get one that actually

lands after switching to about a dozen. So suddenly, they now have the ability to run RCE, full remote code execution on your server here. This file, their file is now sitting on your server. And they can then use this to start pulling in their next couple of stages. So this is PowerShell Empire. This is Mimikatz. This is all the things. They can do it right through their web console here. And then they can pivot into all the GUI pieces of your network back here where you don't want any threat actors accessing your technology. So this is a really old technique, but it's still really, really current. And it's shocking. that we don't have ways to mitigate this or we don't seem to have ways to

mitigate this. Let's take a look at the bro logs for that and I think you'll see a different perspective.

Something on the back when we got signal trained up again? All right.

Excellent. So on the network side, you see these post requests up to the web shell here. This one is actually called API.asp.gef. But you can see the internal server errors where they were previously trying to get to the previous version of the web shell. So what does this look like if we

want to emulate this. And you guys can all, if you have a mobile device with you right now, you can pull out your phone and you can emulate along with me. So I published this to the web here. And what we're going to do is we're going to spin up a quick little web shell. And this is a web shell that is posted on my GitHub. And I've already got it compiled and put it into a Docker container for you. And all the instructions are here if you'd like to do that. But the web shell is very simple. What we do is we just look for anything that's passed the forward slash exec. And we

turn around and we execute that against the operating system. So if I do exact question mark command equals, it'll just RCE that on the box. So what I've done is I've just given you a trivial way to just experiment with this on your own time. And then I took this and I wrapped this around a little GUI for our example that we're going to have here. And I've loaded this. particular web shell now into four different containers for you to play with. The first is treating a container like a virtual machine. It's a from Golang container and it's about 800 meg. Then I did a from Ubuntu which is a little over 100 and then a minimal container distro called Alpine and then the

preferred way which is from scratch. When we're building things from scratch this is where you start to have these realizations when you're in security about how truly far ahead some organizations are in these paradigms. Now, if you're not familiar with what Scratch is, it's following this trend of allowing you to have a smaller and smaller footprint, but on the application side. And you can use this programming language called Go, if you're familiar with it, to compile all of your dependencies into your binary. So this is the only thing you need to ship in your container. So there's nothing else that's sitting in there. And when you think about, when I had that realization that not only was Go designed 10 years ago, but it was designed specifically for containerization,

which had yet to sort of rise to the forefront of technology that it's in today, you have one of those moments that truly should be humbling in your career. When you think that there are people out there that really have a deep understanding of this problem and are building the future. And now we can leverage that future in order to increase the strength of our applications. Now what's interesting is that containerization is not perfect. And these tags that you can throw in a container don't actually mean anything. So from latest, it's just a tag that's thrown on a container here. And this chart is a little old. This scan was from a few months ago when I first did this demo.

But just out of the box, there were vulnerabilities baked into these containers that had not been patched yet. Just the update frequency on what I pulled from Docker Hub was not there. But when I was deploying on Alpine a minimal container distro with just a bare shim to run my application, or even better, from scratch, I didn't have to worry about any of that. So what does this look like? So if you take out your mobile device or your laptop, and you can go to three different versions of this right now. You can go to scratch.liamrandall.com, and you can go to fedora.liamrandall.com and you can go to alpine.liamrandall.com. And let's start on the Fedora one here. And you guys can't see the

top of my screen. Let's move this around. Better. All right. So this is Person Facts. This is a totally fake company that has the best Person Facts. It's smart, gorgeous, and insanely fast. And it's available at all times. And as I mentioned, Person Fax has inadvertently deployed a web shell. So I have full RCE into this environment. I could pull down code. I could pivot. I could exfil. I could do anything I want. Let's do something. Let's go like cat and then ampersand and then arg equals slash edc password. Perfect. I can do all the things. And my life is terrible, and I'm sad, and I lost all my data. Translate this page, shall we not? Now let's look at a slightly smaller footprint.

Let's take this right side of the equation, and let's take the application footprint down a bit smaller here. And we're going to exec command equals ls. I can look at what's there. And I could also do something like cat, let's see, arg equals nc password, whatever. These are up right now. Do your worst. Play with all the things. Destroy all the boxes. I'm going to nuke everything after this talk anyway. Now let's look at a different version of this. Let's look at the from scratch. Now so when you think about this logically, think of a big empty shipping container. with just this application in it. There's nothing else. So even if I have full RCE on this box,

what can I do? Command equals ls. I don't even have ls. In fact, the only thing that I can try to do here is to run my application again, which doesn't work because it's already bound to its default port in the container. So a very powerful but simple demo that shows moving your applications towards this declarative future, these minimal footprints, and running them on these large platforms can dramatically increase your security posture by decreasing your vulnerability footprint. But I think what's most interesting is if we take this particular trend and we start to follow it forward, what does the near future look like? Just to show you the minimal OS example there, this is the from scratch Docker file. There's only four lines in it from scratch, and then

I put in a certificate, I added my binary, and then I set it up to execute on start on the bottom right there for that web shell. And what does this mean is that when I was in college 20 plus years ago, we always talked about this idea of utility infrastructure. And it was always a joke because it was never real. But this is actually what is happening now. The near future looks a lot more like the electrical grid in technology than it does. When you think about the power grid, for example, you get this declarative guarantee in that wall outlet right there. You get 120 volts at 15 amps. And in front of the electrical outlet, I can do whatever I want. I can plug

in my lamp. I can plug in this outlet. I can plug in my phone. And when I need more power, it's seamlessly provisioned for me. And behind the outlet, my DevOps people can do whatever they want. They can bring in power from solar. They can bring in power from nuclear. They can bring in power from wind. It doesn't matter to me. From coal. So long as we meet at that declarative point. And this is what's happening now is that on the outside of the plug, you've got the container. And then behind the container, you have Kubernetes right now. But I'll tell you that it's not about Kubernetes. The technology specifically doesn't matter. The only thing that matters is the guarantee that you're given. And if you are deploying

things at large scale, if you're a Google, if you're a Facebook, you're already leveraging these techniques. There's a reason why we hear less about some of these mega providers getting compromised. And I believe one of the main reasons why is that they've been the first to usher in and adopt these new techniques of declarative application postures on declarative platforms. And the sort of vision for where we're going here is exactly like the electrical outlet. That I can take my app, I can walk over, and I can just say app.run, right? App.deploy. I don't even have to think about app.scale because the metrics do it for me automatically. And if you're following Kubernetes, this is what people are working towards. It's this sort of highly available infrastructure that

takes the pet out of the equation. But I don't care about SQL01 anymore or SQL02 because they're all just cattle to me. And if one of my cattle gets sick, like my web shell I just deployed, well guess what? I just kill it. In fact, I just kill it and scale it, which I'll pass on that demo for right now. If you want to see that afterwards, I'm happy to sort of do that. Now the kind of big caveat here is that, Liam, that's awesome. The future's going to be amazing. We've got flying cars in. My life sucks because I deal with these things called capital assets. And we just put an aircraft carrier to

sea, and it's not coming back for 25 years. So we're stuck with what's on it today. And we've got these power plants, and we've got buildings, and we've got legacy financial companies, and we've got factories and assembly lines. I'm going to put a pin in that for a second for two reasons. One, if you want to see OS Query and Bro and Sysmon, just go on YouTube and watch my previous talks. But these are... Symptoms of people problems. Because we can bring innovation into these environments. And that's going to be the call to action that I have at the end here. But on this utility model of computing, this is a huge opportunity. For some of you, it will be a huge crisis. Because

your bread and butter is going to go away. When you think about the security model that happens with a utility model, imagine evading the GFIC on that electrical outlet over there. Imagine evading the fuses. You can't. Because it's baked into the underlying stack. And in the stacks and applications that we've been building, this is how we deliver our controls. We bake things like SC Linux into the platform. You can't turn it off. We bake things like container controls. We bake in our layer 3, layer 4, and layer 7 controls. We've got protocol analyzers implemented in the Linux kernel. So when you're thinking about how would I run something like Bro in the cloud, what you're really asking is how do I do large-scale protocol analysis in the cloud? What

you really should be asking is, do I need to? If I know that all of my containers only have a single binary in them, and I know that it's HTTP or whatever this transport protocol is, how many full-spectrum protocol analyzers do I need? This is a huge opportunity because everything that happens in the CISOs world is being reimagined right now. And there's an absolute frenzy in thinking, how do you do monitoring in this world? How do you do alerting in this world? How do you do forensics in this world? How do you do incident response in this world? These are still nascent ideas at best in this future infrastructure that's being adopted today.

So let's come back to one of the two root problems. The first being the user and the second being capital assets. And I want to give you a quick crash course in the psychology of app development because I want you to understand what we're up against. when we're talking about influencing our users. When we think about how we, if we want to change our users' behavior, it needs to be motivated by this idea that we want to deliver more value to the customer. And we can do that accepting how the customer works. Accepting the weaknesses of the customer, we can actually work with them to make it happen. I'm going to show you another quick video here. from one of the founders of one of

the early hires at Facebook. Exploiting consumer behavior in a consumer internet business. You said that this is a time for soul searching in social media businesses and you were part of building the largest one. What soul searching are you doing right now on that? I feel tremendous guilt.

I think we all knew in the back of our minds even though we feigned this whole line of like there probably aren't any really bad unintended consequences. I think in the back deep, deep recesses of our minds we kind of knew something bad could happen. But I think the way we defined it was not like this. It literally is a point now where I think we have created tools that are ripping apart the social fabric of how society works. That is truly where we are. And I would encourage all of you as the future leaders of the world to really internalize how important this is. If you feed the beast, that beast will destroy you. If you push back on it, you have a

chance to control it and rein it in. And it is a point in time where people need to hard break from some of these tools and the things that you rely on. The short-term dopamine-driven feedback loops that we have created are destroying how society works. I want to pause right there. And I want to talk a little bit about the idea of what he's saying. Let's talk about what are these techniques and tools that we're all susceptible to and how do they influence us. First, we're going to talk about the psychology of applications and the sort of derived psychology of application security. You have to understand what human beings are made of. And the mind as we understand it today sort of operates

at three different levels. The first is the central core. This is the reptilian brain. I'm not going to dignify this one with any examples, but essentially it's, you know, can I eat it? Can I have sex with it? Will it kill you? And you are familiar with all that advertising, right? It's plastered on billboards. It's in commercials. It's in movies. You can't get away from it. The next is the most susceptible layer, and this is the limbic system. And these are your emotions and your behavior and your moods. And these are very subject to unconscious influence. And the final is what you think of as you, is what you think of as your deciding brain, the cerebral cortex, your conscious, your reasoning. And you

can certainly make arguments and say that these things are better, but there are underlying, I'm going to say, influence techniques that you could leverage in order to carry the day that you should be using first. Let's just look at a small sample of these because there are hundreds. So let's talk about the goal gradient effect. And it's rooted in the fact that people are more motivated as they approach a goal. But what's fascinating is that you can actually drive behavior and motivation with an illusion. If I give you two membership cards, each that have 10 left before you get a goal, the studies show that if the first two were stamped, you know, 12 on this card, 10 left, blank on this card with 10 left, you will be

far more likely to actually complete the one that has the illusion of progress. And it's sort of baked in there, rooted in the idea that you're invested in that idea. The variable rewards, or the idea that built Las Vegas, right? And this is the, when you want to incentivize behavior, it's how often do you give people their results? And your desired results could be anything from likes to to Reddit Gold, to Hearts, whatever the case is, it could be additional space on a storage network. But delivering them in a variable way ensures a higher degree of addictivity. The dopamine system. The wanting, what drives searching, is far more powerful than the liking. In rats, for

example, if you disable the wanting, Even if they still have the ability to eat, they will actually starve. They have the ability to physically satiate themselves, but they can't drive themselves forward. So being able to take advantage of those systems. The unpredictability stimulates dopamine, and these small bite-size alerts that you get on your phones, that you get on your little app notifications, are triggering you at that middle emotional layer. They're driving you forward and driving your behavior forward. Now when you start to learn even the basic rules of this game, you start to see the psychology of application development. And when we think about as a security industry how we should be driving forward positive behaviors of change in our users, we should be doing

a better job leveraging these techniques as well. I'm sure for the social engineers in the room, this sort of little blurb here doesn't come as any surprise to you. The confidence game is a long and well understood far before social engineers started to use it to test networks. But when you think about being rewarded for being three steps away from the bonus here, having a goal gradient of starting with your list items already crossed out, having a milestone already laid out for you, notifications tying into your social network, these things are subconsciously triggering you whether you realize it or not. So is it completely hopeless then? We're stuck with capital assets and we're stuck with

users that are easily manipulated. I'll say no and I'll look around this room as the evidence as to why not. And that's that the evidence that exists today as far as why are you here in this room this morning is that we are each called to a self-directed challenge, to drive a self-directed challenge to pursue technical expertise, mastery, and making a contribution. When we think about why people are here this early in the morning studying security on their own, it's because they're driven by passion. And I think that when you look at the sort of derived things we see in our industry, the derived positive things, this is what gives me hope. This is what has kept me on the road teaching the

170-some-odd-brobe workshops that I've taught. I used to do that commercially, but for the last five, six years, we've not been charging for those. We just show up and we teach a class. It's fun. It's to drive the mastery for myself. And I'm hopeful that if you're here, you also have those similar types of drivers. Let's take one last little video here. Sorry, not the right link.

Go back in time a little bit. I imagine this if I went to my first economics professor, a woman named Mary Alice Shulman. And I went to her in 1983 and said, Professor Shulman, can I talk to you after class for a moment? Yeah. I got this inkling. I got this idea for a business model. I just want to run it past you. Here's how it would work. You get a bunch of people around the world who are doing highly skilled work, but they're willing to do it for free. and volunteer their time, 20, sometimes 30 hours a week. Okay, she's looking at you somewhat skeptically there. Oh, but I'm not done. And then what they create, they give it away rather than sell it. It's going to be

huge. She truly would have thought I was insane. Okay, it seemed to fly in the face of so many things. But what do you have? You have Linux powering one out of... It does sound insane. And it sounds insane when you think about things like the open source community, things like the security community. When you think about the resources that we pull together as a team, the information that we share. The keynote from last year was this amazing tour of the room almost, where the speaker walked around the room and talked about all the amazing contributions that people in the room had been dropping. And those are the things that give me hope that we

do in fact have a path forward to bail our way out of these capital assets. So when we're thinking about what the sort of call to action here is, is that we really have this challenge to enable innovation. And if you're in a large organization, that's a big problem. If you're in a government agency, or if you work for a Fortune 500, and it's that execution eats innovation. When you're executing a model, you spin up around that model, you metrics everything, and you drive out all deviations and difference. And when you are innovating, You actually, by design, want to make mistakes very quickly. It's your job to make mistakes very quickly. But to execution, that innovation thing down there, that nascent little seed

looks like a weed. We must drive that out. We must kill it. We must stomp on it. Now, there's been a huge emergence of business model thinking that started at Berkeley and other places around the world. But it's been coupled with folks like IDEO. And that's that products can be built that have a blend of desirability, feasibility, and viability. That desirable, I can have a new method to build products that my customers want, that they're feasible, I can actually accomplish these things, and that they're viable. I can spin up an open source business model, for example. I can spin up a financial model where I give away my core product for free. Think about like Google. Google gives you free search. That's a good value

proposition for you. You'll spend a lot of time on that. That gives them a new key asset called all of you that they can turn and sell to advertisers. That is a phenomenally powerful business model that's driven with some very simple principles. These are the tools and techniques we use at work, but we've adopted this methodology called jobs to be done where you sort of get really deep and you're looking for jobs that are both important, tangible, lucrative, and unsolved. And you recognize that around security, we do a good job with the functional jobs. We'll release these core engines or frameworks or concepts or ideas that are very functional that get the job done, but

they leave undone many of the productization pieces. The emotional concerns. Can I use this? Can I be successful? The social concerns, how does my boss look at me for using an unsupported tool? The supporting jobs, how do I install it? How do I upgrade it? How do I run it? And my call to action to you is to think about where you can start to adopt these techniques in security. So at this time, I want to pause real quick, and I just want to pause for some questions.

OK, thank you for your time.