 Welcome, welcome to track 101 for the second talk of the day and of Depcon 24 and the talk is Maelstrom. Are you playing with a full deck? Using an attack life cycle game to educate, demonstrate and evangelize. And my name's Shane Steiger. So who am I? I've been messing with computers in some way shape or form since 1989. A few friends and I found out that a local university's computer lab, they did not check IDs at the door. So we went in and messed around with computers for playing around with tin and pine and Y talk and then later on, you know, links and muds. How many people remember links? Yeah. That's the internet didn't suck back then as much. So then I spent eight years working to secure a state and ICS systems throughout a large food manufacturer. And you know, that was an interesting job. Got to know recipes of some food products that are made on kitchen tables today. But at the same time I started law school. So please don't hold that against me. But then I spent six years building out a functional security program role within a large pharmaceutical distributor. Now currently work as a chief end point security architect for a large tech company building out cyber resiliency techniques within the end point space, the desirable capabilities. And you know, as I said here, you know, don't hold the law thing against me, but I'm more of a geek anyway. So that leads me into my disclaimers. The first one I know this sucks. I have to read them off though. The first one's an employer one. The views and opinions are purely my own based on time in the industry and experience. They don't necessarily reflect the views, positions or policies of my employers. And oh yeah, this presentation and discussion is not intended to give legal advice nor form any kind of attorney-client privilege. I'm not your attorney and some of the things you might find interesting may require consultation with your own attorney and that is not me. So what is this really about? It's about, it was an unexpected journey for me to a cyber attack life cycle game. When I first started looking at what I needed to do for certain projects, I became somewhat frustrated with what people traditionally do. And so therefore I started looking for different strategies beyond just the typical normal project management type strategies. And that research took me on a journey. And that journey I was going to share with you guys a little bit and share with you the research, some really cool stuff, and then share how I tripped into actually developing the game, Maelstrom. So the first part of the journey was really, as I said, a strategy journey. From a past life I was asked by a CIO, do they win? And in his context it was does the attacker win? And so that's I was completely out of context as to what he was asking me so I didn't know if the next words out of my mouth would be career limiting or not. So I took that and found out later on that he was actually interviewing for jobs so it was kind of like he was stealing some of the questions or answers. And it was a question that really struck me. A CIO asking that question, do they win? It was an assumption almost. But then later on I was asked to look at solutions for over 300,000 endpoints and things at that scale become kind of interesting. You think you got something generic and rather standard or basic, but you're working with the Wild West at that scale. And what I did is like most folks I put together a bunch of requirements, a bunch of visios, a bunch of power points and ended up with a nice heat map for people to look at and maybe make choices. And it didn't make strategic sense. And that really bugged me and it brought me back to the CIO question of do they win? And so I needed to find some different way to make choices for at 300,000 endpoints. It's a lot of money. Make choices at that scale. So in a previous life I had been working in, you know, the public defender space. And at that time I was really looking and following the OODA loop as an analogy in 2007, 2008. Some folks started describing the OODA loop, the Observe Orient Decide Act, John Boyd's OODA loop from the Air Force and analogizing it to cyber security. And it made sense. But at the same time, right around the same time Lockheed Martin had been developing something called Lockheed Martin's cyber kill chain and I'm sure many of you are familiar with it. And what it really describes is it describes an attacker's set of phases that a traditional attacker from zero to hero, so to speak, will go through to get to their act on objectess. And in a way Lockheed Martin describes there's a recon phase. You go through recon steps looking around for things on Google showed in, whatever. And then you take what you've learned from Google showed in, linked in and you actually start to weaponize a package so that that package, when delivered to the target, actually explodes or has some kind of detrimental effect on the target. And you know, in the cyber construct, exploitation is part of that detrimental effect and later installation so you might be able to later maintain and keep presence, but then also command and control so you can change and adapt or dynamically position as needed. And you know, as Lockheed Martin kind of describes, they talk about, you know, the act on objectives of recon destruction and pivoting or exfiltration. So, you know, it's really good work, you know, for anybody who hasn't seen it, definitely go out, take a look at it. But I have a few quibbles with it, but the next set of slides starts to build out what would the defender do in each of those phases? What would they do against the recon, against Google or showed in or, you know, some linked in areas. And you start, you know, building out the structure of, all right, there's an attacker set of a set of tasks or activities are going on in a phase. There should be some defensive set of tasks or activities that are going on within a phase. Lockheed Martin describes it as the six B's. And I won't go into them here because they're somewhat nuanced and they actually don't necessarily just apply in the phases. So, but it helps to build out that idea of an attacker action, a defender action, and their effective descents. But there's one other point that I have, you know, kind of with the Lockheed Martin kill chain, somewhat of a misnomer because I've had this with companies that I've worked with in the past trying to communicate with them about, hey, I'd like a product that actually works as a defensive product in the weaponization stage and in the recon stage, how do I do that? And they'll get confused as to what the kill chain really means. It's really about the name is somewhat misleading. It's really about defender actions within the attackers life cycle phase. So I throw that out there just as a small quibble. And then another quibble is a set of act on objectives is rather limited if you look at the paper. And, you know, especially in these days where now you see ransomware pretty much every day, there's the idea of, you know, not only exfilling information, but maybe planting false information. And then there's, you know, just the other pieces of humiliating things that might not have that same feel or look within the Lockheed Martin structure. So I said, okay, wait a second. Why not start charting out the attacker's progression and do that over time? And that charting of, you know, recon into weaponization into delivery. And I show this as the simplest form. I mean, these phases could happen in parallel to one another, but you're still exiting one phase. You're exiting the recon phase to get into weaponization to figure out what you're going to build and wrap, you know, to deliver via commodity modular frameworks. And then you're exiting, you know, that weaponization phase to get into delivery. So you're doing tasks, you're exiting a phase to get into another phase, and you're doing this attack execution over time. What does this look like to folks? It looks like a Gantt chart or a project plan. And as a result, I throw out this concept of, hey, it makes sense. It does. You know, the campaigns that you see are largely organized. Even the guys who are not as, you know, as maybe not state actors, maybe just, you know, less skilled, you'll see that they're trying to follow a plan to get to the other end, to get to their act on objectives, whether it might be to steal money or, you know, steal bitcoins or what have you. But we see that these attacker plans are organized and they're really going through a progression to get to an act on objectives. And so, you know, I kind of throw out, all right, what other evidence do we see that the attackers are following some form of plan if not a traditional project plan? We see different skill levels from the same attackers indicating different resources or teams. So you'll see team C, so maybe the, you know, close to the script kiddies doing something and then something breaks and they don't know what to do or how to respond. They'll page out to team B and team B will get through or they'll have to page out to their best resources, team A and team A will walk in and just annihilate the thing. We'll see different teams using different tools. Some may use PSX, some may use WMI, some may use your administrative tools against you and that's actually very prevalent, you know, even PSX and WMI being part of your administration. And then you'll see different teams, maybe are different time schedules indicating shift work. I kind of see this as folks walking in with their lunch pail every day and, you know, all right, I'm going off to work to attack XYZ company or XYZ organization and I'm going to go home or go to lunch at 12 and then go come back to lunch and you'll see that time set of time gaps that kind of indicates what's going on in terms of shift work and that actually had been discussed at length in some recent APT findings. And then, you know, following scripts, making mistakes. When something screws up, you know, not only are they teaming out or paging out to other teams, but they're also redoing work and you can kind of see them making their mistakes in their console logs. Oops, that script didn't run. I didn't give it the right variable and retrying tasks. So these are all things that seem to indicate they're following plans and scripts and getting themselves to an act on objectives. So I throw out a concept here. Why not attack the project plan if you're a defender? Attacking that project plan is I think a perfectly valid way to look at it. And guess what? IT organizations are experts at screwing up project plans. They do it like it's their job. And usually they're named project managers, but I'm not going to bust on anybody. But they even have a methodology for trying not to screw up the project plan. And so I suggest look at the methodology and this methodology is here kind of listed as what's called the PMI triangle. And that's the triangle of time, scope, cost and quality. So if you've ever had to interact with a project manager, you've probably heard one of these, you know, I don't want to see some scope creep happen. I don't, you know, my timing is absolutely necessary for this thing to go before this thing. And so I suggest mapping these plans and finding weaknesses across, you know, a couple of attack life cycles will start to reveal weaknesses that might apply across more attack life cycles. So I think it's absolutely key attacking the attackers project plan. And what techniques can we use to disrupt that attack attackers project plan? Guess what? Time is assumed linear in project plans. Now, you might have less than a waterfall approach. You might have an agile approach. And actually in my backup slides for anybody who wants to quibble, you can go look there. And I have also kind of broken down agile scrum in the same, in somewhat of a similar fashion. But really in the end, time is assumed linear. So we screw with time every day in IT. We, we mess up, we will revert to snapshots because we broke something. And so, you know, we might do certain replays of certain, you know, web activity to make sure that we got the appropriate and substantiated integrity type response that we were looking for. But, you know, assume linear time. And that was actually the first thing that I noticed. I'm like, hey, what if we just randomly reset these machines to different times in the past? What does that do to an attacker's attack life cycle? And we see this with sandboxing and detonation technologies. It breaks it and they don't get to progress through their next set of phases. Predecessors and successors, feigning completion of work. This is where deception might come into play. So they went out, they recond information, they got it. It was said something about an admin that was, you know, worked at a company on LinkedIn. That was false information. They used that information to try and weaponize their spam or their directed, you know, fishing attack against that particular admin. And guess what? That was not an appropriate set of information that they gathered. They used deceptive elements to try and, you know, land an actual attack. And so therefore feigning that completion of work becomes a disruptor to that project plan. Resources and tools, attack tools and shift work. You know, hey, if TMF is using something like Cloudflare as their, you know, their point for infiltration, you know, what is, unless it's an absolutely critical to the business app, what is the harm in just cratering Cloudflare for that particular stage for a period of time? If they only use it during their shift work, guess what? They've got to now switch out to other resources to go and deal with it. Create resource contention. Flooding your own machines or targeting your own machines in a cyber resiliency construct. That should always be an option. You should always have the ability to flood certain machines. I mean, yes, there's certain ones that you're not going to be able to take down because they're business critical, but not everything and everyone is business critical. So understanding and defining somewhat where, where that sits, but understanding that, um, a, an offensive approach against your own machines might create disruptions to the attacker's plan because remember, they're using your machines against you and therefore this, um, removes an asset they have to have to get through their attack lifecycle and project plan. And then, um, you know, I talked about, you know, different teams using different tools, WMI PIS exec and, and management tools against you being used against you. Scope creep, utilizing deception and fake targets or tarpids. This is, this is always a fun one. I actually talk about a number of folks, uh, the concept of honey information, not honey tokens, not honey pots or honey nets, but honey information, things that are planted out there that the, uh, attacker has to stomp through and has no choice but to look at because it's there. They've enumerated on the box and they see a bunch of information, maybe some logs that are interesting and they might want to use that information for their lateral movement. This, this creates scope creep to them if they have no idea that it's deceptive and therefore creates that ability to make them noisy, creates that ability to, uh, uh, make them, uh, visible to you in, in their attack lifecycle. And it also screws with their predecessors and successors costs. I mean, any, any cost increased to the attacker is a cost decrease for you to remediate. And that's, that's something to, you know, keep in mind if you start increasing costs, even minimally, even though some of these, uh, methods might not be 100 percent effective, they eventually get in, you're still increasing costs to the attacker and thereby creasing the OODA loop time that they might have to, uh, go through and therefore you might get inside what is called their OODA loop to make a decision faster than they did. Uh, and then lastly, um, noise and anomalies, that's always a fun one. You know, random IPC shares to things, you know, as the bad guys enumerating through and trying to find things, that actually becomes very interesting. The attackers are usually using some form of automation and scripts upfront and if you start creating anomalies, that starts to mess up their variables for import into their own automation and scripts, therefore creating friction to their project plan. So what would that look like? You know, just visually, I just, you know, draw it up, maybe they're at C, you know, command and control and they give just snapshot of the machine back to an older version, guess what? They have to go all the way through exploit again because they, they've now, um, toasted their, or the, um, snapshot back to a previous version has now toasted their ability to go from exploit to install and back to command and control. That sets them back in time and, or they're sitting at in, uh, install and they, uh, the, uh, the virtual machine might blow back to a point where they have to re-deliver again that same spam message or that same phishing message to get the admin to open. So that's, that's, that's just one visual, you know, the same type of visual for tool unavailability. Um, and, you know, uh, that, that same concept of, hey, you have to exit one phase to get to the other, you have to progress through one phase to get to the next phase. And that same concept for maybe an orchestrated set of false targets, that deception space again and creating, uh, a path for the bad guy. So, all right. So what I did is, I, I sat down and just, you know, in Excel started plotting out a bunch of, uh, attack, uh, you know, patterns that have been seen in the past. And I did it by phase. I said, hey, this time frame, the successors and the predecessors, the tools and the resources were, um, guessing or that, that, uh, the particular attackers are using and then the time frame in which they're doing it, you know, if, you know, that time frame is actually rather key because if you can do something in a phase quicker than they do, you win. So going through and completely mapping out a few, uh, uh, actual live, uh, you know, attack patterns and doing so in terms of the cyber resiliency engineering framework by MITRE. And that was something I was buried in at the time quite a bit for cyber resiliency at the end point. And as a result, uh, I was looking at those cyber resiliency techniques, which are really the money that, that I started to frame these, uh, maps into. So as a result, uh, I mapped out this one, you're not going to be able to see it. It's, uh, an, an attack pattern, but really you just kind of see, hey, the, the, uh, the general, hey, this is, this is the, what the entire attack pattern might look like over time for each phase and, uh, mapping it out. I actually mapped out close to ten in conjunction with some other folks mapped out Axiom, Cleaver, Dark Hotel, Fin4, uh, Zero to Hero, uh, Scenario, Sapu for All Scenario, stuck on your DC things, you know, you might see in past lives or open your door in this case. So I mapped out a bunch of them and, you know, it was kind of interesting, I noticed something, is that you could start to build out, you know, okay, these are, uh, category of, um, the, uh, the actual techniques that you can use per phase and you can mix and match them obviously. I mean, why wouldn't you do that? Start to mix and match them so that maybe, you know, when you recon phase you got your exploratory fishing attack, your port scans, your Google showed in search, you know, you might use a different one for another attack pattern and if you light them up, you're essentially lighting up a path to the act on objectives for, uh, this particular attacker and that, that, I mean, right here I just show three examples per phase. So that meant, hey, I got to get some more, so grep, more attack research catalog techniques and so that's what I did. I went out and looked for some, uh, you know, uh, attack techniques that, you know, were research based and of course I found MITRE's CatBat, common attack patterns and enumeration catalog, but for anybody who's gone out there and looked at it, they're, at the time when I started looking at it, probably about four or five years ago, three or four years ago, I guess it was, uh, there were five hundred, or there were four hundred techniques at that time, there are now over five hundred and four and so it became slightly unmanageable. Yes, I could go and map and start throwing in, um, to each, potentially each phase, those techniques, but I realized something, wait a second, I've tripped across this other framework that was just coming out as, as public work and that was MITRE's attack framework, adversarial tactics, techniques and common knowledge and that had 68 techniques at the time and this was in, um, late 2014, early 2015, I'm like hey, that's a lot more manageable, plus it's relatively mapped to an attack life cycle and I said, hey, that actually works a lot better. So I got, um, an attack life cycle from, you know, something like Lockheed Martin and I can map these attack, these, um, attack, uh, tools techniques straight to the, uh, straight to the attack life cycle right there, therefore it was a win for me. So what does that look like? Um, as of at the time when I started really building out my work, um, it was, it looked like this around 8, 2015. I started in, in, in, uh, February really, uh, hammering on it and then it changed just a little bit and this is what it looked like in 8, 2015. So you can see that, hey, there's this list of, uh, attack techniques that, you know, a bad guy could put in an area, an attacker could put in their pockets and start using, uh, against a particular set of act on objectives, what they're looking to do. And the same concept's true. Light them up. You know, essentially build your path to, to the end game. And that, that really made sense to me and made, it made, you know, logical, so it was research-based. But the problem is, I still had that, um, uh, I still had some things going on at the same time and that was the attack research was actually changing a little bit. So the stuff you see in 2, 2015 was 68. The stuff you see in 10 of 2015, um, started to build out where there were some gaps and it became, uh, 101. And this is hot off the presses. It was just released and it's absolutely awesome. I suggest you guys go out and take a look at it. It was released 7, 28, 2016 and that's, uh, um, the latest list and it ties back to things like capex. It actually shows, um, things that, um, other companies would show as public knowledge for, you know, attackers, their actual, uh, tools and techniques, what tools are used by a particular set of threat actors. This is all tied into this framework now. But, you know, back to the regularly scheduled, the scheduled program here, this was cool stuff and this is what I was using as my build out to, uh, the initial attack patterns. But, uh, that question of do they win? And, and my old CIO's life, uh, came up. I'm sorry, this is a list that, that kind of breaks it out too. But that question of do they win? That became, uh, you know, kind of interesting. I said, well, guess what? I have all these attack patterns listed out at research base. Why not take somewhat of a, you know, kind of a magic card approach of if you have something that's pretty effective as an attack technique, what are the defensive techniques, even if they aren't as effective, what are some of them that you can use against each and every technique in the attack, uh, uh, tool bag? And what it became was, hey, you know, something like new service, you know, what, what would you do? You would maybe whitelist services so that you, they couldn't start, you know, if it was a bad new service or you might blacklist certain services that you know, uh, that particular, uh, attacker is using. You might service, do service start failures and dependencies. So I started listing out this set of complimentary to the attack research techniques. So it became a set of defender techniques. And there were, you know, as I said, multiple levels of efficacy from, from good to really good to maybe not so good. But the thing I noticed is, hey, some of these techniques appear most often and they appeared most often across the attack life cycle. Then that really started to resonate. I'm like, well, if I invest in a particular set of, uh, attack technique or defensive techniques like time disruption, I get, uh, the most effect across the attack life cycle. Deception. I get this enormous amount of effect across the attack life cycle. So things like targets like time, scope creep and predecessors or successors as defense, became a really key understanding and saying, if I invest here, I'm going to have to invest less in, uh, my defenses across the entire life cycle being a strategy play. And then some of the strategies had like little payoff, but high investments. So, you know, like some, in some cases, if you look at analytic monitoring, maybe you're, you're, uh, big data lakes and trying to find that needle in the A-stack, that's a hell of a lot of money. It's you're putting in quite a bit of money, quite a bit of time, quite a bit of effort to go and find that needle in a A-stack. This, this when mapped out across the attack life cycle only showed detective and potentially preventative, uh, value throughout certain phases, not as, not as effective as the, you know, the ones that I previously noticed. So it started to make sense and it made sense in terms of what I was kind of buried in. I was buried in the resiliency engineering framework and I was buried in looking at something that was put out, uh, called the, the industry perspective of cyber resiliency, actually applying it to industries and what industries have done to apply it within their own organizations. So it started to validate a set of work that, uh, I was already chasing and made sense. But I noticed something more, you know, and I see, you know, you can kind of see the lead up. I got an attacker deck, I got a defender deck, I got a progressive board based on Lockheed Martin's, uh, attack lifecycle. Maybe I have a game. So I started a mockup and I didn't, I, you know, I didn't know I was going to get to this, but that's, you know, once I saw all those pieces, I said, all right, let's go back to the, you know, geek days of magic, which I may or may not have played once or twice. And I started going, hey, where can I build these card decks? And I found a place that I could build them and I defined, uh, the attacker is red and the defender is blue just as a convention and started a mockup. And what they, uh, and I, um, also put together a board and you'll notice that this board, you know, I first thought about the, the Lockheed Martin attack lifecycle or whatever attack lifecycle you might want as a potential Candyland type setup. But then I realized, wait a second, this is really kind of like a give and take between the attacker and defender because they don't always win defenders don't always win. So it is a true give and take and therefore create that, that board kind of in a who way approach give take approach or, um, in a kind of a vortex approach. And that's also how it got the name Maelstrom. But as you can see, it's going from reconnaissance and all the way in through to act on objectives. So your goal is to keep the guys out as, as a defender or if you're the attacker, your goals is get to act on objectives and it made sense. I started tearing down, um, uh, the cards to make, okay, what could these cards look like and how would they be built out? They have a, um, a set of phases they could be used in. So this, these sets of car or the first, the attacker card here can be used in recon, exploit C2 and actions. And it's a lateral movement card that, um, does applicant, you know, the back, uh, the attacker in this case is hiding in the application deployment software. So SMS or, you know, the table here or something like that. But, um, you also then have progression. How far are they going to get? There's a plus four or a minus four on the defender card. So that's how far they get within the attack life cycle with that particular play of the card. There's also, um, for more advanced play, there's cost and upkeep. And that's, you know, cost is kind of that, that real strategy play of figuring out, hey, how much would doing a defense like this or an offense like this, cost? And then there's the other piece and that's building out a story. So you can't just throw a card down and not know how it's used. You actually have to, you know, as, as table rules would work, you would say, hey, this is, this card's being used this way in my story. And some of the, some of the most fun that we've actually had playing the game was, was some of the stories people would come up with. It's actually a little crazy. But unique attacker cards within the sets of decks that developed so far. And, you know, these are just some examples that sit out there or that I've put together. And then there's over 70 plus unique defender cards that, that, you know, that I can show as examples. And there's another piece and I added later on while I was developing the game, you know, it became apparent that we don't always know who our threat actors are sometimes have a certain methodology or a certain way of play. And so mapping out unique threat actors was actually kind of interesting. And so, you know, going from freelance bias, corporate spy, all the way down to warfighter or political social, you know, motivations, it was interesting to kind of break those down and the way it would work is the, those chips go face down on the board. So the defender does not know what that is actually played. And there's certain opportunistic cards that might come up and also allow them to take a peek. Then, you know, as I said before, I had a little bit of a quibble with the Lockheed Martin attack life cycle. And some of that quibble, you know, was about, hey, what are the other act on objectives behind the ones kind of listed out and discussed most frequently. And so you, as you can see here, here's the example sets of those act on objectives and the cards that are in play as a result. So that sits face down in the middle of the board because, guess what, you don't know what the attacker's act on objectives is going to be. So there are three different versions of play. There's easy play. That's where the cards are dealt to you. But keep in mind that's not really real life. That's not the way real life works. Tactical play is where you choose which cards you have, and this is kind of like magic that you're going to have in your hand. The, you know, the attacker chooses, the defender chooses, the chips might be face down or dealt, the act on objectives might be face down or dealt. But that's kind of the tactical play. And then the last one is the strategic play where you actually have to buy cards. You're given budgets. But that, you know, as some folks pointed out to me, they said, this is too much like real work and not necessarily a game. I've played a few times, but one thing that was kind of interesting about it is it made sense when folks started to see how expensive it was to do certain attacks or how expensive it was to do certain defenses. And so I have the rules. They're going to be posted tonight, late tonight after the talk and after I get back to the room and so forth. But the rules have been built. They're actually on your CDs. So, you know, they're out there. But I'll post some stuff to get hub. And so that's just a big quick overview of the game. This is what it looks like. I have a printed out set of copies with me. I also have some that are out to friends on loan. And this is what it looks like if laid out. So the board, it's something, I actually, this board, I printed up at FedEx just in Mandalay Bay. I mean, it's that simple, that easy in the cards. That's something that you can play. There is one out there. We've played a number of times, but decided one time we'd actually record it just so people could see how it works. And then, what are the use cases for this? Remember from the beginning I said education, demonstration, and evangelism. Learn an attack concept, lifecycle concept and make it part of a vocabulary. This is not something that defenders actually do often. So, this is an ability or this is a way to go and try and educate defenders and attackers what, in some cases, what they're doing is part of their actual progression plan potentially. Make themselves more organized as pen testers or what have you. And then it builds a security mindset in those defenders who don't do offense. When we played with engineers and played with other forensic investigators, we didn't necessarily understand what the attacker was doing, but they saw the forensic artifacts and then after playing the game a few times they understood, oh, now I get why they needed to do this before they did this. So, building out an attack lifecycle concept or vocabulary and then also building out a security mindset. Demonstration, mini-table tops. We played that out with a few, you know, maybe some events you've had go on. How hell did that happen? Defenders have done differently if they had different tool sets or cards in their hand if they were playing with full decks, so to speak. And then analysis and strategies for choosing technologies to win. It's funny, that's actually where I was trying to go when I started this whole journey. I was looking for, you know, some endpoint technology-based stuff that was at scale. And then cost-benefit analysis. And, you know, that's where it really comes down to hey, you got to make it more, you got to make it harder on them, cost more for them than it is for you. And, you know, lastly, evangelism. People, you know, it's funny, I've had this out, I've played, people look at it and they're like, oh, wait, what is this? It draws them in and starts to, you know, kind of play out that gamification of hey, how do you get to this particular act on objectives? How can I get to that particular act on objectives? How can I get to this type of role? And then gets a message to non-security folks. And so, you know, there's, the rationalization, you saw this one through six of effectiveness, I picked it because of die and that you can actually use that as part of your gameplay, if you'd like. Cost rationalization based on a thousand-seat company, that's kind of what I was trying to do a thumb in the air as to how much I'd see it cost in previous years. There's hacker, hacker 2 control hack, elevation of privilege. I mean, some of these things are given away, but many of these things are actually more offensive than defensive. And so, I say, you know, in this case, we have an offensive and defensive game with a progressive board based on research. The attack framework, the complement to the attack framework and the Lockheed Martin to the next steps, submit work for con talks, get input. So that's where I'm at, here. Map to current attack patterns, play multiple rounds, digitize and create the open source framework. And I want some help with this. This is actually where real money can be had. This is interesting, but I'm looking to give it away and see if folks figure out ways to help me digitize it so that I can watch them play a game, see which strategies are most effective and then also allow for them to update card decks and put in their own tactics that maybe no one has seen before and can be shared, either as defensive tactics or offensive tactics. There was a non-technical game development based on the Scott Tenemann episode of South Park. I won't get into that here, but if for those who have seen it, they probably understand how that works. And lastly, digitize your deck, watch your strategies, gamify it so that maybe it's like a Pokemon Go, collect all your strategies, collect all your act on objectives with your particular set actors. And then lastly, digitize and let the machine rise and play itself. And that, you know, is the theme of DEF CON this year, let the machine rise. And so as a result, I think that that might be somewhat interesting as the framework develops, as well as the cards develop. And so, this is a place can contribute, volunteer, get the latest developments. As I said tonight, I'm going to post things probably going to be late. Twitter, Cyber MailStream, GitHub, MailStream the game that DEF CON 24, you're actually going to be able to print off your own copies if you want to. I'm working with a vendor right now to create a SKU for anybody to go in and use. You can go and even print out if you wanted to at FedEx, but I'm going to try and get it all as one package and then you can just buy it from there. Adding cards, if you want to suggest cards, I suggest using Twitter for peer review, crowdsource it so to speak for people to knock it down or raise it up. And then, you know, watch GitHub and Twitter for the digitized versions and contact Twitter to volunteer to help. And then, lastly, I believe it's not even possible. Nor, kind of that concept or virgin concept, the cyber resiliency engineering framework was key just because I was buried in at the time. Obviously, Lockheed, Martin, Kael Chain and these folks here who have graciously donated a lot of time and energy and fun to play the game, play it multiple times and see what things can be done