Download Under Threat or Compromise - Every Detail Counts

Interested in learning
more about security?
SANS Institute
InfoSec Reading Room
This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission.
Under Threat or Compromise - Every Detail Counts
This paper outlines five major components of a life-cycle approach to defense and how companies can adopt this
model to maximize security in the current threat landscape.
Copyright SANS Institute
Author Retains Full Rights
Under Threat or Compromise—
Every Detail Counts
A SANS Analyst Whitepaper
Written by Jake Williams
August 2014
Sponsored by
Blue Coat
©2014 SANS™ Institute
Introduction
Every company will be compromised sooner or later. No organization is immune. If
you think patching is a way to prevent compromise, consider privacy advocate Quinn
Norton’s recent statement: “When we tell you to apply updates we are not telling you to
mend your ship. We are telling you to keep bailing before the water gets to your neck.”1
In late 2013, the SANS endpoint security survey found almost half of all companies are
now operating under the presumption of compromise.2
Clearly, the security paradigm has shifted. No longer can the security model depend
entirely on keeping the attacker from breaching the perimeter. Instead, organizations
must adopt a full life-cycle approach to defense. In this paper, we outline five major
components of a life-cycle approach to defense (illustrated in Figure 1) and how
companies can adopt this model to maximize security in the current threat landscape.
Figure 1. A Life-Cycle Approach to Enterprise Defense
SANS ANALYST PROGRAM
1
“Everything Is Broken,” https://medium.com/message/81e5f33a24e1
2
“The Case for Endpoint Visibility,” www.sans.org/reading-room/whitepapers/analyst/case-endpoint-visibility-34650
1
Under Threat or Compromise—Every Detail Counts
Life-Cycle Defense
Let’s look at each component of this life-cycle defense model in more detail, starting
with protection, the key aim of every IT security organization. Protection and prevention
are nearly interchangeable, and both rely on some level of detective intelligence to fulfill
their objectives. That same intelligence should be usable for follow-up investigation to
determine impact all the way to the application, device or endpoint, and the user, so as
to close the vulnerability.
Some organizations fail to recognize the need for life-cycle defense and prefer to
operate in only a reactionary capacity. Security personnel who choose to instrument the
network and capture traffic for compromise analysis only after an attack has occurred
are much like the convenience store owner who installs a camera after a robbery. In both
cases, the owners wish precautionary measures had been deployed sooner, and in both
cases the security event was the catalyst for the monitoring improvements. Just as the
convenience store robber may never be caught because video evidence is not available,
the failure to instrument the network and capture traffic may prevent an organization
from ever determining the full damage from an intrusion. It is important to have key
tools in place, such as security analytics, malware scanning and analysis, access to
outside threat intelligence and other such protections. Preparation truly is vital.
Start with Protection
Almost every organization employs two basic defensive measures: endpoint antivirus
and perimeter firewalls. Endpoint antivirus solutions often employ host-based intrusion
detection systems (HIDS) to block unauthorized programs from communicating on
the network. They may also limit which programs can open listening ports and block
communications to blacklisted destinations.
Typically, perimeter firewalls perform both ingress and egress filtering, limiting the
ports and protocols that can communicate into and out of the network. Even when
communication is permitted using a given port or protocol, these communications
are often also limited by the source and/or destination IP addresses. The configuration
of these devices is anything but trivial. Configuration mistakes can and do happen,
particularly when change management guidelines are not strictly followed. This leaves
the organization with a false sense of security, thinking they have protection when they
really don’t.
Many organizations have begun deploying devices to record network traffic at the
perimeter, either at the flow level or at the packet layer. But many deployments lack
sufficient analytical capability to detect anomalies in network traffic. The need to capture
packet data is a given, but simply recording packets and storing them on a hard drive
does little good.
SANS ANALYST PROGRAM
2
Under Threat or Compromise—Every Detail Counts
Life-Cycle Defense
(CONTINUED)
Organizations often configure HIDS devices and perimeter firewalls with blind trust,
hoping they will operate as advertised and security teams can prevent mistakes in
configuration. But how can organizations verify that firewall protections are actually
working? One way is to analyze the network traffic that actually enters and leaves
the network through the firewall. Obviously this requires more than simply recording
packets. It requires advanced analytic functions, such as those that help identify firewall
misconfigurations.
Consider this example: After deploying a device to capture packet data at the perimeter
(ingress and egress), a security analyst discovered large amounts of traffic from the DMZ
on the internal network. This prompted an audit of the firewall rules separating the DMZ
from the internal network. The analyst discovered that a rule allowing all traffic was in
place on the firewall. This rule, which superseded the normal rules separating the DMZ
from the internal network, had been inserted months earlier to troubleshoot a businesscritical outage. However, administrators forgot to remove the rule when it was no longer
EX P E RT A dvice:
needed, and the organization was unprotected for months. Because the rule exposed
Critical preventive measures
the internal network to attack from the DMZ, attackers were successful in compromising
consist of using secure
several internal hosts. This configuration mistake, which was easily identified by
practices for hardening
systems, closing the loop
on vulnerabilities and
remediation, and monitoring
for misconfigurations or signs
of abuse.
examining network traffic, greatly increased the cost and scope of the investigation and
remediation.
This example provides good advice for protection of all applications and endpoints:
Critical preventative measures consist of using secure practices for hardening these
systems, closing the loop on vulnerabilities and remediation, and monitoring them for
misconfigurations or signs of abuse.
Plan with Detection
The need to capture network traffic at the packet level is well established. But just having
the data sitting on a hard drive does little to defend the network. Sure, the data is useful
when investigating a compromise, just as security cameras may provide additional
evidence in a robbery. However, the true value-add of network packet data is realized
when it is used to detect incidents.
Because of the high throughput of network data, analysis in real time is difficult. Much
deeper analysis and richer heuristics can be obtained by analyzing collected data in a
secure, sandbox-type environment. Detection at this level can be used to block against
unknown attacks with the right signs and indicators tripping the sandboxing features.
For example, encrypted communications between internal devices that normally don’t
talk to one another should trip a warning and pull those packets offline for deeper
inspection—including decryption—to make an alerting and/or blocking decision.
SANS ANALYST PROGRAM
3
Under Threat or Compromise—Every Detail Counts
Life-Cycle Defense
(CONTINUED)
Detection and false positives run hand in hand, which is why added intelligence beyond
packet destination and port, for example, should be gathered on suspect activity to
make determinations about whether to allow the traffic to pass, alert an administrator
or send a report. One way to investigate those false-positive events is to investigate the
raw packet data captured, but finding pertinent data in the raw packet data can be like
looking for a needle in a haystack.
Systems allowing the analyst to pinpoint relevant communications in a sea of data are
key to maximizing detection efficiency. Further, any network capture system should
support the summarization of traffic for metrics and capacity planning as well as the
detection of network anomalies. The reports should provide IT security professionals
with the means to detect actual attacks and take action as needed.
Another key to planning is implementing SSL decryption proxies at the network
boundary. Many organizations balk at the potential expense and privacy concerns
EX P E RT A dvice:
associated with implementing SSL decryption, but the problem is significant. Large
percentages of network traffic are encrypted, and stripping the encryption at the
Systems allowing the
network boundary for inspection, using an SSL proxy, can yield insights into events that
analyst to pinpoint relevant
would otherwise be missed completely. Most incident responders with the fortune to
communications in a sea of
have a network traffic analysis system can relate to the frustration of unraveling a lead
data are key to maximizing
only to be stopped cold when faced with an encrypted connection. Pre-positioning
detection efficiency.
decrypting proxies allows for greater depth and precision in investigations and should
be part of any modern network monitoring strategy.
Investigate and Analyze with Intelligence
Having the ability to detect anomalies in network data is good, but it falls short of
providing a full picture of what’s actually happening in the network. Suppose an
anomaly detection system finds multiple anomalous connections. Which anomalies
should security personnel investigate first? Integrating threat intelligence with network
data can aid in detection and help personnel prioritize alert handling. For example, if you
know that an alert is coming from a known malicious IP block (through integration with
reputation intelligence and blacklisting), the blocking action should be automatic, based
on policy set through the security management interface.
In turn, these systems should also integrate with an anomaly detection system. Such a
system can help the analyst automatically prioritize alerts based on known malicious IP
addresses, domains, domain registrants and net blocks.
SANS ANALYST PROGRAM
4
Under Threat or Compromise—Every Detail Counts
Life-Cycle Defense
(CONTINUED)
Another consideration is the need to detect unusual protocols. But unusual is a relative
term. What might be seen as unusual in one network may be normal in another. The
anomaly detection system, therefore, must have the ability to be trained based on the
EX P E RT A dvice:
current network traffic.
Analysts need tools that
For instance, Session Initiation Protocol (SIP) traffic is expected in a network that uses
provide context to what they
Voice over Internet Protocol (VoIP) for communications, but it may not be expected in a
are seeing. It’s critical to be
able to reconstruct sessions at
the protocol level.
network that uses regular phone lines. SSH traffic inbound to a Windows server farm is
similarly unusual. In the firewall misconfiguration example offered earlier, NetBIOS traffic
from the DMZ was one of the first things the analyst noticed. The traffic itself wasn’t
anomalous; it was a cause for concern only in the location where the analyst found it.
Finding the proverbial needle in the haystack is easier said than done. Analysts need
tools that provide context to what they are seeing. It is critical for them to be able to
reconstruct sessions at the protocol level.
Contain and Mitigate
During intrusions, organizations too often guess at their exposure rather than determine
it conclusively. Organizations that lack visibility into communications at the network
boundary cannot verify when—or whether—containment and mitigation efforts are
successful.
One of the first tasks when performing containment is to determine the scope of
the intrusion. Was the intrusion contained to a single subnet or network segment?
How many endpoints exfiltrated data? More important questions are included in the
E XP E RT A dvice:
“Questions to Ask If You’ve Been Breached” section later in this paper.
Be sure to size packet capture
Leadership typically wants to know specifically what data was exposed and exfiltrated
systems appropriately to
from the network. This can be a challenge, especially when attackers protect their
handle your system load.
communications using encryption. Without the encryption key and algorithm used,
even stored network data can’t reveal what was stolen … or can it?
Malware reverse engineers frequently recover the encryption keys used for malware
command and control (C2) and exfiltration data. When they do this, they depend on
having the network data available to provide value to the organization. This is where
precision capture matters. If the capture is sloppy, with dropped packet data (often
due to high volume and inadequately scoped deployments), the organization may not
be able to decrypt the data. To come so close only to be thwarted by dropped packets
at the time of capture is a real morale killer. So, be sure to size packet capture systems
appropriately to handle your system load.
SANS ANALYST PROGRAM
5
Under Threat or Compromise—Every Detail Counts
Life-Cycle Defense
(CONTINUED)
When analysts are able to decrypt malware communications, they can often see the
commands the attackers sent. This may lead investigators to other compromised
machines or machines the attackers were scanning for vulnerabilities. Understanding
the attackers’ actions and intent helps defenders build successful containment
and mitigation strategies. Once the scope has been conclusively determined, true
containment and mitigation efforts can begin.
When attackers use more common encryption techniques, such as HTTPS, to exfiltrate
data, the job of decryption is even easier. By coupling an HTTPS proxy at the network
perimeter with network traffic capture, analysts obtain a complete picture of exfiltration
data that would otherwise be unavailable.
Many organizations depend on host-based scanning tools to identify indicators
of compromise and find infected hosts. While this method certainly has its merits,
EX P E RT A dvice:
Attackers must use network
communications to infect and
spread. By analyzing packet
they should look at their network traffic just as closely: Attackers must use network
communications to infect and spread. By analyzing packet data, analysts can identify the
actual hosts targeted and infected by the attacker. For example, a machine that makes
many hundreds of failed DNS requests to domain names that appear random is probably
infected with malware. Similarly, a machine that attempts to make connections to every
data, analysts can identify
machine in the network on TCP port 80 is probably conducting a port scan and is likely
the actual hosts targeted and
infected as well.
infected by the attacker.
Changing firewall rulesets is also a very common containment and mitigation strategy.
While this is a good start, sometimes the proposed rule changes are overly broad and
can have an impact on benign production network traffic—a side effect most security
teams want to avoid.
So, how can you be sure a proposed change won’t affect production traffic? Analyzing
network data is the answer. Through analysis you’ll know whether a change would affect
existing business functions before the change is made. This ability comes from knowing
the scope of the intrusion as opposed to guessing about it.
Blocking active connections using firewall rules may temporarily thwart attackers by
cutting off access to their malware. But if the attackers aren’t completely removed from
the network, they may be able to regain access to infected machines through a different
access vector, effectively picking up where they left off. That’s why it’s vital to remediate
the vulnerability the attackers used to access the network.
SANS ANALYST PROGRAM
6
Under Threat or Compromise—Every Detail Counts
Life-Cycle Defense
(CONTINUED)
Remediate the Vulnerability
Remediation is hard—so hard, in fact, that organizations often fail to completely remove
the attacker from the network the first time they try. A prime example of this failure
involves the infamous Heartbleed bug. Despite the publicity surrounding this most
critical of vulnerabilities, months after its discovery more than 300,000 public-facing
servers remain vulnerable.3
EX P E RT A dvice:
By using network packet
data, defenders can be sure of
detecting the attackers if they
activate dormant backdoors.
This lack of SSL updating represents a major infrastructure issue that affects the
consumer’s ability to trust a website. Still, many of these certificates have not been
repaired, highlighting just how difficult it is for organizations to keep their systems
clean of vulnerabilities. However, vulnerability discovery, management and patching are
among the top preventive controls that organizations have at their disposal, according
to the Critical Security Controls and other guidance documents.4
Just because you’ve reimaged all the hosts the attackers were observed communicating
to does not mean the attackers are gone. They may be lying dormant in other areas of the
network.5 However, by using network packet data, defenders can be sure of detecting the
attackers if they activate dormant backdoors. That’s because these backdoors often use the
same protocols or command and control servers as the previously detected backdoors.
The following scenario is a common one. An organization patched its corporate web
server the first day the Heartbleed vulnerability was announced. However, it failed to
patch several auxiliary web servers used for partner communications; and, perhaps more
troubling, it failed to patch the VPN concentrator. The security team discovered these
patching failures through active scanning, but they could have also been discovered
through passive analysis of network traffic data.
E XP E RT A dvice:
By examining network
traffic, the organization can
determine precisely whether
hashes were stolen and make
a knowledgeable decision
about the need to change
passwords.
SANS ANALYST PROGRAM
Only network traffic analysis could confirm whether the hosts were merely vulnerable
or whether they had actually been exploited. By analyzing network traffic for SSLhandshakes, the organization could have generated the list of candidate servers to
patch. Armed with that information, it should have followed up with vulnerability scans
and analysis of network packet data to ensure that remediation had been successful.
Another common remediation example is changing passwords. After they compromise
a network, attackers are very likely to dump password hashes for use in offline cracking.
Best practices dictate that, when in doubt, defenders should change passwords across
the domain. If this step is not taken, attackers can use these passwords to regain a
foothold inside the network.
However, changing passwords is a costly proposition that results in substantial losses
in productivity. By examining network traffic, the organization can determine precisely
whether hashes were stolen and make a knowledgeable decision about the need to
change passwords.
3
“Heartbleed: Over 300,000 servers still exposed,” www.zdnet.com/heartbleed-over-300000-servers-still-exposed-7000030813
4
“Critical Security Controls,” www.counciloncybersecurity.org/critical-controls
5
“ Five Actions to Take Immediately After a Cyberattack,”
http://insights.wired.com/profiles/blogs/five-actions-you-must-take-immediately-after-a-cyber-attack#axzz35U1f8JW4
7
Under Threat or Compromise—Every Detail Counts
Questions to Ask If You’ve Been Breached
Modern security analytics go far beyond looking at attack patterns. They are responsible
for indexing, classifying, analyzing, reporting, alerting, augmenting with outside threat
data and escalating to malware analysis tools. Regardless of how robust an
organization’s defenses are, an intrusion is likely to happen. When it does, security
Five Questions to Ask When
You’ve Been Compromised
teams need to answer five key questions (and the sooner, the better).
1. Which systems and data were affected?
Simply capturing sample packet data isn’t enough; you must be able to capture
2. How did they do it?
and analyze packets at wire speed. With more and more networks operating at
3 . Who did this to us?
high speeds, requirements of 2Gbps to 5Gbps are relatively common, with speeds
4. Is it really over?
of 10Gbps not unheard of. Then, data that is suspect must be moved out of line for
5. Can it happen again?
deeper inspection. All this must be automated and conducted at speeds that do
not interfere with business operations and productivity.
Which Systems and Data Were Affected?
Answering the question of which systems were affected can be as easy as looking for C2
and exfiltration traffic between internal systems and the attacker’s servers. If attackers
EX P E RT A dvice:
Monitoring and inspecting
aggregate C2 and exfiltration data out through a few hosts, then simply looking for
command and control servers may not find all compromised hosts. Traffic analysis can
help, but detecting traffic generated by compromised hosts or traveling to compromised
traffic between hosts is
hosts is only a start. Some packet capture and analysis systems are deployed at the
important, given that C2
network perimeter and do not record communications between internal hosts.
servers can be moved around
Monitoring and inspecting traffic between hosts is also important, given that C2 servers
inside an organization to avoid
detection.
can be moved around inside an organization to avoid detection.
After a vulnerability is made public, analyzing previously captured network traffic can
also be used to determine which machines were previously exploited and are under
the control of an attacker. Researchers recently revealed that this activity is being
undertaken by nation-states.6 If this technique works at international scale, it can
certainly work for your organization.
6
SANS ANALYST PROGRAM
“ Some People Want A Time Limit On The NSA’s ‘Zero-Day’ Exploits — Here’s Why That’s A Terrible Idea,”
www.businessinsider.com/why-a-time-limit-on-zero-days-is-a-bad-idea-2014-7
8
Under Threat or Compromise—Every Detail Counts
Questions to Ask If You’ve Been Breached
(CONTINUED)
How Did They Do It?
The question of how an attack was perpetrated is always significant. Consider a
vulnerability such as Heartbleed. Suppose your servers were exposed to the Internet,
unpatched, for a few days after Heartbleed was announced. Were they attacked? Do you
know? Heartbleed didn’t trip IDS signatures or leave application logs.
The only way to know whether you suffered an attack is by using network capture
data. By looking inside the decrypted traffic, analysts can identify whether their
systems were attacked with the Heartbleed exploit and, more importantly, whether the
server’s encryption keys (or other private data) were revealed. Finding this data in the
sea of traffic is probably easier than it sounds. Exploits frequently make a lot of noise
before they are successful—one researcher required more than 100,000 requests to
compromise a server’s private key.7
The Heartbleed exploit is a key case where analyzing with intelligence is critical. It will
involve several distinctions; for example:
• You need a system that can locate network traffic flows that use SSL.
• Ideally, the system should allow analysts to craft new analytics without having to
wait for the developers to update protections. After all, no one cared about the
DTLS Heartbeat field length (exploited by Heartbleed) until the vulnerability came
to light.
• Analysts who wish to analyze this traffic would have to create custom decoders for
the packet data, which is a feasible option only if their tools support it.
Take, for example, the CVE 2014-1776, which was a zero-day exploit used in targeted
attacks. The exploit used vector markup language (VML) to abuse Internet Explorer’s
mishandling of memory allocations. Because VML is not widely used, a common
remediation suggestion was to disable VML at each endpoint in the network until
patches were available.8
But would disabling VML break critical business processes? Analyzing network data can
tell which (if any) hosts are using VML. Then, analysts can inspect the communications,
look into the packets and determine whether they contain any of the exploit code.
SANS ANALYST PROGRAM
7
“ Answering the Critical Question: Can You Get Private SSL Keys Using Heartbleed?”
http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed
8
“Microsoft Security Bulletin MS14-021 – Critical,” https://technet.microsoft.com/en-us/library/security/ms14-021.aspx
9
Under Threat or Compromise—Every Detail Counts
Questions to Ask If You’ve Been Breached
Who Did This to Us?
Employees Versus External Attackers:
A Lesson in Motivation
Full network packet capture can be used to help differentiate an insider
attack from an external attack. Either type of attack is likely to exfiltrate
In this scenario, we use network data capture to
determine whether the attacker is an insider or an
outsider who has compromised passwords to use now
and return later to continue the exploit.
data over the network, but in the case of an insider attack, analysts
would not observe any exploit traffic without employing full network
Organizations need to provide remote access to their
employees. But how do they distinguish legitimate VPN
connections from malicious ones? The answer may lie in
the activity that happens after the connection: Attackers
are often interested in exfiltrating large amounts of data,
whereas employees might access an intranet web portal
to perform some task and then disconnect.
By examining patterns of usage, made possible with
network traffic capture, analysts can be alerted to
anomalous behavior and can use the captured data to
drill down and see the data being sent out and other
activities being performed under a compromised user
credential.
(CONTINUED)
packet capture. On the other hand, an external attacker is likely to send
exploit traffic before exfiltrating data, so both inbound and outbound
traffic, as well as traffic between sensitive internal systems, should be
monitored.
Network capture should also include VPN traffic and other access from
external business partners. In the infamous Target breach, the initial
source of compromise was an external contractor with access to Target’s
networks.9 All ingress and egress traffic to the Internet was covered.
So, did the compromise come from inside or was it a business partner?
Which one? Sensor placement matters when it comes to capturing
network data. Figure 2 illustrates desirable locations for network traffic
capture that are often ignored when choosing where to monitor.
Figure 2. Network Monitoring Locations
9
SANS ANALYST PROGRAM
“Target Hackers Broke in Via HVAC Company,” http://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company
10
Under Threat or Compromise—Every Detail Counts
Questions to Ask If You’ve Been Breached
(CONTINUED)
The ability to reconstruct network sessions is absolutely critical. Imagine the case of a
credential-harvesting spearphishing attempt. It is important to be able to answer two
questions: How many users clicked on the link to visit the site? Of those users, how many
submitted their credentials to the site? Network data can provide the answers.
Malware authors often reuse code in their creations. This includes reuse of usernames,
passwords, HTTP User Agents and other network-based artifacts. Once one of these
artifacts is discovered, analysts can identify other network traffic that shares the same
characteristics. Here too, protocol-level dissection is critical to establish the needed level
of granularity.
Properly scoping an attack can have huge financial impacts on the organization.
Consider, for example, a credit card breach. Host logs show that the attackers definitely
had access to the database containing cardholder data. However, based on host logging,
it is unclear what they actually accessed in the short time before they were eradicated
from the network. The attackers’ backdoor program used encryption, and network
traffic was sent to the attackers. But what was stolen? Do you need to notify (and reissue
cards) to a million customers, a thousand customers or none? Without network traffic
data, it is impossible to answer the questions. With the network data and a good reverse
engineering team, the answer is within reach.
Is It Really Over?
When they first detect attackers, defenders often rush to eradicate the offenders from
the network. This sounds like the correct approach, but attackers may change tools
and tactics and continue their attack if they are not completely eradicated. This is what
happened when Chinese attackers hit The New York Times10 using new tools after being
discovered by security researchers.11
When the compromise is first detected, defenders often remove the obvious infection
in lieu of taking the wipe and reimage approach to remediation. But secondary
backdoors on a compromised machine are devilishly difficult to locate. By instituting
extra monitoring, defenders can identify resumed attacker communications with the
machine—a clear indication that remediation has failed.
SANS ANALYST PROGRAM
10
“ New York Times attackers update tools and change tactics,”
www.computing.co.uk/ctg/news/2288203/new-york-times-attackers-update-tools-and-change-tactics
11
“ Chinese Army Unit Is Seen as Tied to Hacking Against U.S.”
www.nytimes.com/2013/02/19/technology/chinas-army-is-seen-as-tied-to-hacking-against-us.html
11
Under Threat or Compromise—Every Detail Counts
Questions to Ask If You’ve Been Breached
(CONTINUED)
Can It Happen Again?
The short answer is, “Of course it can.” Just blocking access to untrusted domains neuters
a huge percentage of spearphishing attacks. Even large enterprises communicate with
a surprisingly small subset of the Internet on a regular basis. But trying to determine
trustworthiness on your own, without access to reputation data, is a real challenge. Best
practices dictate that reputation data be obtained from a reputable provider ingesting
data from all over the globe.
The vulnerability used to compromise the network originally was likely patched in
the remediation phase. But was the patch enough? Because attackers have already
compromised machines, they know more about the environment and may be able to
exploit vulnerabilities they would never have discovered through remote scanning.
What if patches can’t be applied due to software constraints, such as a Java dependency
with custom or third-party software? These situations call for enhanced monitoring to
determine whether attackers are attempting to regain their control of the organization’s
systems. The best method for this enhanced monitoring, particularly at scale, is through
network traffic analysis.
Understanding normal network behaviors, traffic patterns and actions, and being able to
detect what is not normal, are critical to determining whether attackers have returned to
the network. A great example of anomaly detection (discussed earlier) is CVE 2014-1776.
In the weeks following the announcement of that vulnerability, many organizations saw
an increase in VML traffic. For organizations where VML is never used, this was a clear
sign the attack was spreading, even as organizations tried to contain and mitigate the
vulnerabilities.
SANS ANALYST PROGRAM
12
Under Threat or Compromise—Every Detail Counts
Conclusion
Despite the best efforts of security personnel, compromises do occur. And when they
do, it is essential that analysts be able to provide the answer to five important questions
detailing what was compromised, how it was compromised, who did it, whether it is
truly over and whether it can happen again.
Adopting a life-cycle approach to network defense is a good starting point from which
to build defenses. Protection, detection, investigation and analysis, containment and
mitigation, and remediation are keys to a healthy security environment. Ideally, many
of these technologies and processes would flow together, wrapped in a life-cycle
management and workflow remediation process to reduce risk and attack surfaces while
promoting faster response and reducing false positives.
Full network traffic capture is an important capability for intelligent analysis and
response. By combining network traffic capture with proxies at the perimeter,
particularly those that decrypt SSL data, organizations can obtain answers to key
questions about the compromise and support the detection, response and remediation
stages of the life cycle.
SANS ANALYST PROGRAM
13
Under Threat or Compromise—Every Detail Counts
About the Author
Jake Williams is founder and principal consultant at Rendition Infosec and a certified SANS instructor
and course author. He has more than a decade of experience in secure network design, penetration
testing, incident response, forensics and malware reverse engineering. Before founding Rendition
Infosec, he worked with various government agencies in information security roles. Jake is a two-time
victor at the annual DC3 Digital Forensics Challenge.
Sponsor
SANS would like to thank this paper’s sponsor:
SANS ANALYST PROGRAM
14
Under Threat or Compromise—Every Detail Counts
Last Updated: June 15th, 2017
Upcoming SANS Training
Click Here for a full list of all Upcoming SANS Events by Location
DFIR Summit & Training 2017
Austin, TXUS
Jun 22, 2017 - Jun 29, 2017
Live Event
SANS Paris 2017
Paris, FR
Jun 26, 2017 - Jul 01, 2017
Live Event
SANS Cyber Defence Canberra 2017
Canberra, AU
Jun 26, 2017 - Jul 08, 2017
Live Event
SANS Columbia, MD 2017
Columbia, MDUS
Jun 26, 2017 - Jul 01, 2017
Live Event
SEC564:Red Team Ops
San Diego, CAUS
Jun 29, 2017 - Jun 30, 2017
Live Event
SANS London July 2017
London, GB
Jul 03, 2017 - Jul 08, 2017
Live Event
Cyber Defence Japan 2017
Tokyo, JP
Jul 05, 2017 - Jul 15, 2017
Live Event
SANS Los Angeles - Long Beach 2017
Long Beach, CAUS
Jul 10, 2017 - Jul 15, 2017
Live Event
SANS Cyber Defence Singapore 2017
Singapore, SG
Jul 10, 2017 - Jul 15, 2017
Live Event
SANS ICS & Energy-Houston 2017
Houston, TXUS
Jul 10, 2017 - Jul 15, 2017
Live Event
SANS Munich Summer 2017
Munich, DE
Jul 10, 2017 - Jul 15, 2017
Live Event
SANSFIRE 2017
Washington, DCUS
Jul 22, 2017 - Jul 29, 2017
Live Event
Security Awareness Summit & Training 2017
Nashville, TNUS
Jul 31, 2017 - Aug 09, 2017
Live Event
SANS San Antonio 2017
San Antonio, TXUS
Aug 06, 2017 - Aug 11, 2017
Live Event
SANS Hyderabad 2017
Hyderabad, IN
Aug 07, 2017 - Aug 12, 2017
Live Event
SANS Prague 2017
Prague, CZ
Aug 07, 2017 - Aug 12, 2017
Live Event
SANS Boston 2017
Boston, MAUS
Aug 07, 2017 - Aug 12, 2017
Live Event
SANS New York City 2017
New York City, NYUS
Aug 14, 2017 - Aug 19, 2017
Live Event
SANS Salt Lake City 2017
Salt Lake City, UTUS
Aug 14, 2017 - Aug 19, 2017
Live Event
SANS Adelaide 2017
Adelaide, AU
Aug 21, 2017 - Aug 26, 2017
Live Event
SANS Virginia Beach 2017
Virginia Beach, VAUS
Aug 21, 2017 - Sep 01, 2017
Live Event
SANS Chicago 2017
Chicago, ILUS
Aug 21, 2017 - Aug 26, 2017
Live Event
SANS Tampa - Clearwater 2017
Clearwater, FLUS
Sep 05, 2017 - Sep 10, 2017
Live Event
SANS San Francisco Fall 2017
San Francisco, CAUS
Sep 05, 2017 - Sep 10, 2017
Live Event
SANS Network Security 2017
Las Vegas, NVUS
Sep 10, 2017 - Sep 17, 2017
Live Event
SANS Dublin 2017
Dublin, IE
Sep 11, 2017 - Sep 16, 2017
Live Event
SANS Minneapolis 2017
OnlineMNUS
Jun 19, 2017 - Jun 24, 2017
Live Event
SANS OnDemand
Books & MP3s OnlyUS
Anytime
Self Paced