Preparation
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
>> In this video, we're going to talk all about preparation,
00:00
we'll cover preparation basics and then
00:00
examine the Cloud impacts on the preparation process.
00:00
Before we get too far,
00:00
let's keep in mind,
00:00
when you fail to prepare,
00:00
you're preparing to fail.
00:00
There are many references and
00:00
variations on this long-standing proverb.
00:00
John Wooden was a wildly
00:00
successful and influential basketball coach
00:00
at University of California, Los Angeles, UCLA.
00:00
Keep in mind that I'm an alumni of
00:00
the cross-town rival University of Southern California,
00:00
but I have great respect for UCLA in many aspects
00:00
and I honestly admire
00:00
John Wooden and many of his philosophies.
00:00
If you ever want to learn more about leadership,
00:00
going well beyond the sport of basketball,
00:00
I highly recommend his books.
00:00
Heeding John Wooden's advice,
00:00
let's get into specifics of
00:00
preparing for cybersecurity incidents.
00:00
The CSA guidance summarizes
00:00
some valuable points that you'll want to internalize,
00:00
define a process to handle
00:00
the various types of incidents.
00:00
Ideally, this is in writing.
00:00
If you like writing long policy documents, that's great,
00:00
but having a shorthand decision tree for
00:00
the team to reference is incredibly valuable.
00:00
Handling communications, we talked about
00:00
this and we'll talk about this more in just a moment.
00:00
Incident analysis, hardware and software.
00:00
These are the tools you'll want to have to
00:00
perform forensic activities,
00:00
they will come in handy during post incident analysis,
00:00
but also in figuring out how to
00:00
quarantine the source of the problem.
00:00
Internal documentation on normal behaviors.
00:00
This is helpful to prevent false positives and
00:00
determine when things are back to the expected state.
00:00
Training, have you ever heard the saying,
00:00
an ounce of prevention is worth a pound of cure?
00:00
This especially applies to end-user training,
00:00
whether we were talking about
00:00
common business users or developers.
00:00
Of course, when things happen,
00:00
which they will, responders need to know what to do.
00:00
Proactive system scanning and
00:00
network monitoring allows you to detect problems
00:00
early and helps you prevent things from
00:00
escalating from bad to worse.
00:00
Finally, subscriptions to
00:00
third-party intelligence services.
00:00
These services are extremely helpful resources
00:00
to get information about your adversary.
00:00
They help you in classifying
00:00
the problem and determining ways to contain it.
00:00
The Cloud paradigm has an impact
00:00
on those fundamentals we just covered.
00:00
As is the case with
00:00
so many other parts of the shared responsibilities model,
00:00
governance and SLAs act as
00:00
a key tool for addressing these impacts.
00:00
For starters, it's very
00:00
important you understand the allocation of
00:00
responsibilities between the customer and the provider.
00:00
This way, your preparation plans can
00:00
build on assumptions of who's doing what.
00:00
Be sure you have support plans with
00:00
the provider to reinforce responsibilities,
00:00
setting expectations for things like,
00:00
how quickly is the provider obligated to
00:00
respond and acknowledge an incident report?
00:00
When is the provider obligated to send you
00:00
notification that there are
00:00
incidents affecting their service or perhaps when they
00:00
observe incidents affecting
00:00
your tenancy within their platform?
00:00
When there's an incident, what logs
00:00
and data will the customer have access
00:00
to and how long will it provide a
00:00
retain those logs after the incident?
00:00
Let's speak further on communication and the kind of
00:00
things you want to account for
00:00
in your communication plans.
00:00
Demarcate how the provider
00:00
contacts the customer and vice versa.
00:00
Remember, we're talking about security incidents
00:00
here so the path to escalate
00:00
may be different than
00:00
traditional support and customer service channels.
00:00
This brings us to the next topic.
00:00
Define the incident response teams
00:00
between the customer and provider.
00:00
Be sure not to use individuals as contact points.
00:00
People get sick, go on vacation,
00:00
and even leave companies altogether.
00:00
Making sure to update each provider whenever
00:00
these things happen can be tedious and error-prone.
00:00
Consider a hotline that forwards to a pool of
00:00
callers or an escalation list of multiple individuals.
00:00
Establish out of band communication methods.
00:00
In the course of an incident,
00:00
you may not be able to rely on
00:00
digital services during an attack,
00:00
email, chat, etc,
00:00
so have backup methods.
00:00
If you're a telco provider and being attacked,
00:00
you may need to rely on
00:00
different carriers or different technologies altogether.
00:00
However, it's eerie unlikely that you'll need to
00:00
resort to the canon string method
00:00
you see in the graphic below.
00:00
Last but certainly not least,
00:00
be sure to test the process
00:00
before a real incident happens.
00:00
This is something you should do on an annual basis
00:00
or whenever there are large changes
00:00
to the support channel.
00:00
Data and logs provide you
00:00
valuable insights during incident response.
00:00
Understand the data you can collect,
00:00
keep in mind your Cloud providers aren't going to provide
00:00
you logs that compromise other tenants.
00:00
Set expectations on retention periods.
00:00
Don't assume you can come back any time
00:00
after an incident and ask for forensics.
00:00
Cloud providers can't keep all data in perpetuity.
00:00
Your visibility in the logs will be
00:00
less as you move from IaaS to SaaS.
00:00
Regardless of the service model,
00:00
you don't have access to the physical layer,
00:00
which means the toolkit you rely on for
00:00
responding and isolating incidents will be different.
00:00
This is where the Cloud jump kit comes into play.
00:00
For example, Diffy is an open source tool developed by
00:00
Netflix security intelligence and response team
00:00
and it's specifically designed for AWS.
00:00
The little logo on the top corner is the icon for Diffy.
00:00
See if you can spot the differences between the two cats.
00:00
Be sure your jump kit can examine
00:00
Cloud Platform activities at
00:00
the meta structure layer and it also wants to be able to
00:00
interpret and understand activities
00:00
of Cloud resources themselves.
00:00
This is the applistructure layer.
00:00
You may have heard the term security by
00:00
design and this is an aspect to that,
00:00
incident response by design, we'll call it.
00:00
Since your visibility is limited in a Cloud environment.
00:00
Add log in to your applications that
00:00
can help you see what's going on.
00:00
Be sure to store logs in a secure location that
00:00
investigators can access, but attackers can't.
00:00
You don't want them covering their tracks.
00:00
We previously talked about
00:00
network micro-segmentation and
00:00
even full-blown isolation strategies.
00:00
The goal is to minimize
00:00
the blast radius and impact of an incident.
00:00
Immutable servers shouldn't change when they are running.
00:00
This simplifies detection.
00:00
Did the server change from its based image?
00:00
It also simplifies recovery.
00:00
I'll reinstate a new server from the base image.
00:00
Infrastructure as code provides
00:00
an approach similar to the immutable server thinking.
00:00
IAC technologies let you
00:00
declare the way things should look.
00:00
If there are differences between the way things are set
00:00
up or says how you have
00:00
declared the way they should be set up,
00:00
running these tools will
00:00
realign the Cloud resources appropriately,
00:00
getting you back to the state that you've expected.
00:00
Whiteboard hacking is a great way to assess
00:00
vulnerabilities and create theoretical attacks.
00:00
Threat modeling is a structured way to perform
00:00
these assessments and tabletop exercises
00:00
can be a lot easier and less
00:00
costly than full-blown penetration testing.
00:00
In this video, we covered the preparation basics.
00:00
Then we went over the impacts of Cloud on preparation,
00:00
focusing on communication,
00:00
data and logs and architecture.
Up Next
Similar Content
