You can prepare for incidents in two ways:
by having clear and comprehensive security policies in place, as
well as the hardware and software resources to enforce them
by having a clearly defined plan to respond to incidents and a
properly trained team that can implement the plan
A key part of incident handling is understanding which parts of
your network are at the greatest risk. By deploying Firepower System components
on those network segments, you can increase your awareness of when and how
incidents occur. Also, by taking the time to carefully tune the intrusion
policy for each managed device, you can ensure that the events that are
generated are of the highest quality.
You cannot respond to an incident unless you can detect it. Your
incident handling process should note the kinds of security-related events that
you can detect and the mechanisms, both software and hardware, that you use to
detect them. You should also note where you can detect violations of your
security policies. If your network includes segments that are not actively or
passively monitored, you need to note that as well.
The managed devices that you deploy on your network are
responsible for analyzing the traffic on the segments where they are installed,
for detecting intrusions, and for generating events that describe them. Keep in
mind that the access control policy you deploy to each of the managed devices
governs what kinds of activity they detect and how it is prioritized. You can
also set notification options for certain types of intrusion events so that the
incident team does not need to sift through hundreds of events. You can specify
that you are notified automatically when certain high priority, high severity
events are detected.
Your incident handling process should specify how, after a
security incident is detected, an investigation is conducted. In some
organizations, junior members of the team triage all the incidents and handle
the less severe or lower priority cases themselves, while more senior members
of the team handle high severity and high priority incidents. You should
carefully outline the escalation process so that each team member understands
the criteria for raising an incident’s importance.
Part of the escalation process is tied to understanding how a
detected event can affect the security of your network assets. For example, an
attack against hosts running Microsoft SQL Server is not a high priority for
organizations that use a different database server. Similarly, the attack is
less important to you if you use SQL Server on your network, but you are
confident that all the servers are patched and are not vulnerable to the
attack. However, if someone has recently installed a copy of the vulnerable
version of the software (perhaps for testing purposes), you may have a greater
problem than a cursory investigation would suggest.
The Firepower System is particularly well suited to supporting
the investigation and qualification process. You can create your own event
classifications, and then apply them in a way that best describes the
vulnerabilities on your network. When traffic on your network triggers an
event, that event is automatically prioritized and qualified for you with
special indicators showing which attacks are directed against hosts that are
known to be vulnerable.
The incident tracking feature in the Firepower System also
includes a status indicator that you can change to show which incidents have
All incident handling processes should specify how an incident
is communicated between the incident handling team and both internal and
external audiences. For example, you should consider what kinds of incidents
require management intervention and at what level. Also, your process should
outline how and when you communicate with outside organizations. Consider the
Will some incidents require that you notify law enforcement
If your hosts are participating in a distributed denial of service
(DDoS) against a remote site, will you inform them?
Do you want to share information with organizations such as the
CERT Coordination Center (CERT/CC) or FIRST?
The Firepower System has features that you can use to gather
intrusion data in standard formats such as HTML, PDF, and CSV (comma-separated
values) so that you can easily share intrusion data with others.
For example, CERT/CC collects standard information about
security incidents on its web site. CERT/CC looks for the kinds of information
that you can easily extract from the Firepower System, such as:
information about the affected machines, including:
information about the sources of the attack, including:
a description of the incident, including:
methods of intrusion
the intruder tools involved
the software versions and patch levels
any intruder tool output
the details of vulnerabilities exploited
the source of the attack
any other relevant information
You can also use the comment section of an incident to record
when you communicate issues and with whom.
Your incident handling process should clearly indicate what
steps are taken when a host or other network component is compromised. The
range of containment and recovery options stretches from applying patches to
vulnerable hosts to shutting down the target and removing it from the network.
You should also consider the importance, depending upon the nature and severity
of the attack, of preserving evidence in case you pursue criminal charges.
You can use the incident feature of Firepower System to maintain
a record of the actions you take during the containment and recovery phase of
Each security incident, whether or not it is a successful
attack, is an opportunity to review your security policies. Do you need to
update your firewall rules? Do you need a more structured approach to patch
management? Are unauthorized wireless access points a new security issue? Each
lesson learned should feed back into your security policies and help you
prepare better for the next incident.