Breach Found. Did It Hurt?

ANALYST BRIEF Breach Found. Did It Hurt? INCIDENT RESPONSE PART 2: A PROCESS FOR ASSESSING LOSS Authors Christopher Morales, Jason Pappalexis Overview Malware infections impact every organization. Many times an infection is benign, but where it is not, the damage inflicted can have considerable impact and severe economic consequences. Without a comprehensive process, a breach, or malware attack that exfiltrates data, is difficult to detect, understand, and mitigate against. Once a successful attack has been confirmed, breach analysis provides incident response (IR) teams with relevant forensic information in an actionable timeframe. Forensic information may include the attacker s identity, the motivation for the attack, the extent of infection, and most importantly, it will alert the IR team as to whether intellectual property was stolen. With this information, organizations can respond to the incursion with the appropriate level of urgency and scope. Without a process that clearly identifies the extent and intent of a breach, enterprises are exposed to a host of potentially disastrous financial and legal implications and risk. A properly implemented breach analysis process starts with the least invasive toolset (network monitoring and breach detection systems) and ends with the most complex (file access monitoring). Often, the initial toolsets are the least accurate but can accelerate the forensic process by identifying initial indicators of compromise (IOC). The second in a two- part series on IR, this analyst brief discusses the need for differentiation between malware detection and breach detection.

NSS Labs Findings Malware can exist in an enterprise for months without being detected. A successful attack may not attempt to exfiltrate data immediately. Any definition of breach should include data exfiltration. Current enterprise security processes typically do not address breach identification. Most security tools do not provide the information needed for breach identification. NSS Labs Recommendations Implement a breach analysis process to monitor for infected systems and identify inappropriate movement of internal data (a potential precursor to exfiltration). Move beyond existing perimeter security devices as the sole indicators for data breach. Identify gaps in current detection and monitoring capabilities as they pertain to data exfiltration, and develop a plan to eliminate these gaps. Preserve valuable attacker forensics by investigating infected machines before they are re- imaged. 2

Analysis Malware detection products often lag behind the technical capabilities of today s attacker. Frequently, malware is installed and remains undetected for days, weeks, and even months. Even more surprising, it is common for many organizations to remain committed to using endpoint protection products (EPP) alone for malware identification rather than recursively monitoring their networks for the most important indicators of successful but hidden attack: data exfiltration. The Goals of Breach Analysis In the case of a breach, an enterprise must quickly establish the answers to several critical questions. Most enterprises currently lack this ability. A methodology capable of monitoring and identifying the breach life cycle permits an enterprise to answer specific questions on the nature and extent of a threat: Has malware established communication across the perimeter? Was the attack able to establish communication to a foreign host, and did data loss occur? Where else did the malware go, and how did it propagate? How many hosts were infected? Which ports were utilized? What malicious processes have been installed on the infected system? Do the processes mimic critical system dynamic link libraries (dll) to avoid detection, or are they new processes? What are the attributes of these processes? Do the processes make system calls, rewrite files, or attempt to make specific file access? What data was accessed? How important was that data to the enterprise? Why did the attack happen? For example, for trade secrets, for money, or was it simple mischief? Who is the attacker? For example, a foreign government, a hacking group, or script kiddies. Organizations should evaluate their current workflows to identify which of these questions they are able to answer and to assess their average response time. The final three questions are the most challenging, but they also provide the most critical information. The Anatomy of Data Loss Although there are diverse categories of malware, breaches share a common path from infection to data exfiltration, and organizations can leverage this predictability during detection. AZacker ConnecYon Success Firewall PropagaYon System System System To remote web- based system Malicious Process Malicious AZribute Data Access Figure 1 Common Data Exfiltration Workflow 3

Breaches that intend to extract information often incorporate a remote, web- based system as a data repository. Figure 1 depicts a scenario where the attacker successfully connects to internal systems and then drops malicious code/processes in order to access proprietary data. While it is important, the perimeter firewall is not the only area where organizations should focus detection and prevention efforts. Breach Analysis Process Breach analysis allows enterprises to respond decisively to malware infections and better understand the implications of a successful breach. The breach analysis process begins with the simplest, most general technique, external network monitoring, (top of Figure 2) and concludes with forensics, the most accurate technique, but also the most complex and time- consuming (bottom of Figure 2). While it is feasible to initiate a lower- level technique independently of the earlier steps, this will increase overall complexity. For example, use of scheduled host memory scans (host analysis) as early indicators of compromise provides alerts on infected systems but also adds latency and requires additional manpower (the positive hits on scans of every system must be reviewed). Conversely, higher- level techniques are simpler but do not yield as much information. By working through the full breach analysis process (figure 2), enterprises are able to gather relevant data and manage breaches efficiently. External Network Monitoring Breach DetecYon Host Analysis Forensics External Network Monitoring Network Analysis File Access AudiYng External network monitoring reveals an attacker s identity and the potential motivation for the attack. Typically provided as a service, this monitoring alerts on malicious outbound connections by using information obtained from the Figure 2 Breach Analysis Process monitoring of known criminal organization groups, botnets, malicious sites, and malware. This information is also used to provide insight into the responsible parties, their motivations, and their tools. With this data, an enterprise can identify malicious traffic emanating from its domain and thus determine the number of machines that have become infected and are controlled by the attackers. Enterprises must evaluate the way in which particular services classify sites as malicious and must determine the techniques by which these services monitor and collect information on attackers. Breach Detection Systems (BDS) A BDS is the next generation of malware detection. In addition to identifying malware, it also detects the outbound communication of botnets at the network perimeter. Combined with external network monitoring, breach detection provides an initial indicator of compromise. A BDS identifies if a connection is successful, employing several common techniques to accomplish this (for example, signatures, sandboxing, network anomalies, and IP reputation lists). The data provided reveals the immediate scope of the infection, its trajectory, and the identity of the parent malware. 4

When combined with external network monitoring, information about the attackers and their tools can be correlated to understand the intent of the botnet. A BDS could also utilize network behavior analysis to inspect all network protocols and sessions for suspicious activity or for files that use a combination of abnormal network behavior characteristics. Network Analysis While BDS provide an initial indicator of compromise, internal network analysis tools give direct insight into the behavior and communication of traffic within the corporate infrastructure. networks are monitored to expose infected systems and determine the techniques used to propagate malware. network analysis tools also provide context around more universal behaviors on the network that could have led to the infection. Some network tools focus on collecting only the offending traffic while other tools are augmented to collect all of the traffic on the network in order to provide more advanced analysis. Although the tools themselves do not protect against infections, and although a certain level of expertise is necessary to be effective, a combination of the two approaches yields a broader picture of any malicious activity and provides better insight into the activity that could have led to the infection. Simple techniques for internal network analysis include logging and monitoring of endpoint events and NetFlow and/or sflow traffic. In many instances, this data can provide enough information to enable further forensics and consequently an understanding of the hosts behavior. Correlating this data into a security information event manager (SIEM) further simplifies pattern identification. Host Analysis Host analysis identifies the presence of malicious processes on a system and determines the attributes of these processes. Host analysis also notifies the organization of the malware s intent. While some of this information can be obtained with a BDS using packet capture abilities, a BDS does not supply the level of detail required to investigate a complete system. Three options are available for comprehensive host analysis: monitoring of the network stack (the simplest option but with the lowest level of granularity), file system analysis, and system memory analysis (the most difficult option but the most granular). Network stack Monitoring of the host network stack, much like internal network analysis, provides visibility into the internal communication within systems, which in turn permits identification of malware propagation within a specific system or set of systems. Techniques include monitoring of real- time systems for suspicious processes; analysis of inbound/outbound network traffic for suspicious or unauthorized connections to other machines or external addresses; detection of unauthorized encrypted traffic; identity- based file encryption; and the inclusion of reputation lists that are updated by threat feeds. File system File system analysis provides an understanding of file access, manipulation, and execution. Techniques currently in use include code signature validation of the digital stamp that is applied on files once they are released by software vendors; monitoring of known executables; sandbox techniques for detection of known malicious conditions; and monitoring system attributes in order to detect any changes. System memory Memory analysis is considered to be an all- inclusive form of analysis of a system and is often viewed as the most effective method for detecting malware on a system. For example, network monitoring is limited to detecting malware while in motion, and file system monitoring is limited to the host operating system. File analysis in particular is unaware of rootkits that function outside the scope of the host 5

operating system where the file monitoring occurs. Memory analysis, however, provides this visibility since all code must execute in memory regardless of where it is stored. Unfortunately, the limitation of memory analysis is its inability to perform real- time monitoring; it is not trivial to inspect memory on a running system unless a memory dump is performed. During the shift from file analysis to memory analysis, internal teams are able to determine what is active on a system, agnostic of the operating system and file system structure. This includes identifying the permissions available to the malicious code; discovering which systems the code is attempting to connect with; and ultimately determining the scope of data available for the code to access. File Access Auditing/Legal Forensics The final step in the breach analysis process is perhaps the most important. If information has been stolen, a compromise has occurred, and depending on relevant legal requirements, public notification and legal forensics are necessary. This is a costly situation an enterprise will wish to avoid. Legal forensics procedures should not be required in the breach analysis process unless information has been accessed and stolen, or the enterprise deems the breach worthy of prosecution. File access auditing tools that provide the ability to immediately analyze file access both locally (host- based) and on the network will clearly describe the extent of a breach and thus can dramatically reduce the overall cost of an incident. Legal forensics, where necessary, can be time consuming and costly to complete for large deployments, depending on the methodologies implemented. Requirements will vary depending on the environment. A thorough breach analysis process will assist in guiding the legal forensics investigation at the time it is deemed necessary. 6

Resources and Workflow Along with integrating the appropriate tools and techniques required to answer critical questions, an effective process for breach analysis also identifies department ownership for each phase of the analysis. Having an understanding of the methods is the initial step; implementation follows and is often more challenging. Depending on resources, skillsets, and business models, implementation can be through analysts within the organization or in some cases, security partners can be utilized for both analysis and assistance in remediation. Figure 3 provides examples of common department ownership and depicts the incident response process that is followed in many organizations. Figure 3 Breach Analysis Resources and Workflow 7

Reading List The Known Unknowns. NSS Labs https://www.nsslabs.com/reports/known- unknowns- 0 Does it Matter, Or Was it Just Noise? NSS Labs https://www.nsslabs.com/reports/incident- response- part- 1- does- it- matter- or- was- it- just- noise The Targeted Persistent Attack (TPA) The Misunderstood Security Threat Every Enterprise Faces https://www.nsslabs.com/reports/targeted- persistent- attack- tpa- misunderstood- security- threat- every- enterprise- faces Top 20 Best Practices to Help Reduce the Threat of the Targeted Persistent Attack https://www.nsslabs.com/reports/top- 20- best- practices- help- reduce- threat- targeted- persistent- attack 8

Contact Information NSS Labs, Inc. 206 Wild Basin Rd Building A, Suite 200 Austin, TX 78746 USA +1 (512) 961-5300 info@nsslabs.com www.nsslabs.com This analyst brief was produced as part of NSS Labs independent testing information services. Leading products were tested at no cost to the vendor, and NSS Labs received no vendor funding to produce this analyst brief. 2014 NSS Labs, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the authors. Please note that access to or use of this report is conditioned on the following: 1. The information in this report is subject to change by NSS Labs without notice. 2. The information in this report is believed by NSS Labs to be accurate and reliable at the time of publication, but is not guaranteed. All use of and reliance on this report are at the reader s sole risk. NSS Labs is not liable or responsible for any damages, losses, or expenses arising from any error or omission in this report. 3. NO WARRANTIES, EXPRESS OR IMPLIED ARE GIVEN BY NSS LABS. ALL IMPLIED WARRANTIES, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON- INFRINGEMENT ARE DISCLAIMED AND EXCLUDED BY NSS LABS. IN NO EVENT SHALL NSS LABS BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL OR INDIRECT DAMAGES, OR FOR ANY LOSS OF PROFIT, REVENUE, DATA, COMPUTER PROGRAMS, OR OTHER ASSETS, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 4. This report does not constitute an endorsement, recommendation, or guarantee of any of the products (hardware or software) tested or the hardware and software used in testing the products. The testing does not guarantee that there are no errors or defects in the products or that the products will meet the reader s expectations, requirements, needs, or specifications, or that they will operate without interruption. 5. This report does not imply any endorsement, sponsorship, affiliation, or verification by or with any organizations mentioned in this report. 6. All trademarks, service marks, and trade names used in this report are the trademarks, service marks, and trade names of their respective owners. 9