hello everybody Welcome to track two and
uh today we have Alan and Alan works on
technology leadership team at Airbnb
where he mostly focused on threatened
thread detection and incident response
and Alan really really enjoy incidents
so oh why don't you take it away okay
[Applause]
hey y'all thanks for coming to my talk
uh so this is how I learned to stop
worrying and build a modern detection
and response program so today I'm going
to share with you a framework that will
help you build a modern detection and
response program
you'll come away from this talk with a
better understanding of what your
program should look like how all the
tools capabilities and processes should
fit together and how to analyze build
Implement and evaluate so your program
provides immense business value but
first hi I'm Alan I'm a senior staff
engineer at Airbnb I'm also a dad which
you could probably tell by my stunning
dad shirt I live in Austin Texas with my
wife and little two-year-old son Liam
here we are in a
very giant adult-sized ball pit and I
almost lost him many times in there
he was he was in there a really long
time I got real worried and this talk is
in a way inspired by Liam uh you see I'm
a worrier uh and being a parent and a
warrior is a very fun combination I
remember when Liam was just a few hours
old
barely lump and I was sleeping in the
little Hospital caught that the dads
sleep in next to him
and he was in the bassinet and I was
listening to him breathe because I'm a
worrier and then I noticed that his
breathing sounded a little different now
I've been a parent for about
20 minutes so everything sounds really
different to me but I'm worrying so I
get up to look at him and he looks
purple
but yes he does look purple he's also
only like been outside in the world for
a little bit so I don't know if it's
like normal purple or like bad purple
um
but I I'm I'm worried about him but I
know what to do I have a plan I took an
online parenting class during covid and
I paid very good attention
um so I flip them over in my hand Pat
Pat and he spits up and starts crying
but he's breathing again he's fine
um and Liam gifted be something really
important that day and that's
perspective on my worrying and I
realized something uh worrying can be a
superpower
there's this research paper out of the
University of California Riverside it's
called the surprising upsides of worry
and in this paper they argue that while
worrying especially at extreme levels
certainly has its negative outcomes
there's a really cool upside to worry
here's a quote worry illuminates the
importance of taking action to prevent
an undesirable outcome and keeps the
situation at the front of one's mind to
ensure that the appropriate action is
taken
and when I read that I said oh hey
that's what I do on Blue Team
um so Warriors which I will frequently
mispronounce as warriors
uh bring a unique skill to detection and
response we are constantly thinking
about what could go wrong
but we need to make sure that we have
the knowledge to take action and here's
where I see a lot of programs fail so
I've been doing detection and response
for a little over a decade but I didn't
start here I started my career more on
the red team side of things and I got to
watch lots of blue teams fail Time After
Time
and then when I switched over to the
blue team and started working a
detection response I found that myself
and my peers while we were created
accomplishing the technical work uh none
of us really had an idea what a
detection and response program should
look like or that we should even have
one we just did our tasks and our
projects it was pretty ad hoc and we had
no bigger picture or strategy in mind
and I think this is one of the major
reasons blue teams fail
we're taking lots of action we are
really busy but we're really making it
up as we go where we copy what we did in
our last organization because it kind of
worked there
so after making lots of mistakes I took
all those lessons and I built a
framework that finally worked for me and
hopefully I'll help you make a much
better detection and response program
and this way you all can learn from my
mistakes and make better more informed
mistakes than I did
I learned something else when I first
became a parent everyone has advice for
you and some of it is useful
and a lot of it isn't
and the reality is that you have to
figure out what works for you and your
kiddo but I have found that the advice
that's been the most helpful is less
prescriptive and provides resources and
tools
so when I was building this talk I asked
myself is this a methodology or is a
framework and you're like well I don't
remember the difference so some
characteristics of a methodology are
that it's very prescriptive it tells you
exactly what to do the steps are very
systematic they must be done in a
particular order and there's usually not
a lot of room for creativity or
customization but to delivered outcomes
usually consistent
on the other hand a framework has a
loose structure it's flexible gives
leaves room for other approaches it
still provides you most of the processes
and guidelines required to succeed but
in the end you can still choose what you
want to use and it definitely leads the
inconsistent outcomes but every
organization has different lines of
business areas of risk technical
capabilities
so I chose a framework because I want
you to be able to apply this to your own
program so as we go through the
framework today think about how you
might need to personalize or customize
for your own organization
but before we talk about how to build
and implement this framework let me put
some things in historical context so the
30-second version of like wear detection
and response comes from is that late 90s
early 2000s you get the security
operations center the sock they get a
little popular and these spun out of a
thing that's been around much longer the
network operations center the knock
and initially uh socks were pretty
focused on things like anti-virus and
ids's maybe some firewall if uh you know
the knock let them do that
um and then more to our tools start
rolling in we start to get SIM and ueba
thread Intel platforms kasby EDR
um you know we get all these alerts now
so now we need to have soar and a data
Lake to help us automate and investigate
and
there's been lots of advances in our
tooling
but even if you have all of those I
still think that many organizations are
still operating in a legacy model
so let me talk about what I mean when I
say a modern detection and response
program
so first a legacy program is reactive
the focus is on alerts that indicate
something bad has already happened and a
good a good way to know if you're in
this is that you find most of your time
is spent just trying to get to that
alert q0
you'll never get there by the way
uh Legacy program focuses all its
strategy on the technology when you
describe your program do you find
yourself talking about the tools you
have the vendors you do business with or
do you think about what capabilities you
actually have and how those Empower you
to do the things you need to do in
detection and response
a legacy program has lots of manual
heavy tasks you might have automation
tooling but if you find that you're
doing most of your day-to-day tasks
manually then you haven't really
invested into thinking about automation
capabilities
and finally and personally I think most
unfortunately a legacy program operates
completely siled and disjointed from the
rest of the organization this puts you
out of touch with the orgs technology it
inhibits your ability to work side by
side with your partner teams
and you end up investing a lot of time
and money in the problems that you
should have been trying to solve
collaboratively
on the other hand a modern program is
proactive and that doesn't just mean you
do a thing called threat hunting it
means your philosophy of detection is
the idea that you want to detect a
threat as early in an attack as possible
and that there's many signals you can
correlate before the something bad has
happened alert needs to fire
and instead of being so tool focused a
modern program builds strategy that is
business focused and by that I mean we
Empower our teams with more than just
requirements but also the context of how
what they're working on empowers the
business to do what it does
a modern program prioritizes automation
so when you're implementing processes
integrating your tools your first
thought should be how will we automate
this instead of creating your manual
playbooks and sure hoping you're going
to automate it in the future
you probably won't and finally a modern
program is connected to the business
centralizes functions workflows and data
because you can't succeed by doing it
alone you'll never scale
and I saw some of you nodding your head
agreeing but also
what about the challenges in my way is
what you're also thinking and I know
them very well it's the alert fatigue
that's grinding any sense of hope that
you'll move forward it's your lack of a
budget to get the expensive tools you
need it's hiring and retaining talent
because these roles often lead to
burnout
and it seems that you'll never get out
of firefighting mode and the incidents
just keep coming
so whether you're a CSO or director you
just want to understand where Modern
detection and response fits in the
overall security program or if you're a
manager building processes hiring the
people executing this type of work or
you're an engineer an analyst a PM that
wants to understand the bigger picture
this talks for you
and if you don't know much about instant
response this is also a good talk I
think
so I'm going to help you get to a modern
program with a framework to guide us
today methods to help you measure and
Report how your program is detecting and
stopping threats and along the way all
the lessons I've learned about
empowering teams to succeed and overcome
operational time sinks
and like all good Frameworks this one is
based on work done by people much
smarter than me which is most people
although I'm fairly certain none of them
ever worked in information security
because we're going to follow the
process of organizational design so what
the heck is organizational design you
may ask well Gartner defines it as the
process of creating structures the line
rolls workflows okay hold on before you
doze off
I read this book called organizational
design a step-by-step approach so you
didn't have to
and this book lays out a seven step
process for designing your organization
I uh I made it four steps because most
of you probably haven't had enough
coffee to have seven steps and so these
are the four phases of the framework
we're going to work through today
we're going to assess and analyze our
current state
design and develop our ideal program
which is where we'll spend most of our
time and then we'll talk about when it
comes time to implement how we overcome
operational challenges
and then finally we'll evaluate and
Report using metrics that tell the story
of how this program's performing with
narratives that sell it so here we go
so to assess and analyze
we start by asking
where are we and what do we have
so whether you're joining a new team or
you've been promoted or you've been
tasked or you just work on a detection
and response program and you want to
level up your current efforts
the first thing you need to do is
understand what your starting point is
do you have anything maybe you're in a
large program that has detailed metrics
that are constantly being reported maybe
it's just you and some antivirus
um now at a previous job a few weeks
before I started there my boss emailed
me this book and I'm not really a big
fan of business or optimization books
but this book had a lot of great
information on how to get yourself set
up to be successful and productive
faster when you start a new job
not directly relevant to this talk but
it provides a really great tool for
applying systematic learning to
understanding your current state
and the first piece of advice this book
provides is that you need to stop
stop doing and start learning
take a breath
sure things are probably on fire but
before we start fixing we need to First
learn and we need to learn from three
perspectives
past present and future
for the past perspective asking why are
things done the way they are
why
how has this program performed in the
past
how were goals set and were they
insufficient or overly ambitious
for the present are the reasons
something was done still valid today
how do people in the organization think
about detection and response and how
they're doing
and then looking toward the future are
the conditions changing so that
something different should be done going
forward
if performance has been good or bad why
was that the case and what behaviors did
the program encourage or discourage
and then we're going to ask those
questions from four different viewpoints
before we dive into each of these I will
say that if you are starting with
nothing
you have been given a gift
it significantly reduces the complexity
since there's little past or present
factors to consider when designing but
if you have a team you have tools and
processes in place you definitely need
to do this work so don't skip it
so first step we assess the Viewpoint of
vision and Mission and here you want to
think about these questions
what is unique about detection and
response at Euro organization
what unique problems do the culture the
technology the people at your work pose
for detection and response
and then what are people spending their
time doing
and maybe an even better question what
if they spent less time doing X and then
more time doing y would they be more
effective
so who do you ask well you ask your team
but who else might you ask these
questions
audience participation time
customers
stakeholders who who's our stakeholders
everybody
can we think of a couple
legal there's my favorite
get them in early
who else
yeah your developers your I.T team your
technology teams
leadership
they better be on board right
so here's a silly question how do we ask
nicely of course so I don't use
questionnaires often as a tool
but these are questions that may take
time for people to think about
um so actually this is a place that I
think questionnaires are actually pretty
appropriate but regardless of how you do
it your takeaways are
what are people doing because this tells
you what the implied vision and Mission
is which by the way is probably very
different than what's written down
and then what does the organization need
from detection and response
so then we assess the Viewpoint of our
people
we want to understand what skills we
have available to us as we're thinking
about processes and Technologies we want
to make sure that we understand what
skill sets we have before we start
building
so I'm going to point you to this
resource it's the nice cyber security
Workforce framework it comes from nist
it does a pretty good job of
categorizing and describing the
different types of cyber security skills
and nice skills are defined as these
things called work roles there's lots of
them but to give you a jump start I've
grouped them into like the following
detection and response roles and these
are general groupings and I'd expect you
to have responders that are also
detection and response engineers and in
fact I'll talk about you know how
there's a lot of space for overlap and
how I like that but I found that these
roles make it a lot easier to talk about
the skills without too much
customization
and then I assess so
I created a self-evaluation survey and
ask my team to rate themselves for each
of the work groups so for forensic
analysts I asked each member and it
comes each role comes with a description
of what it is what you know what needs
to be done and then have them rate
themselves they have no experience a
small baby Liam amount and then all the
way up to like parallel parking during
rush hour without breaking a sweat
I did not have them do it anonymously
but you could totally do it anonymously
across your team yeah
um depending on the culture of course
and then we use that data to create a
heat map
and that visualizes the experiences and
skill sets of the team so now you have
an estimate of what skills you have
where you have strengths and weaknesses
and where you have gaps
so then as you're evaluating your
processes and Technology decisions the
tools you're building and buying now you
know where to prioritize mentorship
where to target training and hiring
cool now we're going to talk in more
detail about processes and when we start
to design and develop we'll talk about
all the processes that I think should
exist in a detection and response
program but every organization is
different so let's capture what we have
in place today because maybe with
something you'll add in your process
design later on
and you've probably heard of it but it's
a good tool for evaluating processes
it's the capability maturity model
integration program cmmi and you can use
it to rate processes maturity
you start with lease mature at initial
where your processes are unpredictable
poorly controlled reactive and then all
the way up to mature where you're
optimizing and your focus is on process
Improvement
and then you do your Discovery find out
what are all the different processes
what's your incident response process
like how do you escalate incidents
what's your triage do you have playbooks
for different types of incidents and
then rate each process
and group them into General themes
um
and then depending on your situation
well
maybe it's not great
and maybe it's worth calling out how bad
it is so there is also the capability in
maturity model which I got from a very
deep dark Wikipedia following and it's a
semi-serious way that a captain in the
Air Force came up with as a way to
evaluate dysfunctional organizations
my favorite level is contemptuous which
is when
ineffectiveness has become apparent to
the larger organization but measurements
are fudged to make the organization look
good while they become more committed to
the ineffective processes
yep if you know you know
um so cool now we've obsessed our
assessed our people our processes our
vision and Mission so let's take a look
at our technology
and before you start making a list of
all the tools you bought stop
technical capabilities are not product
categories
so what do I mean by that
first
you might have something called EDR
I might have something called EDR but
depending on the vendor the tool how we
implemented it the different type of
systems we run
what you're actually using in the tools
our capabilities might be very different
and second I think product categories
are confusing
it could just be me but if I asked five
people in this room what xdr was I would
probably get five different answers
so as we're analyzing and designing our
technical architecture focus on the
capabilities the use cases instead of
the product categories so instead of
being like I've got EDR which by the way
is endpoint detection and response for
folks that may not know because remember
product categories are confusing
um we would document capabilities like
fileless malware detection forensic
artifact collection volatility memory
Imaging host isolation
and then think about the capabilities
outside of your own team's ownership
that could be what you use during
incidents for messaging ticketing
alerting that stuff's really important
too
so
that's it now we've got an understanding
of what you're starting with the
historical context and where things are
currently trending you did great you
stopped you learned now let's have some
fun and design and develop our program
and when I design and develop I like to
think about it like we're telling a
story
because stories are memorable you may
never remember anything from my talk but
you'll remember the little story about
me Pat my little guy on the bus back
there and throwing up our brains are
wired to remembered stories uh so my son
Liam is two he can't read surprise but
he can recite this book about Leo going
for a swim word for word so having a
mission and a vision statement is cool
but when you start to talk about your
program like you're telling a story
that's when it can really start to
resonate
so with that in mind let's start
designing and developing so in this
phase we're going to create three
deliverables
first we're going to ask ourselves what
processes do we need in our program
design and processes tell the story of
what we do
so to better enable this storytelling
I'm going to build this thing called a
process View
and this is a diagram that gives a
visual representation of the processes
within our program how they interact
with each other and it's not intended to
be an exact diagram you can make one of
those but it'll be an eye chart
remember what you're doing is you're
telling a story
so I'll start from an ideal beginning
our first process is threat modeling
where we build profiles of thread actors
get intrusion sets and understand what
type of threats we care about the most
and the story I'm telling here is that
our program is fueled by thread Intel
Intel being coming from both internal
and external collected analyzed and then
disseminated throughout our program
whether that's in the form of threat
briefings iocs or hunt packages
uh the story I'm telling here is that we
don't want to reinvent the will we still
need the classics event monitoring
triage analysis incident response
forensics
um
the story I'm telling is that we are
proactive our Intel often from our own
incidence is used for threat hunting
maybe starting out with simple automated
ioc searching and then moving to doing
creative data analysis looking for
undetected threats
and then the story I'm telling here is
that as we continuously that we
continuously test and improve our
program with something called micro
purple tests
tests that simulate threat techniques so
we can validate that our detections and
how we respond actually work
and then we use those tests to
prioritize our logs our detections our
responses
and the story is that continuous
Improvement needs to be Central to our
program so that we can prioritize what's
the most important work we're doing
including things that come out from
threat hunts like we have gaps in our
application logs
and something I talk a lot about in my
life is that visibility without context
is never good enough you can have all
the logs in the world but doesn't mean
they're helpful if you can't integrate
it with your thread intel if it doesn't
really provide you context of your
systems your networks your applications
your Cloud platforms
you want observability you want to be
able to write detection rules that you
can actually find known bad anomalous or
risky activities without that context
you can't do it
and threat hunting is a great input to
your detection engineering
and so then when our detections fire all
those Classics over there built with
automatization Autumn automation
prioritized then rapidly triage analyze
and respond
and then finally the story I'm telling
here is that this program's performance
can be measured and that data is used to
communicate how we're succeeding
improving changing and investing
and then we can Circle back to the
beginning where incident data flows back
into our threat Intel collection so that
we can continue to inform the program
with new threat hunts threat briefings
and detections
and the cool thing about a framework is
that you might see things totally
different than I do and that's fine and
you know you should talk to me after I'd
love to hear
but then you can zoom out and you can
start to see that our reporting and
metrics can also inform our red teams
with new scenarios our security
awareness teams with metrics about
phishing events so that we can better
educate our users and put better
preventions in place
and then all of our partner security
teams
our production security our corporate
security so they can build the controls
that help prevent the incidents that are
actually happening that we're seeing
cool now we got processes let's take a
look at building our architecture
and we're not going to list product
categories right
we care about capabilities
and I start with the process view I've
tried to do it the other way but I think
it's easier to think about what we need
to do before we come up with what
technical capabilities we need to be
able to execute on them
so here's some resources available that
can help you think about capabilities
you're probably familiar with miter
attack
gives you you know a really great list
of attacker tactics and techniques and
one way I've used this is I'll walk
through the framework which is Super Fun
by the way and ask what capabilities do
I need to detect and respond to this and
then I think about it
on my Mac systems on my Windows systems
my Linux systems my the cloud all my
Dockers
and then we have miter defend which was
released not that long ago and it's a
catalog of defensive techniques so it
helps you answer what capabilities do I
need for specific techniques it's a
little bit prescriptive and might not be
applicable to like your environment but
it does have really great analysis
techniques so I think it really shines
there
tines have this sock automation Matrix
it lists all the common activities most
socks want to automate it's a really
good starting point when you're thinking
about what things you want to be able to
automate like alert handling issue
tracking enrichment user interaction
and then it has lots of really good
examples of how to automate those and it
covers things that you probably haven't
thought about like automating your
documentation and change management
because I bet you're all really good at
documenting
thrilling stuff
and then finally snowflake have this
detection series on medium about
building detections and then
analogy that to software engineering
which is an interesting approach
so let's go back to the process View and
use it to inform our capability
architecture
so
if we focus on thread Intel and think
about the types of data we'd like to be
collecting about our threat actors
intrusions maybe just raw Intel from
Twitter but also actionable Intel like
early warning signals dark web postings
related to your organization threats to
your brand and reputation credentials
for sale
and then we have to think about how
we're going to collect it disseminate it
and then integrate it across all our
tooling so that we can have true Intel
driven detection
and then if we switch over to the
classics I think about all the automated
capabilities I'll need in blue that
support my workflows to do the triage
and Analysis and then also the automated
capabilities I'll need in red to do the
response
and then for my more engineering focused
and proactive processes I think about
what I'll need to get observability from
my logs not just collecting but also
normalizing enriching aggregating
correlating giving historical context
and then optimizing so you don't spend
your whole budget
and thinking about how you need
analytics to detect threat behaviors and
malware
across all your things endpoints Cloud
SAS containers
and then how are you going to automate
testing so that you can check all the
different miter attack techniques in all
your different environments
and then you can put all those
capabilities together
and create our architecture View
and I've organized the capabilities and
the groups that tend to be more closely
related
and just as I discussed before the
headline of the story is that we're
going to take our threat Intel
so that we can enable Intel driven
detection so that our threat Behavior
analytics our malware analytics or micro
purple tests can be directly informed by
Intel
and then we take all that data turn it
into something that we can use for
observability build detections
generate alerts for automated analysis
so that we can trigger our rapid
responses that are automated across our
various controls
so now we have a long-term architecture
toward a modern program
and you prioritize what do I need most
what's the most important and then
that's how you start working toward your
Investments your building your hiring
so you know what you need to do you know
what technical capabilities you need to
make it happen
so then what roles do we need to build
and operate these
and to do this we come back to the roles
that we put together at the starting
point
and one topic I'll mention here is that
I'm starting to see a trend where
organizations are posting very specific
job titles like detection engineer or
threat Hunter and I don't think there's
anything like inheritantly bad about
that but I do know that like as humans
we don't like to be labeled and limited
in our abilities so I like to think
about these as roles that people can
move between
people like to vary their experiences
but also it makes a team like this a lot
less siled which is what can really
happen and it changes the different
silos motivations
but regardless of how you slice it uh
now you know what processes and
Technical capabilities you need you know
what roles you need based on your heat
map what's missing and what you need to
do to fill the gaps
and there's a lot of you that are
pessimists scoffing at this bright sunny
day that I just described I've built
these beautifully drawn processes and
Technical capabilities and I've got this
fully staffed team sounds like a dream
sounds great but what about my total
lack of a budget for these tools and
that hiring freeze
all right so let's talk about it
um so first of all let's talk about how
to make the most of the people you do
have so when I transitioned from being
an engineer to a manager my perspective
changed I had to take a step back think
about the bigger picture
and that's where I got this idea of
building these different views I'm back
in an engineering role and I realized
that these views are vital for everyone
but maybe especially the people the
engineers the analysts that are working
in it because these views tell the story
of what's the most important thing they
can be working on and where they're
driving value
and then when you are able to hire
people they know where to best Focus
their time and this is especially
important for those of us that are in
operational teams it's really easy to
feel pooled in the many different
directions and having a single view that
is this is what we're going to can
really help the team understand
if you're trying to build a new program
but you have a lot of historical debt
lots of noisy alerts lots of manual
tasks I have found two approaches work
really well the first is to declare
bankruptcy
you aren't going to solve yourself out
of this one uh it probably won't fly
with leadership so I also recommend that
you try to Outsource as much of you as
you can time box it but think about
hiring maybe a third party sock some
contractors something to throw bodies at
the problem
so that you can temporarily have your
team focus on building the bare minimum
of something that works so that you can
finally move forward
and then as you prioritize the technical
capabilities you need the inevitable
question of build versus buy comes up
now I'm an engineer I love to build
um but here's what I'd recommend uh I
think a 65 solution is the best solution
um and that doesn't mean that we ignore
like the basic principles that we need
to be able to use this thing with
automation we need to still be proactive
those things hold true
but if you can buy yourself a solution
that gets you 65 of the way there that
means your team can focus on the very
business specifics or program design
specifics that you have
and then of course While You're Building
you've still got incidents you still are
not operational team and those are
always going to be the priority but
especially at the beginning of
implementation
push back
let the less critical Things fall on the
floor we are really good at giving the
appearance of being really busy and that
makes people think that things are just
fine but as we'll discuss next uh how
you report can really open up your
leadership's eyes to the reality and get
them on board with shifting to a modern
program
so let's jump into it and just like
there was a legacy and a modern program
and I think some of you probably have a
fairly modern program but are falling
into Legacy ways of evaluating and
Reporting and it could be preventing you
from getting the support the funding the
head count that you really need to
succeed
and so when I say Legacy uh I mean
you're still thinking reactive by
reporting time to detect time to respond
time to contain and that's it nothing
else
uh uh and when I say Legacy it's a
report to leadership with the number of
events that happened last month in
comparison to the amount of events that
happen this month without any context
that doesn't help anybody no one cares
next slide it's when you report on what
you're seeing without any context of
what you aren't seeing
and overall Legacy reporting doesn't
tell the business the value your program
brings all they know is some bad stuff
happened that more things happened more
bad things happen this month than last
month and you're busy
a modern program though when you report
provides context around the detections
in place describing how threats are
being detected and what the impact the
business is
our reporting should focus on what
threats we're seeing can see are seeking
funding to see and it provides context
to the numbers what are the associated
threats what environments could be
impacted and where do we have visibility
and it quantifies these at least in a
narrative to the business risk like hey
that ransomware incident
that might have meant that we weren't
going to do business for weeks
at best
so I want to talk quickly about four
ways to evaluate and Report
and I've talked a lot about
observability and I think these three
questions really simplify what I'm
trying to get at
what can we detect today what threats
can we see and then what can't we see
what's our landscape coverage do I have
the same threat visibility in my cloud
platform do I have that I have on my
laptops
and then take both of those and answer
what's my overall visibility into
threats
and then to answer those questions
I had talked about the idea of micro
purple testing and that is running tests
that validate whether you can and can't
detect something
so here's an example of what running all
those techniques across miter and
scoring them as pass or fail might look
like
and in this hypothetical example the
story is that we've got great coverage
of Discovery and C2 techniques but if an
attacker
gets access and is able to move
laterally they're probably not going to
be detected
and that might be bad for business if
you've got poor controls between your
environment boundaries
next we look at the results of running
all those techniques across all our
different environments or what I'm
calling landscapes
and you can get a different view of what
tactics might be less likely to discover
here the story is this organization has
pretty good endpoint coverage but almost
no visibility into their containers
which could be a problem if that's where
the business apps run
and then to sum it all up you can
provide uh our hypothetical overview of
visibility and the threats based on our
micro purple tests you can make an
estimation based on the detections you
have in place but maybe you haven't yet
tested them and then waiting those by
the priority and prevalence of our
environments
and then these three reports tell
leadership these are the different types
of threats which ones we can see and
where and overall how we're doing and
then of course you could Trend it over
time you could bookmark where
Investments are being made where hiring
is happening and how you're currently
trending upwards or downwards
and then closely tied to that report are
a metrics and for those
alert numbers are good but instead say
we know what we can see
what threats are we seeing the most and
where which ones pose the biggest
threats to the business
and from what we can see what are the
trends in Impact
what preventative controls Investments
could reduce the risk
so instead of just giving a lot of
numbers that might not mean a whole lot
to the people looking at them
derived from your events what are the
top threats what are your top Landscapes
at risk and what are the top incident
trends that you the business need to
immediately address
and then speaking of incidents a really
valuable tool for evaluating and
Reporting is just using incidents as a
narrative to describe how well the
program is or isn't working you can
think about it from the process View
which process surfaced this up how did
triage analysis response go
you could think about it from your
technology view what technical
capability caught this which one did we
expect would catch this sooner what did
we have to do manually versus
automatically and what investments could
have made this better
and then we could think about it from
our people
did we have the skills needed to respond
and this is a good time that we can
address skill gaps job roles and whether
you need more resources
so as an example let's say you have an
event where a malicious email it gets
past your email protection solution and
a good thing happens the user reports
the phishing email
so you might use this event you can
highlight wins the fishing report was
triage your process worked in a timely
manner
you did really good analysis you have
processes and the people that can do
them
and yeah they found that the email was
malicious there were multiple recipients
and we found the one person that clicked
the link because we had this tool and we
had this process and we had the right
people so that we could execute a rapid
response isolate the end point delete
that email everywhere
and then feed what our analysis said
into threat hunting so we can look where
attackers might have evaded our other
defenses
extracting indicators
so that you could find that oh actually
there were victims we didn't see because
there's gaps in our email logs
and then we were able to respond to
those
and maybe it doesn't go well
this is a good opportunity to show that
there's a need for better investment
because honestly all the nice graphs and
data can go really well and it could be
a beautiful picture but sometimes a
story will go a lot further for
leadership to understand your challenges
and so with all those then you can
present a roadmap
we know what we can and can't detect we
know what type of threats are impacting
the business and we know how to make it
better
so here's where you make your asks I've
got the data to support that you need to
reduce the risk of these threats to the
business here's why we prioritize what
we did and then here's the road map to
close this
fund it hire for it
so cool we've gotten to understand the
current state we've walked through
designed and developing our own program
we've talked about how to get it done
while still operating and we've gone
over the tools you'll need to evaluate
and report on how amazing or struggling
your program is so that you can clearly
communicate your asks
so now instead of hiring based on the
number of alerts or investigations you
make
you can make data-driven decisions based
on the roles and the skill sets instead
of threat hunting because it sounded
cool your process view is a story that
answers what your program does how it
provides value and how you measure
success
and instead of buying based on what
Gartner or other vendors might tell you
that you need uh you have a vision for
your architecture your capabilities with
a prioritized timeline of what you need
and your clear asks to leadership
and instead of telling your boss yeah we
might detect it you have metrics that
describe what your threat coverage is
and performance from previous incidents
so hopefully you've now learned how to
stop worrying and build a modern
detection and response program
we have time for a couple questions
um but also this is my email and then
all of my social handles are on my
website I write an infrequent newsletter
called meoward it has an adorable cat
that people love and the security info
is just okay
so yeah if you have any questions
there's a mic in the middle of the room
thanks this is a great talk I appreciate
it uh maybe context so I'm a CSO that
also runs it privacy compliance other
groups CSO plus they call it uh and what
I'm always trying to figure out is how
to combine these Frameworks together I
love this but what's I'm wondering is
how you would include stakeholder
management uh in this like right away to
me this what this pops out as is what
the business cares about for incident
response is when are we back to business
not when did we start the incident
Lessons Learned so if you had to include
stakeholder management where would you
put that in this so I usually include it
in it so I'll re I think everyone here
right we're good I don't have to repeat
the question that's my favorite
um the so I usually included that
stakeholder view in two different places
so in the process view you have each of
those processes and all of those
processes have like their own very
detailed design inside of them right
this is what happens when an event comes
in this is who we need to escalate to
but I find that that can get lost really
easily and so having that zoomed out
look of here's all of our stakeholders
that we communicate and then having that
almost a stakeholder process
communication plan to each one this is
our contract and this is why I really
think asking those questions about like
what should we be doing as a program is
are so important because then when you
build that stakeholder contract between
them you've already asked those
questions and so then when you go
through your processes of all your micro
processes within your program you know
exactly what things are coming out of
the program that are going to them and
what things are coming back to you as
well so that's usually where I try to
like diagram at
any other questions
the slides will be somewhere uh if worst
case scenario please reach out to me at
my email I will absolutely send them to
you
I did not use Vizio
that's a good question though
great I appreciate everyone for coming
out to this talk and enjoy the rest of
your day