Welcome. Welcome to Track 101 for the second talk of the day of DEF CON 24.
And the talk is Maelstrom. Are you playing with a full deck?
Using an attack lifecycle game to educate, demonstrate, and evangelize.
And my name is 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. The internet didn't suck back then as much.
So, then I spent...
Eight years working to secure SCADA 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 endpoint security architect for a large tech company.
Building out cyber resiliency techniques within the endpoint 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.
The 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 lifecycle 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, you know, 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.
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 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.
Could be career limiting or not.
So, you know, 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, you know, it was a question that really struck me.
You know, 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 know.
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 PowerPoints.
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.
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 defender space.
And at that time, I was really looking and following the OODA loop as an analogy.
And, you know, 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 cybersecurity.
And, you know, it made sense.
But at the same time, right around the same time, Lockheed Martin had been developing something called Lockheed Martin 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 he'll...
That an attacker...
Traditional attacker from zero to hero, so to speak, will go through to get to their act on objectives.
And in a way, Lockheed Martin describes, you know, there's a recon phase.
You go through recon steps looking around, you know, for things on Google, Shodan, whatever.
And then you take what you've learned from Google, Shodan, LinkedIn, 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 a 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 and 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 a recon, against Google or Shodan or, you know, some LinkedIn areas?
And you start, you know, building out the structure of, all right, there's an attack.
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 Ds.
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 there are effective defenses.
But there's one.
There's one other point that I have, you know, kind of with the Lockheed Martin kill chain.
It's 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.
It's really about defender actions within the attacker's 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, you know, 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.
You know, 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 malware.
Malware 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, 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.
And 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.
You'll see different teams using different tools.
Some may use PS execs.
Some may use WMI.
Some may use your administrative tools against you.
And that's, you know, that's actually very prevalent.
You know, even PS exec and WMI being part of your administration.
And then you'll see different teams.
Maybe our 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 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 research.
And 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 enact 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, you know, 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.
Tapping 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 attacker's project plan.
And what techniques can we use to disrupt that attacker's 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've 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 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 activities.
We might do some more randomity 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.
Jesus. Predecessors and successors. Feigning completion of work. This is where deception
might come into play. So they went out, they reconned information, they got it, and 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 phishing 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 disrupter to that project plan. Resources and tools. Attack tools and shift work. You
know, hey, if team F is using something like Cloudflare as a tool, they're going to have to
use it as their, you know, their point for infiltration. You know, 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, you know,
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 that sits, but understanding
that 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 life cycle and project plan.
And then, um, you know, I talked about, you know, different teams using different tools, WMI,
PS Exec, and management tools against you, being used against you. Scope creep. Utilizing
deception and fake targets or tar pits. This is always a fun one. I actually talk about, with a
number of folks, 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 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 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 make them visible to you. And then, of course, you have the ability to, you know,
make them see you in their attack life cycle. And it also screws with their predecessors and
successors. Cost. Any cost increase to the attacker is a cost decrease for you to
remediate. And that's something to keep in mind. If you start increasing cost, even
minimally, even though some of these methods might not be 100% effective, they eventually get
in, you're still increasing cost to the attacker and thereby increasing the OODA loop time that
they might have to.
And, therefore, you might get inside what is called their OODA loop to make a decision faster
than they did. And then, lastly, noise and anomalies. That's always a fun one. You know,
random IPC shares to things, you know, as the bad guy is enumerating through and trying to find
things. That actually becomes very interesting. The attackers are usually using some form of
automation and scripts up front. 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, you've just snapshoted the
machine back to an older version. Guess what? They have to go all the way through exploit again
because they've now toasted their, or the snapshot back to a previous version has now been
toasted their ability to go from exploit to install and back to command and control. That
sets them back in time. Or they're sitting at install and they, 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 just one visual. You know, the same type of visual
for tool unavailability.
And, you know, that same concept of, hey, you have to exit one phase to get to another. 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 a path for the bad guy.
So, alright. So what I did is I sat down and just, you know, in Excel, started plotting out a bunch of
attack, 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 guessing that the
particular attackers are using. And it's 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 lot of, a lot of the things, the
few actual live, 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, I was looking at those cyber
resiliency techniques which are really the money that I started to frame these maps into. So as a
result, I mapped out this one. You're not going to be able to see it. It's an attack pattern. But
really you just kind of see, hey, the general, hey, this is what the entire attack pattern might
look like over time for each phase and mapping it out. I actually mapped out close to 10 in
conjunction with some other folks. Mapped out Axiom, Cleaver, Dark Hotel, Fin4, Zero to Hero
scenario, Sapu for all scenario. And then I mapped out the attack pattern. And that's
stuck on your DC things you might see in past lives or open your DER 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 a category of 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're
exploratory phishing attack, your port scans, your Google will show 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 this particular attacker. And
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, you know, attack techniques that, you know, were research based. And, of
course, I found MITRE's CAPEC, common attack patterns and enumeration catalog. But for anybody
who's gone out there and looked at it, 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, there were 500 or there were
400 techniques at that time. There are now over 504. And so it became slightly unmanageable.
Yes, I could go and map and start throwing out attacks. But, you know, I was not able to do it. I
was just throwing in to each, potentially each phase, those techniques. But I realized
something. Wait a second. I tripped across this other framework that was just coming out 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 late 2014, early
2015. I'm like, hey, that's a lot more manageable. Plus, it's relatively massive. It's
a lot more complicated. And so I started to map to an attack life cycle. And I said, hey, that
actually works a lot better. So I got an attack life cycle from, you know, something like
Lockheed Martin. And I can map these attack tools techniques straight to the attack life cycle
right there. Therefore it was a win for me. So what does that look like? As of at the time when
I started really building out my work, it was, it looked like this around 8, 2015. I started in
February really 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 attack techniques that, you
know, a bad guy could put in an area, an attacker could put in their pockets and start using
against a particular set of act on objectives, what they're looking to do. And the same
concept is true. Light them up. You know, essentially build your path to the end game. And
that really made sense to me. And it made, you know, logical sense. So it was research based.
But the problem is 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 started to build out where there were some gaps. And it became 101. And this
is hot off the press. And I think that's a good thing. And I think that's a good thing. And I think
that's a good thing. I think that that's kind of cool because it was photos or gifs. But I think
that, you know, once you get to that point where you've got the web, you've got all these
boxes in there that you're looking at. It's absolutely awesome. It's such an amazing
thing. You know, these days the end game, you know, they're all trying to get people to
use their own, you know, different game. And so I think the bottom line is they're not being
really important with our end game. And lastly, it's like, what do you think of all these
things. You know, we've got the
into this framework now. But back to the regularly scheduled program here, this was cool
stuff and this is what I was using as my build out to the initial attack patterns. But that
question of do they win and my old CIO's life came up. I'm sorry, this is a list that kind of
breaks it out too. But that question of do they win, that became kind of interesting. I said,
well, guess what? I have all these attack patterns listed out and research based. Why not
take somewhat of a 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 tool bag? And what it became was, hey, something like new service. What would you
do? You would maybe white list services so that they couldn't start if it was a bad new
service. Or you might black list certain services that you know that particular attacker is
using. You might service, do service start failures and dependencies. So I started listing
out this set of complementary 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
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 lifecycle. Then
that really started to resonate. I'm like, well, if I invest in a particular set of attack
techneake or defensive techniques like time disruption, I get the most effect across the
attack lifecycle. Deception, I get this enormous amount of luck. For example, if you use a
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 in saying,
if I invest here, I'm going to have to invest less in 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 in some cases, if you look at analytic monitoring, maybe your big
data lakes and trying to find that needle in the haystack, that's a hell of a lot of money.
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 haystack. This, this when mapped out across the attack life cycle,
only showed detective and potentially preventative value throughout certain phases not as
a middleman at the time of that attack, but to fit through over the season from that
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 called 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
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 attack life cycle. Maybe I have a game. So I
started a mock up, and I didn't, 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.
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 the attacker as red and the defender as blue just as a
convention and started a mock up. And what they, and I also put together a board. And you'll
notice that this board, you know, I first thought about the Lockheed Martin attack
life cycle or whatever attack life cycle you might want as a potential candy land 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 board kind of in a woo way approach, give take approach or 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 , and all the way in through to act on
objectives. So your goal is to keep the guys out as a defender, or if you're the attacker, your
goal is to get to act on objectives. And it made sense. I started tearing down the cards to make,
okay, what could these cards look like, and how would they be built out? They have a set of phases
they could be used in, so this, these sets of cards, the first, the attacker card here, we're just
can be used in recon, exploit, C2, and actions. And it's a lateral movement card that does
the attacker in this case is hiding in the application deployment software. So SMS or
something like that. But 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, for more advanced
play, there's cost and upkeep. And that's, you know, cost is kind of that real strategy play of
figuring out, hey, how much would doing a defense like this or an offense like this a 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 table rules, we're going to
work. You would say, hey, this card's being used this way in my story. And some of the most
fun that we've actually had playing the game was with some of the stories people would come up
with. It's actually a little crazy. But what do they, you know, how many cards are there?
There's over six unique attacker cards within the sets of decks I've 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, 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. And our threat actors 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 free to free, you know, there's a lot of
different ways to do this. You know, you can go from being a freelance spy, corporate spy, all the way
down to war fighter or political, social, you know, motivations. It was interesting to kind of
break those down. And the way it would work is those chips go face down on the board so the
defender does not know what is actually being 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 that I've done. And I think that's a
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 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 in and of itself. You choose which cards you play or you're
going to have in your hand. You know, the attacker chooses. The defender chooses. The chips
might be faced down or dealt. The act on objectives might be faced down or dealt. But that's
kind of the tactical play. And then the last one is 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. So that was one of those ones. We 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 all that stuff to GitHub. 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. It's that
simple, that easy. And the cards, that's something that I'll talk about in a few seconds. The
sample video of gameplay, 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, life cycle 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, you know, defenders and attackers what, you know, 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 becomes, you know, it becomes a
security mindset in those defenders who don't do offense. You know, there's, when we played with
engineers and played with other like forensic investigators, they 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 life cycle concept or vocabulary and then also building
out a security mindset. Demonstration, mini tabletops. We played that out with a few, you
know, maybe some events you've had go on. How the hell did that happen? What did, you know, what
would a defender 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 technologies, things that I could use.
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 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 do you get to this particular act on objectives? How do you get
to that particular act on objectives? And they start playing out games for themselves and
draws them into that attack versus defense type 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 DAI. And that you can actually use that as part of your
game play if you'd like. Cost rationalization based on a thousand seat contract. That's kind of a
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 lives. And then there were prior art. There's hacker, hacker two, control out 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 compliment to the attack framework, and the Lockheed Martin cyber security kill chain. So,
what are the next steps? Submit work for contacts, 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 need, I want some help with this. This is actually where real money can be had. This is
interesting. But I'm looking to, you know, give it away and see if I can get it back. So, you know,
see if folks figure out, you know, ways to help me digitize it so that I can watch them play the
games. So that we can watch them play the games. 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 Teneman episode of South Park. I won't get
into that here. But for those who have seen it, they probably understand how that works. And
lastly, you know, let people play, update their decks. Watch their 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 defensive cards develop. And so, this is a place you can contribute, volunteer, get the
latest developments. As I said tonight, I'm going to post things. Probably going to be late.
Twitter, Cyber Maelstrom, GitHub, Maelstrom the game, DEF CON 24. You're actually going to be
able to print off your own copies if you want to. That's, I'm going to, I'm working on that. 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 the game board off 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. Crowd source 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'm going to give you a
little bit of the credits. I mean, without the ATT&CK framework, none of this information would
have been possible. Nor kind of that concept or bridging concept. The cyber resiliency
engineering framework was key just because I was buried in it at the time. Obviously Lockheed
Martin, Kill 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 to, you
know, contribute to the community. So that's what I have.