As a security professional, you'll
be responsible for responding to security events that
occur in your organization.
Events like a user clicking an email attachment
and suddenly infecting themselves with malware,
and that malware then begins communicating
with other services and sending information outside
of your organization.
Or maybe you're dealing with a distributed denial of service
attack with botnets that are overloading your internet
connection.
Or maybe information that was stored confidentially
on your servers, has now somehow made its way
onto public servers on the internet.
And sometimes the thief contacts you before making it public,
to see if you'd like to pay a little money to keep it away
from the public's eyes.
Or you can have a user installing
peer-to-peer software inside of your organization
and effectively opening up all of your systems
to access from the outside.
Each one of these security incidents are very different
but they all require some type of response
by the security professionals in your organization.
These types of incidents are often responded to
by your incident response team.
This is a group of people that have been specifically
trained to deal with these types of circumstances.
This might include the IT management
team for your security department,
so you have corporate support.
It could have compliance officers
that are responsible for making sure that all of the data
is compliant with all of the rules and regulations followed
by your organization.
You'll of course need technical staff
to help troubleshoot and resolve these types of problems.
And there may be users in your community
that can help with these situations as well.
This is certainly not a comprehensive list,
you could have management within the organization,
public relations, applications developers, and other people
who would be critical for responding
to these types of incidents.
NIST, or the National Institute of Standards and Technology
here in the US, have created a document
that can help you understand the process you'd go through
to handle these types of security incidents.
This is NIST special publication 800-61 Revision
2, which is titled computer security incident handling
guide.
This gives you information about the entire lifecycle
when you're handling a security incident.
This includes preparation, detection and analysis,
containment, eradication, and recovery, and lastly
your post-incident activity.
The key to handling a security incident properly,
is to make sure you're well prepared.
There needs to be all of the right people and processes
in place so you know exactly what
to do when the incident occurs.
This would include communication methods, which
will document exactly who should be contacted
and how they should be contacted,
this would also include your hardware and software tools,
so you know exactly how to respond to these problems,
store and capture data that's important
and be able to have information that you might want
to use later on as evidence.
There will also be a need to have documentation
of the organizations network, , understand exactly where data
may be located, and once you have created and stored some
of this evidence you may want to create hash values of that
information so that you can be assured that none of that
information changes.
You also want to prepare for the mitigation process,
so you want to be sure that your planning includes
a clean operating system and application images.
And lastly, and probably most importantly,
we need policies and procedures so that everyone
knows exactly what they should be doing when a security
incident occurs.
To be able to respond to a security incident,
you have to know that the security incident has occurred.
And there are many different ways to monitor and identify
these security incidents.
This is an ongoing challenge because we
receive so many different types of attacks
all the time, every day.
And there are always security tools
we have in place that will prevent the majority
of these types of attacks.
But how do you identify the legitimate threats
and know if a particular incident has occurred?
These security incidents often include many different devices,
many different operating systems,
and you often need someone who's very knowledgeable in order
to understand exactly when an incident might have occurred.
Sometimes we can be informed when
the potential for an incident may have increased.
These precursors give us a little bit
of a heads up or at least help us
to predict where particular areas of the network
may receive a security breach.
For example, we may look through a web server log
and see that someone was using a vulnerability assessment
tool to try to identify any open or known vulnerabilities
on that server.
Or it may be that announcement day
where we receive a list of vulnerabilities in Microsoft
operating systems or Adobe Flash, that tell us
that we need to update those systems to avoid
any type of vulnerability.
Or there might be direct emails, Twitter messages,
or Facebook posts from a hacking group
that tells you that they are going
to try to attack your network.
This means that we'll need to monitor our systems
and see if we can identify cases where a particular security
incident might have occurred.
For example, we might find that our intrusion prevention
system has identified a buffer overflow
attack against our system, and they can tell us
whether that particular attack was successful
or whether it was stopped by the IPS.
We might also have alerts and alarms
that come from our anti-malware or antivirus systems that
can tell us if a particular piece of malicious software
is running on a device.
We can also have messages from our file integrity
monitoring systems that will be able to tell us
if any of the critical operating system files on our servers
have been changed or modified.
And if we're monitoring network traffic,
we may be able to tell if there are differences in the traffic
as compared to what might be normal on that particular
segment.
If you do find that there's malicious software or some type
of breach, one of the best things you can do
is isolate and contain that particular security incident.
You would never want to leave it running just
to see what it does because nothing good can ever come
from a situation like that.
Instead we might want to take that malicious software
and run it in a sandbox.
This would be an isolated operating system
that is specifically designed to run software and see
what the results of running that software might be.
This is also an environment that can be completely deleted
after performing your analysis, so
that you can be assured that that malware is not going
to get outside of your sandbox.
But even the sandbox doesn't provide for perfect analysis
of malware.
Some malware can recognize when it's running in a sandbox
and it will perform differently in a sandbox
than if it's running in an open network.
And there's some malware that recognizes
when you lose connectivity to the internet,
so when you isolate that system, it
begins deleting files or damaging the operating system.
Once we've identified that an incident has occurred
and we've identified where malware might be on a system,
it's time to recover that system.
We would first need to eradicate this malware
and remove it from that system.
Sometimes this involves completely deleting
everything on the system and recovering
from a known good backup or a known good image
or we may want to recover the system
and then fix the vulnerabilities that caused this incident
to occur in the first place.
This is why it's always important to have a backup so
that you can restore this system very quickly.
If you don't have a backup, then you'll
need to rebuild the entire system from scratch
and in some cases, you may have lost data because you
don't have a backup.
In either of those situations you'll
want to be sure that you have rebuilt the system
and that you have then repaired the system to close
any of those vulnerabilities.
And lastly, you want to lock down
the perimeter of the networks, so
that you can stop the attack before it
gets into your private network.
On large networks, the reconstitution process
can be very difficult and very time consuming.
You want to be sure that you have cleaned every system that
could have been touched by this malware,
or this security incident, and this might take months of work
to be able to recover everything on the network.
This usually starts with making high value changes
and making changes that can be done very quickly.
So we may want to send patches out to our systems,
or modify the firewall to prevent
a certain type of traffic from entering your network.
Then you can look at a much larger response
across the entire infrastructure and begin
looking at changes in how the network is designed,
look at the operating systems that
may be used for a particular project,
and perhaps roll out additional security controls
so you can prevent these types of incidents
from occurring again.
And once the incident is over, we
can take a step back and look at what processes worked
and what processes didn't work during our incident response.
We might want to have a post incident meeting where everyone
attends to talk about what occurred during the process,
and we want to be sure we do this as quickly as
possible because we tend to forget some of the details
as time goes on.
You want to make sure you have plenty of documentation,
and that you're able to offer ideas on what to do better
for the next incident.
An important piece of documentation
would be able to understand exactly what happened,
and when it happened, so you know exactly the time frame
that everything occurred.
You also want to examine how all of these
plans you put in place before the incident were
able to execute during the actual incident.
And then what would you do next time
to make those plans work even better?
Being able to look back and have an objective view of how things
went is going to help you the next time something
happens on your network.
And it may be that this particular incident has caused
you to have a different idea of things
to look for the next time.
So you may want to update your alarms and alerts,
so that you're able to receive additional precursors that
might identify when an incident is going to occur.