ant to fix in some manner. But there's a lot of tests included in here. And I can talk about picking and choosing the ones that we want in a minute. Overall, there's 26 total controls, so there's 26 objects that passed and 27 that failed. We're talking to 53 objects. And then individual tests, there's 125 individual test lines that the thing is going through and investigating. So there's a whole lot of stuff that is in there. The joy of this demo is that it changes almost every time I run it. So the last time I updated my slides, which was like Thursday, there were slightly different numbers. So you get a report on how many successful controls you have, how many failures you have, and you can work from there. So one of the things that the DevSec community has put together for us is remedial components. So I can go through and I can actually fix these. And they're supposed to match sort of one to one. There are, this one is a Chef Cookbook, but there's also stuff for other configuration management tools that we choose to use those. So what this helps us do is look at that host and say, all right, I have all these bad things here because it was just a default image. It doesn't meet my requirements, but I want it to because I want to be able to do Dev on it or whatever. So I can go through and use this companion to fix everything. So I'm gonna use Chef to do that. And so InSec detected some issues and I'm gonna just use a quick example of what we call policy file and not use a Chef server if you're familiar with that at all. And we keep all these on a site called the supermarket which allows us to sort of share things out. They're also available directly from GitHub. So I have a policy file that I'm going to run. And in this case, I'm gonna call it server hardening so I know what it's gonna do. It's gonna talk to the supermarket and it's going to run this OS hardening cookbook that the DevSec community has published for us. So I'm not going to worry about connecting to a Chef server and download all this stuff locally. So in true cooking show fashion, we have one here. Okay, so server hardening. We'll talk to the supermarket and then we'll deal with our run list there. We'll see how this goes. You're gonna install it and then export the components and then run the Chef, make sure I get all my typing correct here. I'm just gonna copy it. Okay, so at the end of the day there, we talked to 206 resources, 141 of them needed to be updated. That's that last line there. So there's all kinds of things that get touched, right? Cause there's all kinds of things that were wrong. And so the whole workflow sort of function is that I'm asking the system to get hold of some publicly available cookbooks. We're gonna download them. I can see the versions of them there to see how they line up maybe with other requirements I might have. And then it just goes through and starts fixing things on the system, right? So I'm root here and I can change as many of these things as need to be changed. So all kinds of stuff gets touched. Now we hope that this fixes all those errors that we had from the Linux baseline. Let's see what happens. I fixed most of them. Okay, let's see how close we are this time. I had two the other day. Let's see where we are here. So we can scroll up. Oh, this one, this one always happens. So my requirements for AuditD aren't met. I have one particular control, package 0.8, that is not fixed by my remediation cookbook. So now I have to decide, all right, well, how much do I care about this? I don't know, let's find out. We can talk to our security team and figure out what they think about it. We can investigate with the other folks that we're working with to see how much of it we really need to do. So when I ran this the other day, I had two failures. It was package 0.8, and then it was also some file system stuff, no worries. So I have to find the controls that aren't passing. I decide if I wanna fix them or forget them, as it's totally possible to do either one. If I wanna fix them, then I'm probably gonna go into my configuration management code and make some adjustments and change some file settings around, things like that. If I wanna forget them though, that might be interesting. So what we're gonna do, we're gonna build a new profile around little spacevine to exclude the things that we don't care enough to fix right now, right? So at some point, my security team hopefully will give me a new configuration for this and that would be great. In the meantime, I wanna keep working and we've decided that for what I'm doing, I'm not too concerned about this right now. If it were something super serious, I'd wanna get a fix, but we're just going to exclude it. So profiles have the ability to bring in profiles from other places. So these sort of default ones that we've published, super helpful sort of in the generic case and I can use them, I can ingest them around the other settings that I might need. So if I'm actually doing some specific tests around Tomcat platform or some other application that I'm working with, I can use my links, spacevine, inside of those larger profiles that are more specific to me. So I have my application profile, it might have controls that are specific to my problems and my particular environment and then I have sort of this generic one that's down here. What I can do, I include all of the controls, maybe by default, but I can also come in here and I can skip the ones I don't need anymore or the ones that I've decided to just sort of ignore for the time being or maybe aren't appropriate for my particular environment. I don't wanna turn off SSH or I don't wanna turn off cups on my print server or whatever the case might be. So I can actually do that. So I can create myself a new profile and InSpec has a bunch of tools to allow you to do that so that you get all of the files that come along. See if I put one in here already. I did not. Make sure I get my, yeah. So I get sort of this default package, right? And there's two places that are super interesting. One of them is the inspect.yaml and the other is the controls directory. So controls directory is where all those RB files are stored that have all the tests in them. And I have one in there so far. But inspect.yaml has the configurations that allow me to bring in and consume other profiles. So in this case, the one that I'm working with is Linux baseline. I can consume it in a number of different ways. I already downloaded it. I have it locally and I could use that version. But if I wanna save this profile and use it in different places in different times, I can actually just talk to Git and say, hey, you know what, just go out and pull out the latest version and we'll work with that. So in this case, what we've done is we have our hardening profile and we've allowed it to depend on the Linux baseline but directly from Git rather than from a download. So it's gonna go out and investigate the Git repository and bring down the new one as it runs. And then I'm going to tell my controls that I want to include the controls from Linux baseline. That's all the good stuff that we saw before. But at OS 10, that's super annoying one or I guess a package or eight that I'm gonna fix here in a minute, I'm going to ignore that. So I'm gonna skip that control so that it doesn't fail my stuff anymore. So then when I'm ready, everything is green. So I'm up here, I'm checking all this stuff and all the things that I needed. I have my version of my local profile and there's nothing in it, right? And then I go out to this version of the Linux baseline and there's all the things that it tested for me. So I can just consume these profiles in this manner so that I know I'm always getting the latest version. I don't have to be the person writing those, I'm just using what my security team, what my compliance team has written for me. So it's super easy for me to consume that that way. Rather than thinking about how many bash scripts I have to use after I build a host or the other things that end up being checked. So there's what that looks like, a little bit larger. So in fact, we'll find or retrieve the included profile. You can choose to use all of it or just pick a few things. If you only want a handful of those controls, you can do that as well. And you can exclude the ones that don't meet your needs like we just did. And then you create a new file and you can manage all the other components that way. So we skipped package 08, OS 10 was from Thursday. So something changed in the meantime. And then we get all green return on our profile. So now I have a host that is compliant with my requirements for my group and can move forward. And it was just a basic host off the line at Amazon. It wasn't in a special image or anything else that I built. But because I'm using these components this way, I can turn it into a good state that I can now use to move forward. So there's other stuff that InSpect talks to you. There's constant work going on with InSpect. It's very much an in-process service. We're working with the cloud providers to provide tests for resources in the cloud, right? So if you hear interesting stories about people who publish documents to S3 buckets and then open those S3 buckets inadvertently to the world, super interesting to read everybody's grades off an S3 bucket, but it's probably not what was intended. So there's ways to test that kind of thing. So unintentional misuse of complex setting in these environments, we're gonna be able to help you to make sure that you're doing them correctly. And then our CIS, we published the full CIS profiles as part of a commercial subscription. So they are available, they've been certified. Test Kitchen, as I mentioned earlier, InSpect will also run as a test suite in Test Kitchen. So if you are doing active configuration management programming, you're creating your cookbooks or modules or whatever, Test Kitchen will make use of InSpect for testing those components. There's a number of YouTube videos and some other good content on that, regardless of which tool you choose, but you should be using Chef. So that's more information about that at kitchen.ci. Finally, resources about where you can find more information about InSpect. InSpect.io is the current home of all things InSpect. DevGest.io is the InSpect community. So it's folks that work for us, but also folks that work for other groups that are working with InSpect. There's a couple of interesting stories here then too that I've highlighted. One is Annie Hedgepeth. She had a series of blog posts, they're a couple of years old now, but the main information is still correct.  And she had been in the creative space before. She wanted to get into tech and her husband's one of our customers. And she went through and was like, I'll learn InSpect and see how that goes. And what she did out of that was create this series of blog posts about how she was learning InSpect and how things were going. And it's a really nice step by step discussion of how you think about InSpect and how she was associating to it having not really been in tech before, right? So instead of different beginning assumptions, I guess you could say. And it's actually really good. There's another set of stories about, this one in particular is about Dirty Cow, just about how this particular organization went through and investigated their systems and remediated their issues. And then we're sure they were always being, always correct by InSpect. These slides are already up on SlideShare. You can find me, slideshare.net slash lnxchk, all my stuff is there. The workshop version of this is also up if you're interested in that. Finally, we'll have new stuff about InSpect coming in May. May is our big conference. It will be in Seattle this year. We have content coming from some federal government contractors about how they're using InSpect and compliance in their environment. We have some folks talking about these digs and some approaches on that side. And Google's coming to talk about generating these tests automatically in a couple of different ways with some libraries they have. There's really good content coming with InSpect in the near future. Having said that, I have five shift cost tickets if anybody would like to go. And my marketing person wasn't super helpful in like deciding how we should give these out. But if anybody would like a shift cost ticket, I'm happy to give them to you. And I'm also happy to take whatever questions you have. We have about 10 minutes left, so if you have any questions. Yeah, so the question was that log in the output when you disable a test under a couple different levels of the output it will. Otherwise, it suppresses that. So you don't have extra output for things you're not running. Yeah, yeah, exactly. Anything else? Has anybody run InSpect before? Are you all new to it? Yeah, a couple. Okay, awesome. Very good. Oh, okay, yeah. So Lance over here is, they're converting from service back. So if you're familiar with service back and you're like, this kind of smells kind of the same. Like it certainly didn't happen that way. Service back being sort of an older project was really good, right? Like they launched it at, I think it was on ignite at velocity in like 2013 maybe. Really interesting. And the genesis of InSpect sort of taking that idea and sort of going into these profiles and some other things that service back didn't really then go in that direction. So it ended up just a little bit different. Yeah, also a very good tool for working on these kinds of things. Awesome, thank you. I have some info card to the front if you would like the links and that kind of stuff in a printed version. Also card for our LearnChef project that has tutorials and videos and that kind of stuff. If anybody would like to visit us in Seattle, please come up and get a ticket. Yeah, email Susanna and she will hook you up. Test, test, test. But anyway, so I'm testing this one and you're talking in that one just at the same time. Test, test, test. Okay, so. Whoa, whoa, whoa. Yeah, hello, hello. Test, test, test, test, test, test, test, test. Testing one, two, three. Test, test, test, testing one, two, three. Testing one, two, three. Testing one, two, three. Yeah, awesome. So if by chance something happens and I've got to turn that down, can you show me which one it is? Okay, cool. Do you have my computer audio? No, not for this. Test, test, test, test, testing, testing. Probably just gonna be me and you. Can you guys hear me all right? Probably don't even need a mic, but we'll use it for the... Let me know if this gets too loud. I can adjust it. Okay. I wish. Anybody need more stuff to take home in their bags? So find disc. Take home to your kids. Find disc. Find disc. Find disc. Hey, almost got it. I used to be able to throw real frisbees, but that's exactly right. Yeah, I got in trouble because my accuracy's not so good. And my boss got nervous and he said no more hard find discs. Yeah, that's, I'm shooting for that. Thank you. So we still got another minute. Get started. So you guys probably deserve some sort of medal for being here for the last talk, talking about security. And so hopefully we'll make it worth your while. Simus is the open LDAP people. Open LDAP. Have you heard of that product? Yep. That's where the maintainers provide commercial support. Okay, it's time to get started. So this is the anatomy of a secure Java web app using Apache Fortress. And for the next hour, we are going to be thinking about how to secure web apps if we pulled out all stops. That's me and my timeline. I've been at this for a while. I like to tell people when I meet them that I've made a pretty good living, writing bad software. And then the follow-up is it's all bad software. There's a lot of bad software out there. When I'm not riding my bike, I try to get some work done during the day with the software architect with Simus. Again, they're the open LDAP people. And I'm Apache directory PMC chair. And I moonlight with open LDAP. So our agenda is we are going to have a little discussion about security breaches real quick. Talk a little bit about vulnerability scanning before we get into the main topic, which is really end-to-end security based on a couple examples. And along the way, we're going to look at some security principles to try to explain the rationale for the approach here.   And so if you try to take notes, keep up and probably be a little overwhelming. So these slides are published right there. My contact information will be at the end. Actually, you've got my business card and those flying discs. Just contact me if you want to copy the slides. What I want to do is have a conversation about security with you guys. So, you know, I'm going to throw some stuff out, try to keep me honest, and let's learn together. Okay, I like this quote from John T. Chambers. There are two types of companies, those that have been hacked and those who don't know they've been hacked. This one's mine. It's not a network as much as an ocean, not a tear machine or container, but islands separated by miles of hostile waters, almost be attended to and defended each with unique challenges. Okay, so this problem statement we're going to be coming back to. This is going to keep us focused. But our goal is we're going to try to make our systems more resilient to cyberattack via the application of a few common security principles. Okay, so what's the problem? This is 2019. Why are we talking about security breaches? Are things getting better or are they getting worse? Those right up there, those are the top five breaches of 2018. Those are in numbers of users with their personal information exposed. At the top, that's a B as in billion. Not to pick on those companies. This is a widespread problem. What's going on? Why is this, why haven't we figured this out yet? Why are we still talking about breaches and exposures? Is it a technology problem? Is it a process problem? What is it? Thank you. For example, you get a prize for that. This is the one I've studied, Equifax. I think that was one that really kind of, that might have been a tipping point. They disclosed a breach in September of 2017. 150 million people in North America and United Kingdom had their personal information exposed, including their social security numbers, birth dates, addresses, phone numbers. Probably everybody in this room. Had their personal information exposed. I know I did. Who's Equifax? They're one of the big three credit reporting agencies along with Experian and TransUnion. You may not know who they are, but they definitely know who you are. They're keeping almost a billion. Consumers information, they're up to almost a billion. They are a very large company. Remember the Fortune 500, got 9,000 employees. What's up with that? So what happened at Equifax? Specifically, it was CDE 2017-5638, which is a vulnerability in Apache Struts, which is a web framework for the Java platform. It's a commonly used web framework. It was a vulnerability that was detected out in the wild in April of 2017. And for whatever reason, Equifax chose not to apply the patch. Couple months later, in the early summer, the attackers breached their website and that went on for a couple months before it was discovered. And in September of 2017, Equifax actually disclosed the breach. What happened specifically? How did it work? It's called a remote code execution exploit. In this case, the attacker tricked the website into accepting a string of data that was executed as a command, a system command. How exactly did that happen? Within Struts, there's a library called the Object Graph Navigational Library, OGNL, which has been a target of exploits like this before. And you have kind of a string of data that looks something like that, that gets uploaded in a header and it gets interpreted via the Java runtime. This is contrived. We're executing a calculation command there, but in the actual attack, they installed malware on the server right and then that was the beachhead that they were able to set up shop and then eventually do their work. If you're interested in this, there's a webcast by Blackduck that goes into the forensics deep dive. They talk about what tools were used, how those tools were used, how could that be done? It's simpler than you would think. So again, the exploit was disclosed in September of 2017 and there was quite an uproar about it in the press, as you might expect. And the fingers came back to Apache Struts team and they were catching some heat and as a result of that, the vice president of the Apache Struts team, Renee Guillen, published this statement on the Apache Software Foundation website in response to the uproar. And we're gonna look at some of the things he said because I think it illustrates some of the problems and some of the things we can do to get around it. So this first paragraph here, Renee says, establish a process to quickly roll out a security fix release of your software product once supporting frameworks or libraries need to be updated for security reasons. Best to think in terms of hours or a few days, not weeks or months. Most breaches we become aware of are caused by failure of the software components that are known to be vulnerable for months or even years. And indeed that was the case with Equifax. They chose not to apply the breach or I'm sorry, they chose not to apply the patch which would have prevented the breach. So back to our problem statement, how can we make our systems more resilient to cyber attack? The solution must be to ensure all appropriate patches have been applied. Okay, we can do that. There's some tools out there that are useful for that. The old lost dependency check mechanism actually works on several platforms, Java.net, Ruby, Node.js, Python, CC plus plus and what it does is it compares the dependencies in your application to the list of vulnerabilities in the libraries in the IST database and it will spit out a report and so you just look at that report and then you can fix those libraries or update them. So this is a Java talk. And so these are the tools that you can use to run this mechanism on the Java platform. There's an ant, Maven, Gradle, Jenkins plug-in. So I use Maven in my projects so I would apply, you know, enable the plug-in in my POM file like this and you know, I'd run that target on a release cycle and it would flag any vulnerable libraries and then you would just upgrade the version and life is good, right? Or is it? Let's go back to Renee's statement on the website. Any complex software contains flaws don't build your security policy on the assumption that supporting software products are flawless especially in terms of security vulnerabilities. So that gets back to my earlier statement all software is bad.  It's extraordinarily difficult to understand all the different ways that a piece of software is going to be used. And so I would assert to you that the list of unknown vulnerabilities is orders of magnitude larger than the list of known vulnerabilities. And there will never be a scanner that can detect them all. That's impossible. So what we do about that. Back to our solution, which is in response to our problem statement, how do we make our system more resilient to cyber attack, practice the principle lease privilege by enforcing mandatory access controls. Principle lease privilege is in a particular abstraction layer of a competing environment. Every module such as process user program depending on the subject must be able to access only the information and resources that are necessary for its legitimate purpose. Mandatory access controls, restrictions on even administrative users can be enforced at a granular level. Okay, so there are a lot of different ways to do this depending on your platform and your operating environment. Linux, you've got positive security controls, things like sudo, and you can file permission certainly can help you here. We've got SE Linux for Red Hat, all sorts of things. Well this is a Java talk, one of those things that we have in Java is the Java security manager. So are we Java guys here? Anybody use the Java security manager? Yeah, so that's really been my experience is nobody uses the Java security manager. Why is that? We'll get into that in just a second. But it is a way in which to enforce mandatory access controls. So as soon as you enable that Java security manager in the runtime, everything's off by default. So things like opening up a socket to a website, reading and writing the files, executing files that's turned off by default, and you have to enable it via permissions. So if you've got some kind of remote code execution vulnerability in your application like Equifax did, if they had been using Java security manager, it wouldn't have happened. Okay, so this is gonna be the first of four examples that I'm gonna show you. It's called the remote code execution sample. It's in my public GitHub account. These are all available for you guys to use. But we're gonna just take a little test drive of the Java security manager in a sample app. So this sample app has a readme, which explains sort of the rationale of it and kind of sets it up. And then it explains how to basically download it, build it, and run it. So when we run it, we are gonna execute this program. There's actually three examples in here. We're gonna do the first one. And it's just a simple application that simulates one way or remote code execution vulnerability can occur. So this is a contrived example, can you guys see that, okay? And it's basically kind of doing everything for the lifecycle of a serialization exploit in one app just to kind of show you how the security manager can halt it. So it's kind of, you've got this first part where an object is being instantiated and serialized. That's what the attacker would do in this case. And then they'd send it over the wire somehow, presumably they'd upload it to a website. And then when the website deserialized it, that's when the exploit occurs. Here's the object in question. And so in this case, again, it's a contrived example, but what's going on inside of this object is that it's basically running a script here, you can see with the runtime. And that script is kind of a silly little script, but it just basically takes the .cpassword file concatenates it into another file and the target directory that the program's running in. So let's go ahead and run this and show you how this works. Can you guys do that, okay? So you can see here, or can you see that? I can actually zoom in a little bit. That better. That's too much. So you can see there that we are enabling the Java security manager right here in the runtime. And so we're just gonna execute this app and it runs. And basically the exploit was successful. I look at the target directory and you can see there's a file there you've been hacked, which contains my .cpassword file. So let's look at the Java security policy right here. And you can see that there is a permission being granted for this hacker script to run, to execute. Okay, so no one would ever allow that in their right mind. So practicing the principle of least privilege, you only allow what's minimal for this application to run. So if we comment this out and run it again, you can see that it failed with an access control violation right there. Okay, so access denied, can't execute that file. So that's just a very kind of a simple example showing how the Java security manager can prevent things like remote code execution exploits. Again, that sample's out there. If you wanna try it out, there's a couple other types of things in there as well. It's not a perfect solution, that's why nobody raised their hand. Supposedly it's got performance implications. I think those are overblown, especially with respect to the security implications. You know, hardware's cheap, remediation's probably not so cheap. But there's a caveat or two. One is it doesn't play well with reflection. Reflection is Java's dynamic instantiation framework, pretty much used by all the parsers. So in order to do something like using the job security manager in a Java runtime, how to suppress access checks on reflection, which is another open door. Reflection is another way in which some attacks can occur. So it's not a perfect solution. But it is a tool in our toolbox and it certainly will give you good information about your application. So even if you don't run it in production, it's kind of a nice thing to just run it in a test environment and look at what your application's doing. Look at all the resources that it's accessing and that might give you some insight in how to protect it going forward. Okay, so it's not a perfect solution. What now, do we just kind of hope for the best? Let's go back to Renee's statement. He's got some pretty good insight. Look at this one here. He says, established security layers, good software engineering practice to have individually secured layers behind a public-facing presentation layer such as Apache Stress Framework. A breach into the presentation layer should never empower access to significant or even all backend information resources. Back to the Equifax exploit. The attackers use the vulnerability to pop up a web shell on the server weeks later and managed to retain access for more than two months and were able to pivot through the company's various systems by obtaining an unencrypted file of passwords on one server, letting the hackers access more than 48 databases containing unencrypted consumer credit data. During that time, the hackers sent more than 9,000 queries on the databases, downloading data on 265 separate occasions. Huh. So it's probably a little bit more than Apache Struts going on there, right? So let's go back to our solution. Again, with respect to our problem statement, how do we make our systems resilient to cyber attack? Let's add something there and say apply defense in depth. What is that? The building up layering, overlapping of security measures is called defense in depth in contrast to a metal chain, which is only as strong as its weakest link. The defense in depth aims at a structure where should one defensive measure fail, other measures will continue to provide protection. So that's where you get this onion where the data is surrounded by the applications, surrounded by the hosts, surrounded by the network. If one defensive measure fails, another one picks up the slack. If Apache Struts fails, something picks up the slack. You don't have unencrypted files sitting around with passwords, for example. Every single node on the network should be protected. Every, even into the layers. And we're gonna talk about that right now. Okay, so this is a Java talk. I'm an old guy, right? So I don't have containers in there. But these are the layers. For the application I'm getting ready to show you, which is sample app, these are the layers that are available to us as security architects for when we wanna decide where to apply controls. Do you apply controls in all those places? Yeah, maybe not, depending on your use cases. But it's best to be aware of them and know that they're there. So these layers are gonna be specific to your operating environment if you're operating inside of a PaaS platform as a service. You're gonna have more layers there, Kubernetes, whatever. It's gonna be specific to your operating environment. So this is what we're looking at for the sample I'm getting ready to show you. They don't all do the same thing. So you're not just doing the same check in every layer. They all have different capabilities. So the outer layer in this onion, we're talking about Java. I see security, we already talked about it. That's the principle of these privilege. The next one in, GSE, Java secure socket extension, that's confidentiality. Java EE security, that's another subsystem that most people don't use for various reasons. We're gonna use it today. That's the deadbolt on the front door. We're gonna talk about that in a minute. Spring security, once you can get in the front door, what pages can you hit? You know, that's what we can use Spring Security for. Web app framework, you can get in the room. What equipment can you operate? What buttons can you push? What links can you hit? That's where you would do that kind of control. And finally, down in the database, that's where you're gonna do content filtering. Okay, so this is example number two. It's called the Apache Fortress demo. This is in my GitHub account. So this is a sample web application, a traditional web application. Again, if you're running inside of something like Kubernetes or microservices, you're gonna have more layers, but you still have this inside of all that. And so there's a web application, there's a directory, and there's a database in the sample application. And so all of the infrastructure is open source. All of the instructions to set this up are in the tutorial, step-by-step guide, the software you can all use either in test or production. You can lift it, steal it, use it, whatever. So we're not gonna go through the installation instructions. What we're gonna do is we're gonna talk about these different layers and what they're doing for us. Okay, so those layers we saw are really in two areas of access control. You have kind of an outer area, which is declarative, and that's where Java SE, JSSE, Java E, and Spring live. And that means programmer unaware, right? Declareative is, you just enable it, it just works. In the inner area, we've got programmatic controls down in the web app framework and the database, that means the programmer had to do something. Now, could these controls have been declarative? Possibly. In your architecture, maybe you could do that. That's always something to strive for. Declareative is good. But sometimes the lower down you get, the harder it is to do that, especially when you start to do fine-grained authorization like we're gonna do in this application. So we start out with Apache Tomcat servo container. First thing we're gonna do is enable HTTPS. The instructions walk you through the steps that you gotta do to generate the cryptography artifacts and where you put them, use an open SSL. We're not gonna do that here. Okay, so Java EE security, that's the deadbolt. So that is really, you enable it at the container level and it does it on behalf of the application and there's nothing the application can do to break it. So that's a nice layer to have that I almost always use in any of my applications. There are specifications that surround Java EE security. This is not a Java EE security talk, but if you are a security architect on that platform, I would recommend that you get to know those specifications and know what they're for and if you're not using them, know why you're not using them. This is in Tomcat, so Tomcat is not a full-blown Java EE container, it's a servo container, so we are gonna use what's called the Tomcat Realm, which has been around forever and it's basically just a database of users, passwords and roles that are stored that are used for the security checks. So Tomcat has a number of realms that are available out of the box, there's a file realm, which you would never use in production, there's a JDBC realm where you store the data in tables and I would say you would never use that in production either, there's an LDAP realm where you use basically kind of a general purpose LDAP structure and that one's fine. We're gonna use what's called the Apache Fortress Tomcat Realm. So Apache Fortress is a project that I'm a maintainer of, we're gonna talk a little bit about that here in a moment. But basically what we're gonna do is we're gonna enable the realm at the container level and it's gonna enforce this sort of core screen policy on behalf of the application. How do you define that policy? It's in what's called a deployment descriptor, a web.xml file which specifies a contract between the application and the container and you specify a URL pattern which that's saying, hey, these are the resources that you need to make sure are secured. That should pretty much be all of them other than the logon form and the air page, everything else should be behind that and then you have a list of one or more roles. So I am prescribing this as a deadbolt, it's core screen authorization so I'm gonna say just put one role in there, one and only one role. So the user can pass authentication and they must have that role in order to get that into that app and that's sort of a fail-safe mechanism, can't be screwed up, just you gotta have that role to get in there. Okay, so in order for all this to work in this setting, we've got the Apache Fortress Tomcat Realm which is using the Apache Fortress security system policy decision point. Policy decision point is a resource server that sits out on the network and it's answering questions like authentication and authorization, authorization would be can I hit this page? Can I push this button? Can I hit this table? So let's talk a little bit about this policy decision point so that we understand the context of this. So the Apache Fortress system uses a security model that's called role-based access control. So most people have probably heard of role-based access control. They at least understand what the generic term means. The role-based access control is not really a generic concept. It's a model that's been kicked around for decades. It started out in the 80s in the academic and government world and that model was formalized in the early 90s by the team at NIST, David Ferriolo and Richard Kuhn and they basically are defining and describing what a role-based access control system should do. This model was further refined in the early 2000s by a team led by Robbie Sandu where it was formalized into a set of functional specifications that describe exactly what the different operations of a role-based access control system should do. That was formalized into the specification in 2004 by ANSI, inside 359. That's what Apache Fortress implements is ANSI, inside 359 role-based access control. Any questions about that? Oh, there's a companion spec called Insights 494. That's where you add attribute map modifiers to the equation. Kind of an A-back thing. And we're gonna touch on that at the very end of this talk. Okay, so I told you it's not a generic thing. There's a very refined and defined object and data model. In data model. And so there's kind of the entity model right there. And there's four areas that Insights 359 covers. This R-back zero, that's the minimum that a system has to do to be compliant. That's users' role's permission. Then a session. A session is really kind of the cellular feature of the R-back system. Just because that role has been assigned to the user doesn't mean that it's gonna be considered in an access control decision. The session is where the role is activated. Okay, so that's in keeping with the principle of these privilege. So that sets the stage for some of these higher-advanced features. R-back one's hierarchical roles. You can establish inheritance relationships between them, which is for administrative easing. R-back two's static separation duties. That's where you can specify mutual exclusion constraints between assigned roles. So there are possibly combinations of roles that should never be assigned to a user in conjunction. Think of something that would be a toxic relationship. And so that's a way of enforcing that at the policy decision point. R-back three's dynamic separation duties, which is mutual exclusion constraints between activated roles. So the role can be assigned, but they can't be activated together. So the classic example there is you have a check rider and a check approver. A user could possibly be one or the other in any given situation, but never both at the same time, because that would create the opportunity for fraud. Does that make sense? So we're gonna talk about that here in the demo, which is coming up. We were talking about the object model. There's a functional model, which is the shape of the APIs. So there's three broad categories. There's admin, that's how you get the policy in there. There's review, that's how you interrogate the policy. And there's system that's runtime evaluation of the policy. That's what most people think about is the system manager APIs, what you do at runtime. These are all what you would expect. Create session, that's where you would authenticate and activate zero or more roles into the session. Setting the stage for check access where you're checking the permission. Session permissions would be get all the permissions for that session, say you're in a GUI or some sort of application where you don't wanna go and do a bunch of round trips. You can add and remove roles from the session. And that's, we're gonna see that here in a sec. If you're interested in that, I've got an example that talks about what's called role engineering. That's how you would synthesize a policy in our back and you would apply it to an application and enforce it. So it's kind of soup to nuts, that's out there. You wanna check that out. Okay, so back to installing our policy decision point. There are, the policy for this Apache Fortress system is being stored in a directory. It's an LDAP server. Do we all know what LDAP servers are? Kind of a special purpose database for security. Apache Fortress works out of the box with two LDAP servers. One is a Apache directory server. The other is open LDAP. The tutorial instructions will take you through all the steps to set one of these up. You just take your pick, you'll work with either one. There's also a Docker container which will simplify that somewhat. Okay, so we've got our policy decision point installed. We're now, we've got this directory server out on the network. And so we are going to encrypt traffic because we are sending data over the wire like passwords and we should encrypt that, right? We're practicing defense in depth. So the tutorial will walk you through those steps, taking those cryptography artifacts that you generated in step one and where you put it and what bits do you flip to make that happen on whichever directory server you're using. Now we're into, we're gonna put the locks on the room doors. We're gonna use spring security for that. So that's where you establish a policy between roles and pages. To hit this page you gotta have that role. To hit another page you gotta have another role. So we're gonna use spring for that. That's still declarative. So the application, we haven't instrumented the application yet. We're gonna do that on this dep which is the web app authorization layer. Okay, so this sample app is using Apache Wicket which is a component based web application framework. So the way I chose to instrument this layer is to, I created in this sample app, secure controls. So there's a secure button, there's a secure link and the way it works is if you have the permission in your session then the button will show up or the link will show up. And if you don't have the permission then it won't show up. And if you hit the button, it's gonna check not only do you have that permission but you have that permission for a particular customer. So we're gonna be doing fine grain authorization down to the context level with this sample app. Okay, so the last authorization we're gonna do is down in the database layer. We just popped up the database server so this is in this sample is MySQL. The instructions to install that is in the tutorial. And so we are going to instrument the database layer with programmatic controls to verify that the user has the permission to do that database operation on behalf of a particular customer. So you might be scratching your head right now and saying, well, why are we doing authorization in the database layer? And the web app layer, you know, I pushed a button to add a row to a table. So I checked it there. Do I need to check it here too? You know, that overboard. So we're back to defense in depth. Would if the attacker was able to circumvent your web app, authors, you know, what if they were able to circumvent your web app? Would if they were able to instantiate your database component via say reflection? What then? So again, defense in depth when one barrier doesn't hold up, another one holds, you know, picks up the slack. We're almost done. Last thing we're gonna do is we're gonna encrypt that channel to the database via SSL. So we're going to instrument MySQL with, you know, the cryptography that we generated earlier and we're gonna instrument JDBC to make that channel secure. Okay, so those are all the steps that I've done here. We could keep going. There's more here that we could do. You know, we could have say column level encryption on the database. You know, you could encrypt the customer column, for example, that's another thing you could do. You might have stricter access control lists on these resources to say, hey, the service account that's accessing that can only access it for these specific rows, these specific tables. So that's, you know, you get the idea of sort of defense in depth practicing the principle of lease privilege. We're trying to sort of limit the attack vector, the surface area of an attack. Okay, so talk a little bit about the functional requirements of this application. It's just a contrived example where we have three pages. There's some data sitting in the database for three customers. And I've established a security policy, a fine grade access control, security policy where I'm saying to hit a particular page for a particular customer, you've got to have that role. So three pages, three customers, that's nine roles. And furthermore, I'm saying that a user may be assigned to one or more roles for each role would give them access to that particular page for a customer. And then we're gonna apply dynamic separation and duty constraints on those nine roles to say that the user can activate one and only one of those roles in the session at a time. Does that make sense? So let's go ahead and take a look. Well, before we do that, so you know, we can now have this sort of slice and dice the policy in any way we want. So I have this user, user one, two, three, that has access to all pages for a single customer. User one has access to a single page, all customers, user one, one, two, three, single page, single customer, you know, on and on and on, right? So just based on the roles, then that's what you get. So let's go ahead and try this out real quick. So this is the app, I'm not a web designer, so it's not very beautiful. And I'm gonna log in. Can you guys see that okay? Okay, and so this web form right here was presented to me by Apache Tomcat. The application did not put that web form there. So I'm authenticating, I'm authenticating with the realm and I got through. And so the realm decided that yeah, the password was right and yeah, he's got the one role that he needs to get into this application. So once it passes that check, then I land on the landing page where the, you can see that the web app framework said, yeah, he's got the roles for these three pages. So it put the links on there. And so I can click on these links and I can get to those pages, which question, go ahead. So the question is the web form that we hit in the very beginning, which is this, is enforced by Tomcat. And so that gets back to, there's a deployment descriptor called a web.xml file that goes in the webmpt folder. And in that folder, you specified to Tomcat what the policy is. And so yes, now the data's not in web.xml as far as the user ID and password. That's correct. That's correct. Okay, so again, I'm gonna log in as user123 with the container. Yeah, that's well. That's me. You have, you can actually put a form. You can give it a form. So that was my form. So that tells you, yeah, that tells you how bad I am. But you can, or you can also have an HTTP basic auth where it just puts up a little box. But yeah, obviously you could do better than what I did. Okay, so here's the landing page again. So I can click on these links and Spring is okay with it. So I can go to page one. Spring lets me go to page one. So I must have a role for that. I can go to page two, page three, so on and so forth. But where are my buttons? There's no buttons on the bottom. Because I haven't activated one of those page customer roles yet. So I'm gonna do that now. So there's a, you know, and again, this is contrived just to kind of show you how this is. You probably wouldn't have a user do this. But I'm going to activate page one, 123 role. Okay, so I click activate. The buttons pop up down at the bottom. See that. And so now I can interact with the buttons and do things like I can pull back data. You can see on the bottom.  That's SSL over there. The traffic on LDAP is LDAP-S. What happens if I try to change the customer to say four, five, six, and do a search? I get an authorization error because the user doesn't have the role activated to hit that customer data for that page. Question. Okay, so the question is, is the logic in the Java code to check for the roles or is it checked by the framework? And the answer is it's checked by the framework. So the Java Apache Fortress subsystem, which is this role-based access control system, is the thing that actually checks those roles. And you're basically, you're interrogating with APIs. So in this case, when we saw this error, it was doing a check access on that button. And so it was saying, can the user click the button on page one, customer one, two, three, for say search or add? So it's a permission, you know? Page one, one, two, three, add. That's a permission. And so you call the policy decision point with that question, check access with that permission and it just returns a yes or no. In this case, it returned a no. So the application doesn't have to worry about that. It's just calling these APIs. That's correct. Okay, so the question is, can, is there a declarative mechanism, say in the spring framework, to do these fine-grained policy checks? So the answer is no. There isn't anything that works like this in the spring framework where you can do that declaratively. You know, I'm sure that you could probably figure out some way to do it. But, you know, I mean, it's absolutely. Yeah, so the comment is it would be nice to annotate the button and I agree with you. And I believe that that's possible. And so it could be just that I don't know how to do it. Question. Okay, so the question is, is this JSP syntax or is this Java code? So this is, the framework is Apache Wicked. And so Apache Wicked is a component-based framework, so you're not actually coding JSPs in Wicked. You've actually got Java classes that you're writing and that renders into HTML. Yeah. So, okay, so where are we? We filled the authorization check for this user because they tried to interrogate on customer 456 because they don't have that role activated. So let's just jump to another page for this user. We're on page two, the button went away, right? So that means that we don't have the role activated for page two, customer 123. Remember, this user has access to all pages, single customer, right? So we can go to any one of the three pages and interrogate customer 123. So all I gotta do, right, is activate this role for page two, one, two, three, which is in the dropdown, right? So I'm gonna activate that role and I get another error, which is a dynamic separation of duties violation because I can only have one of those page customer roles active in my session at a time. So before I can activate that second role, I must deactivate the first role. So I'm gonna deactivate the first role and then I'm going to activate the second role and then the buttons pop up and then that user can then interrogate on that page. And so that, I'm gonna show you one more user real quick and we're gonna move off this example. So user 123 has access to a single page one customer. So let's log in as that user right now. Okay, so similar to last time, only now we just have one page there because this user only has access to a single page, single customer. I can click on that link as before, the buttons, he would have to activate that particular role before that button shows up. But what I wanna show you here is what happens if this user tries to bypass the web app framework in the link and enter in the URL to the second page manually. Can't do it because Spring knows the policy, right? So defense in depth, one layer fails, another layer picks up the slack. Okay, so that's enough of that. There's a bit more to this. Testing is important. We verify the policy, performance is important. That round trip of that policy decision point should be less than 10 milliseconds. I sat in a talk yesterday where the round trip was 100 milliseconds or something, the policy decision point I was saying, well, it sucks to be you. You should be able to get that down to a lot faster. That's why Apache Fortress is using an LDAP directory. It's not using it because it thinks LDAP is complicated and we're just gonna put it somewhere hard. It's because directories are fast and efficient. And so Open LDAP has legendary performance. The round trip time's getting down into the microseconds. So the question is, is when we do a check access in the application, is it doing a round trip with the policy decision point or is it cached? And so the answer is it's cached. So remember when I was showing you those access control functions and one of them was session permissions that pulls back the whole list. That's what's going on in the beginning is it's pulling back all those permissions and it's caching it in the session. But you could do it round trip. When you're talking about just a millisecond or whatever. And so that's one of the impediments to doing fine-grained authorization like this is the performance. And that's what architects will tell you. Well, we can't do it because the performance. And so I beg to differ. You can do it. The performance is there. If you pick the right resource, it will work. That's Apache Fortress demo. We keep it up to date. So try it out. If you've got any problems, let me know. And we'll help you with it. OK, so there's still a problem here, right? I'm presenting this last application like it was the best thing since slide spread. But there's a problem. And it's, I don't know, can anybody guess what the problem is? It has to do with the policy and the fine-grained policy. So we had nine roles, right? Fine-grained. So for every page customer, you had to have a role. So our roles are exploding, right? So as soon as you introduce context into the equation, then you've got this role explosion problem. So basically what it means is the number of roles that you're going to need for your policy is the number of roles times the number of relationships. So in the case of the app that we just looked at, we had three roles and three customers, so we had nine roles, no big deal. But what if you had 100 customers? What if you had 1,000? What if you had 10,000? What if you had 100,000? Then this quickly becomes unwieldy. And then again, we're back to we can't do fine-grained authorization because we've got this role explosion problem. And it's a huge problem. And it actually exists. And so this is why people will tell you don't use RBAC. That's one of the main reasons they'll tell you don't use RBAC is you'll have a role explosion problem. And so there's a solution here. And the solution is use attributes to constrain under what conditions the roles may be activated. So remember earlier when I was pointing you to the specification, there was insights 4.94 attribute modifiers on the roles. So ANSI not only allows, they encourage the use of attributes with the roles. So we're going to talk about that right now. So basically what we have, well, that's basically the physical data. So in the first example that we just looked at, we had these page customer roles. So the customer number was actually embedded in the name. And so for every page customer, you had to have a role. Use an RBAC, we're back to generic roles. But we can constrain them by a particular attribute value, in this case, customer. So what that looks like is we've got a new policy construct where we're establishing role constraints where we're saying, hey, this role is kind of special. It's now constrained by something called customer. Now that could be hair color. That could be what kind of car you drive. That could be anything. So the type of constraint is irrelevant to the security system. What you define that is as policy setters. And then you have a construct on the user to role assignment where you're saying, yeah, user one, two, three is assigned to page one, only for customer one, two, three. So in code, we've got to do things a little bit different at runtime before we call create session. Remember, we're talking about the APIs create session is how you create the RBAC session. Before we invoke create session, we've got to push the value of that constraint into the runtime context. So we're saying this user is logging on on behalf of customer one, two, three. And so that's the cue for the policy decision point to say, OK, for all the constrained roles, it's got to match that value, or I'm not going to activate it in the session. OK, that brings us to the next example, which is actually our last example we're going to go over. Let's call the Apache Fortress ABAC demo. That also is in my GitHub account question. Yes. OK, so the question is, is LDAP holding those attributes? And the answer is, yes, LDAP's holding those attributes. So I'll show you that here in a minute. Absolutely. So there is a schema to hold those attributes. If you're interested, I'll show that to you after this. I'll show you the physical data and how it works. OK, so this example is in my public GitHub account. And again, all the infrastructure's there. This is skinning down. We don't have a database. We're not doing SSL and all that. This is really to just kind of illustrate this policy construct with attributes. So it's the exact same policy as before, where you have these three pages and three customers. And users have access according to which page is customer combination. So we're going to log in. Oh, I've got to go to the app first. OK, it's just as ugly as before. Again, this is Tomcat saying log in. So I'm going to log in as user123. So this user, you might remember, has access to all pages for a single customer. So the landing page is exactly as before, where I've got the three links to the three pages. I click on a link. And the buttons are not there as before. Here, we don't have a dropdown. We have an entry form. OK, so again, this is contrived. I would expect the application to push the value of the attribute into the session, not the user. But this is just to show you how it works. So I'm going to go ahead and push that customer123 constraint down into the runtime. When I do that, as soon as I do that, the buttons pop up on the bottom. And now this user can operate on that. So if they try to, say, push a customer ID that they don't have roles, privilege for roles, and they activate that, the buttons go away. So it works exactly as before. Only now we're using attributes in conjunction with coarse-grained roles instead of these roles that are fine-grained. Does that make sense to you guys? So it's fairly subtle, but it fixes the role explosion problem. A fifth example we don't have time for. This is the RBAC A-BAC demo. It's more of a concise, simpler one to use. So if you want to try this out, I'd point you to this one, probably. The other one was just in response to the first anti-pattern of the role explosion. OK, that's it. Closing thoughts never allow users more than they need to do their jobs. That's the principle of least privilege. Apply security controls across many layers. That's practicing defense and depth. Role-based access control may be combined with attribute-based access control for fine-grained authorization. These are the examples that we looked at. Again, these slides are published if you want to try this out. There's a bonus there on the bottom, which is using role-based access control with SAML 2.0. So I like this sample. I used to do it in this talk, but it got pushed out by A-BAC. And so I didn't have time. But the nice thing about this is you don't have to set up an identity provider. I don't know if you've ever had to set up a SAML identity provider. That's not something for the faint of heart. And so this sample uses a common identity provider from SSOcircle.com, which is like a free one. You just kind of register with them, and then you can kind of test with it. It's kind of nice. And then the service provider controls are in the SAML app. And then basically what happens is, instead of authenticating with a web form with Tomcat, you're authenticating with the identity provider. And then you get the assertion gets pushed into the app. And Spring SAML is doing the validation for the deadbolt instead of job at East Fury. So you can move these layers around according to your needs. And then it shows you how to sort of take that assertion and to use it with A-BAC. So that's something out there if you want to try it out. I also keep that one up. There's my contact info. Feel free to contact me. And if you've got any questions, I'd love to hear about them. And you guys have been real patient with me. It's a pretty gnarly talk for the last one of the conference you guys have sat through it. So thank you for your patience. And I guess we can do some questions since nobody needs this room, or we can go have a beer. So thank you. Anybody got any questions? Link for the presentation is at the very beginning. So I wanted to show you the data for the attribute data. So I can do that now if you guys want to see that. OK. I'll let you guys write this down before I switch. And you can just email me if you want me. And I'll send it to you if you don't get the link. I mean, that's a pretty long link. Apologize for that. So any other questions while we're waiting? Did this make sense to you guys? Yeah? Good. Well, that's the thing is that's kind of where the rubber hits the road, right, is testing it out. And I don't know about you. I've been a security architect for a long time. And I never generated certificates or public keys. I mean, that was always something that the IT guys did. So if something went wrong, I was beholden to them. And so that's one of the nice things about that Apache Fortress demo is it shows you how to do that in sort of very specific terms. And that's kind of a nice exercise to do, because you get a really good feel for all the things that can go wrong. And while I wouldn't say that it's difficult, it's complicated in that if you miss any of those steps, it ain't going to work. And it can be tricky to troubleshoot. And so it's good to know that because you kind of get a feel for these things. So as far as the data structures, this right here, this application that I'm showing you is the Apache Directory Studio. I don't know if you guys have ever seen this. This is one of the sub-projects of Apache Directory is the studio, the Directory Studio. And it's a general-purpose LDAP browser. So I am right now browsing the open LDAP instance that's on this machine right here that I've been using today. And so underneath the people folder is a user curly right here who has some constraints, some attribute constraints. So let's look at that. So this FTRC is what we're talking about, which is the fortress role constraint. Yeah. Yeah, you can have multiple roles, multiple constraints. And so that second A-back demo that I showed you the link to, the R-back A-back demo, this is that policy. So I've got Curly, Mo, and Larry are the users, the three stooges. And they can either be a teller or a coin washer on a particular branch. And so based on the constraints, so you can see right here that Curly is a teller in location east. So that teller role is being constrained to a location. And that's the east location. And he is a washer in the north and a washer in the south. Location is just an attribute constraint. So in terms of the way Apache Fortress looked at this, they're arbitrary. You could call it XYZ. You could call it hair color. It's just that it has to match what you push into the runtime. Yes, you can use the location to specify where that role can be activated. Remember, the role is always assigned. But to activate it in the session is a function of the policy decision point at runtime when you call create session. So Apache Fortress does that automatically. So in this case, before we call create session in our program, we would push a name value pair into the runtime location east. And then Apache Fortress, when it's iterating over all the roles that have been assigned, it's going


All this month at Appalachian Wireless, get the only truly water-resistant Android smartphone the Samsung Galaxy S7 for just $99.99 and get a second one free while supplies last. Service agreement is required. Better service? Bigger savings? That's today's Appalachian Wireless. Dignity Hospice of Southern West Virginia doesn't believe in turning those in need away. That was evident Saturday at the third annual Dignity Hospice Charity Poker Run where dozens showed their support. Proceeds from the event benefit those who can't afford hospice care. When they come to us, especially in hospice, they don't always have enough insurance to cover their needs. So what we do is we raise money. So we're able to go into this fund and make sure that they have everything they need and everyone is created equal and taken care of equally, you know, to where we provide anything and everything they need even if they don't have the coverage. Things like this do more than just raise money. It also brings awareness to the cause. It brings the community together. It brings different entities together that otherwise wouldn't maybe know what hospice and home health does. Dignity Hospice of Southern West Virginia covers Boone, Lincoln, Logan, Mingo and Wayne counties. Staff at Dignity Hospice say working there is rewarding. You have to have a heart for hospice and for home health. Hospice is a different ball game. I laugh and tell people sometimes that God took me on a very crooked route to get me where I'm supposed to be, but hospice is a wonderful place to work. It's very rewarding, very fulfilling.  You never have to worry that you've done something good for somebody that day because you can walk away at the end of the day knowing that you've helped somebody. For more information on Dignity Hospice or volunteer opportunities, call the number on your screen. Reporting in Logan for EKB News, I'm Shelby Steele.


Here we go! Sidor is young, part two, guys tangled out in Vegas. Sidor has walked away with the win. Young was having some back problems. Young 100% healthy here, to my knowledge. Sidor is immediately in on that patented left side high crotch. Young squatting it out. Sidor is building a ride back up. Cutting it back across to a double. Sidor is going to get the takedown. 29 seconds of riding time for Sidor. Minute 37 left in the period. Paul Young's brother, Daniel Young, wrestling for Army. Still alive in the consoles, I believe. Back in on that high crotch. Young stuffs at this time. Underhook dragging down short offense. Looking. Underhook slide body. Young was trying to shoot off that snap. Short time in the period. Two runs. Doesn't have her out until. Four now. Young goes down to his feet. Sidor is in the re-action up to his feet. Sidor is pushing. Young facing. Number six. Good two runs. Sidor does have riding time now. Not one of the mats right there. Climbing up to speed immediately. Back in there. Tapping, clubbing. Just mopping down to the mats. Doing some work. Nicely trying to work for a fresh start here. Nice snap down for Young. He's got the snake. Up exchange there for Young. He's so tough for that position. Sidor's almost got himself in a little bit of trouble. He's got a minute to get himself a takedown. Going into the third period. Nicely Sidor's two pounds. Young's chasing. Sidor's not really backing up and not necessarily pushing his own pace. Young in deep on the shot. Sidor's great hips. Check the riding time. Sidor's trying to hip over. Young hanging tough here. Self set. What they call it illegal or not. Sidor's trying to push and step over here. Young pressure here. Almost completely erased all of Sidor's riding time down to zero. He's about to start getting some of his own here. He had redrop for Young. The redrops and the pressure. Sidor gets to his feet though. It's a whole different story. He's dangerous on his feet. He's on the first period. Young's got 30 seconds of riding time as well. Young's starting to feel this rematch victory. Right now he's definitely could deal with an escape and some hand fighting and maybe a little treadmill action. Or he could just ride him out here. Nice redrop again. Sidor's head on the mat. That might have been the last hurrah for Sidor. It's trying to get to his feet with that explosion. Young's got some great forward pressure going here with the spiral. Not a good sign for Sidor's head on the mat. A couple ticks left on the clock. Looks like Paul Young. Which I predicted would be in the finals against the Magic Man.


Thank you to the American Society of Mechanical Engineers, the Impact Engineer team, and the network of experts who nominated Select-A-Me for the Women Leading and Technology and Impact Award alongside amazing women which I'm humbled to be in their company. Thank you to my family, my husband, my team, friends and advisors for your ongoing and unending support. Each day I aim to seek excellence and hopefully serve an example to the next generation workforce. A few months ago I shared virtually to a couple thousand girls that STEM plus your passion is your superpower, and upon reflection I think that's true for any age. On a personal level, I hope that we can use this unprecedented time to innovate towards a betterment of humanity to enhance peace and prosperity. On a professional level, I'm excited for the ongoing work in the global partnership at AI, Troubled Environmental Sustainability Initiatives, and in the next few weeks I look forward to being part of exciting initiatives within the U.S. Air and Space Forces. Thank you again. Take care and Godspeed.