Today, many state-of-the-art security solutions are
responding to the increase in cyberattacks via post-execution
malware analysis that includes continuous endpoint
monitoring and rapid reactive response to attacks. Although
it may seem like the need of the hour, we need to understand
the implications of this new thrust and examine how we can
best improve security.
Preparing for the Worst?
Malware execution on an endpoint has inherent risks. A
compromise reaches the post-execution stage only after
the failure of every preventive solution. The hope of this type
of malware analysis is that its actions will give away the
malicious behavior or that the affected enterprise will be able
to use this new monitoring layer to recover from an attack.
Post-execution monitoring analyzes and logs application
behavior, and in many cases also analyzes and stores most
of the network traffic. This is all done to detect and eventually
recover from the inevitable worst-case compromise scenario.
Coming back to the dilemma of malware execution and
analysis on an endpoint, we must answer the question:
What should these solutions monitor? What to monitor is an
important issue. If a solution is logging most of the network,
operating system and application behavior data in anticipation
of the worst, it is collecting massive amounts of data.
Post-execution solutions are noisy. With limited autonomy,
they simply can’t risk missing something important, so they
seek to collect and analyze an avalanche of data. This includes
disk writes (and parent proc), execution events, some subset
of reg, RPC communications, user activities (including URLs
visited, cookies written), DNS requests, and network trace
data like pcap or NetFlow for every operation.
The amount of data quickly adds up. Let’s say these systems
collect 1 megabyte per hour per host (or 1,000 1-kilobyte
records after compression). If you multiply that by 24 hours
for 1,000 hosts, you have 24 million events, or 24 gigabytes
of data a day. After 90 days you amass 2.1 billion records, or
2.1 terabytes of data. Imagine how much data an enterprise
with 50,000 to 100,000 hosts might collect.
Even with this heavy-handed approach to data siphoning,
defenders may never be able to find the needle in the haystack.
This burdensome approach is extremely complex and wastes
power, memory, disk space, and network resources. Let’s look
at some of the hidden costs for an enterprise if a security
solution purely uses the detect and respond approach after
malware has executed.
Management Cost
Gathering and maintaining the volume of information needed
to operate a detect and respond solution is a commitment
that grows with time, as does the cost of extracting value
from the information. Enterprises should be aware of the
following hidden costs and concerns:
Security Event Analysis
More security events lead to more analysis and increased costs.
Endpoint System Performance
Continuous endpoint monitoring leads to performance
bottlenecks, while unnecessary data collection further strains
the endpoint.
Cloud Lookups/Network Bandwidth
Although the security vendor is paying for cloud storage, it is
the enterprise that is paying for network data usage.
On-Premises Analysis
Hosting and managing a big data solution on-premise to deal
with the volume of data adds complexity, as well as hard and
soft costs.
Privacy Concerns
Solutions that collect and store most of the system events
for detection and response may end up collecting more
information than is necessary or desired. Access controls,
locality, retention periods, and encryption policies on the
collected data may vary by vendor.
Some security solutions rely on open-source data to get
information about suspicious files. These sources often do
not turn up useful data since pre-execution malware detection
has become a lost art and security vendors are not investing
sufficiently in improving file detection capabilities.
For example, if the Dyre family of malware is detected on
June 1st, a post-execution system querying any vendor on
June 4th will not recognize the sample as malware, based
on the industry’s collective knowledge at the time. There are
many examples of malware that is not initially identified as
malicious and fails to get reported as bad for weeks, months,
or even years. Such delays highlight the need for systems
to fill the gap in malware identification without relying on
reactive file-detection scanners.
Prevention vs Detect and Respond
3
What You See Is What You Get
Permitting malware execution creates major technical
challenges by expanding the playing field for malware instead
of limiting its options. Here are some examples of weaknesses
in newer technologies that are based on detect and respond.
Good Behavior / Bad Behavior
During malware post-execution analysis, endpoint security
solutions need to monitor the suspect in its natural
environment to detect, log, and block events in order to
recover from attacks. However, even under monitoring, it
is very hard to predict when a malware specimen such as
Rombertik may reveal its ugly side. It may be days before it
executes its malicious code or it could be dependent on some
user action (like scrolling a document to the second page) to
trigger the malware. Lots of new research has tried to solve
some of these problems, only to be circumvented yet again.
An alternative would be to watch all applications all the time
in the anticipation of a security event, which leads us back to
the security management cost discussion.
How Late is Too Late?
Can a monitoring technology detect the first bad event? Is
installing a driver a malicious event by itself? Most often the
answer is no, but the moment a malicious kernel driver runs,
it’s probably too late to save the system. These are just some
of the disadvantages of post-execution monitoring. More
often than not, a series of behaviors constitutes a malicious
behavior. However, it may be too late to block the malware if
that determination is not made in time and, more importantly,
every time. This yet again presents the old signature detection,
cat-and-mouse game, where defenders try to detect as early
as possible and attackers try to evade by mixing good and bad
events and sometimes gray events.
Examples of irreversible damage a piece of malware can cause
if not blocked in time, every time, include:
Parasitic Infection
By letting a parasitic infector run and infect critical files, the
cost to recover and restore the system increases drastically.
The file may become permanently damaged, requiring the
system to be rebuilt or restored from backup.
Data Destruction
We have recently seen two major attacks that could have
not been prevented by defenders solely relying on a postexecution detect and respond approach. The Saudi Aramco
and Sony Pictures attacks both used a signed commercial
kernel driver to wipe and destroy the targeted machines.
Another simple example is running ransomware like
CryptoWall/Cr
Please complete the form to gain access to this content
