automation tools
ALERT AND ACTION
Companies can encounter problems when collecting more packet data, which requires them to sift through so
much more data following a breach. If the right tools aren’t in place and the right processes aren’t followed this
increased monitoring could be a real time and budget waster. Here, Tom Rowley of Savvius outlines what alert
automation tools should be considered, how they should be implemented and best practice in a breach situation.
B
usiness networks
have changed in three
important ways over the
past few years. First,
they’re faster than
ever. Second, they connect to more
devices (thank you, BYOD), and third,
a growing share of network traffic
consists of rich media such as VoIP
and video that is highly sensitive to
network delays.
As well as being faster, more
connected, and voice and video
centric, our networks have also
become more difficult to troubleshoot
and secure. Some of this is due to
the fact that they transport too much
data for traditional network monitoring
and troubleshooting tools to reliably
collect and analyse. Many analysis
tools end up relying on snippets
or samples of traffic and high level
statistics, but these lack the details
and hard evidence that IT engineers
need when troubleshooting problems
and characterising security attacks.
Given the near certainty that your
organisation will be breached, it’s
clear that modern best practices for
enterprise security need an overhaul.
As part of that change, they have to
include specific tools and expertise to
34
help them respond to an attack. While
an enterprise needs to build the best
defence it can, and constantly monitor
its network as closely as possible, it
also needs to be ready to immediately
launch an investigation when hints of
a breach become apparent.
Evidence of intrusion
The key to conducting a successful
investigation is to have historical
data at hand that can be examined
for clues to the attacker’s behavior.
No matter how good an attacker
is, the culprit will unavoidably leave
evidence of the intrusion. This
evidence will typically be found in
one of three places: in the memory
of the computers and servers on
the network, in the logs files that
record actions on each individual
computer, and in the traffic (packets)
that traversed the network. Some of
these forms of data are more useful
than others. Memory data can be very
useful if the attacker is still present
in your computers, but they are often
long gone and the memory erased.
Log data can provide very detailed
clues to the attacker’s behavior but,
unfortunately, it’s relatively easy to
erase or forge. As a result, modern
forensic investigators are increasingly
turning to network data as the prime
source of forensic clues. Network
traffic and packet data recordings
can’t be easily forged since they
are stored in real time, making then
difficult to modify. Lots of attacks
do involve manipulating network and
packet data but all of that attacker
behavior can be indelibly recorded
and later used to replay the assault.
The old adage that ‘packets don’t lie’
is not only true, it also gives forensic
investigators an important advantage.
In the ideal world, investigators
would have logs and network packets
at their disposal to reconstruct an
attacker’s behavior and assess the
damage caused. But the question
remains, how long does an enterprise
need to save log and network data?
Unfortunately, modern attackers can
be very good at disguising their entry
into an enterprise, and it may be an
extended period of time before the
breach is discovered. According to
the 2015 Trustwave Global Security
Report, the median time to detect an
attack was 86 days – nearly three full
months. Other studies have shown
an average time-to-detect of up to
270 days. And how long does it take