Isla Web Malware Isolation and Network Sandbox Solutions Security Technology Comparison and Integration Guide

Transcription

1 Isla Web Malware Isolation and Network Sandbox Solutions Security Technology Comparison and Integration Guide

2 How the Two Approaches Compare and Interoperate Your organization counts on its security capabilities continuously. Before making additions to your security framework, it s critical to understand what protections prospective technologies can provide and those they can t. This technical brief offers a detailed look at the capabilities offered by network-based sandboxing solutions and by Isla, a system that isolates Web-based malware. The brief then outlines how the two approaches can be used in tandem to provide compelling security advantages. Introduction To gain the upper hand in the battle against increasingly sophisticated cyber attacks, security teams need to continue to strengthen and adapt their defenses. To achieve this end, organizations have to architect a sound framework based on the concept of establishing defense in depth, leveraging a number of technologies, approaches, and processes. In assessing new technologies to bring into the mix, it is vital that decision makers have an accurate understanding of the products and approaches available, including their respective capabilities, and the threats they can and can t address. In this brief, we offer a detailed look at two types of offerings: The Isla Web malware isolation system offered by Spikes Security and network-based sandboxing solutions provided by other vendors. The following section offers a high-level description of various sandboxing approaches. Subsequent sections then provide a detailed look at network-based sandboxing and Isla to help clarify their specific purposes and capabilities, and describe their respective strengths. Finally, this brief offers insights into how these two technologies can be used in tandem to help establish a robust defense against cyber attacks. Sandboxing: Purposes and Capabilities At a high level, sandboxing refers to the process of running code in some form of a segregated environment, so that malicious code can be identified, constrained, or incapacitated. Through effective sandboxing approaches, an organization can therefore limit or completely negate the damage inflicted by malicious code. Sandboxing is a term that has come to describe some very different approaches. Following are three prominent categories of sandboxing: Application-level sandboxing. Over the years, application developers have introduced sandboxing into their offerings, including Web browsers, run-time environments, and browser plug-ins. Sandboxing in the Web browser refers to the process of separating browsing-based activities, so for example, one exploited tab on the users device is kept from eavesdropping or compromising data from other tabs. Through this approach, providers are looking to minimize the damage associated with a browser-based exploit. Endpoint-based sandboxing. With this approach, segregation of code execution is attempted within a given endpoint device, such as a user s laptop. For example, any time new code is downloaded, the code can be run in a restricted environment that attempts to limit the potential for malware to spread to the rest of the operating system, other devices, or the corporate network. Network-based sandboxing. While there are a range of network-based sandboxing approaches, in general, the key distinction is that, compared to endpoint-based approaches, network-based approaches run and inspect potentially malicious code in an isolated environment, typically an appliance. In addition, many vendors now offer cloud based sandboxing services. These alternatives are built on the assumption that application-level and endpoint-based sandboxes are routinely defeated. This paper will primarily focus on network-based sandboxing approaches, and explore their purposes and limitations. Following are some of the common capabilities network-based sandboxing solutions deliver. 2

3 Code Collection In some fashion, code needs to be directed or fed to the network based sandbox. Network approaches typically rely on some form of sensors, which are used to inspect traffic, automatically identify potentially dangerous code, and submit that code to the sandbox for inspection. Alternatively, other technologies enable administrators or other users to manually submit suspicious files to the sandbox. Inspection and Analysis When code is received, sandboxes execute it within a detonation chamber, which are generally comprised of a limited range of virtualized resources that simulate the environments of end user devices or other targeted systems. These sandboxes then run the code and look for signs of malware behavior, such as keystroke logging, data theft, attempts to access dynamically linked libraries, and so on. The detection of malicious code can trigger alerts or even automated remediation efforts. Through these capabilities, suspicious code can potentially be flagged and stopped before proliferation on the network or submission to the endpoint. Threat Databases and Intelligence Many vendor solutions offer databases that track application vulnerabilities, malware, and exploits that have been detected. These databases can be automatically updated within the customer deployment and they may be published in a central database that is maintained for all the vendor s customers. In this way, new malware samples that get collected by a given device can be shared to further remediation efforts, and to help establish new rules to strengthen other security defenses. Either through native capabilities, or through integration or partnerships with other vendors, some platforms enable integration of sandboxing intelligence with other security intelligence technologies, for example, SIEM, to help speed forensics and remediation. Approach Limitations Fundamentally, it is next to impossible for any sandboxing technology to realize a 100% success rate in combatting dynamic, so-called polymorphic malware or malware that attacks unknown, zero-day vulnerabilities. For sandboxing to work, there are several specific processes that need to happen successfully. However, each of these processes is fallible, and if any one fails, breaches may occur. Following are a few of the specific limitations: Degradation of User Response To stop the infiltration of malware, sandboxes will intercept communications and inspect code before it is forwarded to the user. While this approach offers the potential to intercept malware before it infects endpoints, it also can result in significant delays for end users. If users must wait several minutes for files to be inspected, they will often grow frustrated and find workarounds that enable them to bypass the security mechanism. Inability to Pre-empt Attacks In some cases, traffic gets forwarded directly into networks and endpoints, possibly at the same time or even well before the code is ever analyzed by the sandbox. As a result, significant damage may occur even if the sandbox correctly identifies the threat. Sensor or Collection Limitations Whether an organization s sandbox relies on automated or manual code collection, there s no guarantee that all malicious code will always be submitted to the sandbox for inspection. For example, pre-filtering techniques, such as antivirus engines, are often employed to limit which code is submitted to the sandbox. These mechanisms can either lead to too much code being submitted, or to the bypassing of actual malware. Limited Inspection Capabilities Depending on the sandboxing technology in question, only a narrow set of objects may be analyzed. For example, many sandboxing alternatives can t inspect JavaScript and HTML elements, and so can t detect Webbased exploits. Many systems may effectively evaluate potential Windows operating system threats, but fail to detect OS X or Linux threats. 3

4 Distinguishing Between Threats and Legitimate Processes Fundamentally, malicious code can behave in a fashion that s similar to legitimate applications. Quite often, this is the very intent of malware authors, who look to camouflage their efforts within legitimate processes. For example, just as remote desktop software enables an IT administrator to access an end user s desktop to diagnose an issue, malicious Trojans can leverage similar activities. It may be difficult to distinguish among these different uses in a programmatic fashion. Lacking Precision Sandboxing technologies may not be precise enough. The result is that many attacks will go undetected, or too many false positives will be generated. When too many alerts are created, administrators can t follow up on each potential threat in a timely manner. Either way, real threats can go unaddressed. Networking Constraints When sensors and sandboxes are distributed across locations and networks, organizations can encounter networking constraints, which either means the amount of code that can be analyzed is limited, or network performance can suffer. Cloud Exposure Cloud-based sandboxing alternatives themselves can present security and compliance issues. For example, routing even a subset of network traffic to a cloud-based sandbox may result in sensitive or regulated data making it into external servers, which may create security gaps or jeopardize compliance status. Susceptibility to Evasion Malware authors continue to evolve their approaches to combat automated sandboxing approaches. For example, many sandbox environments operate programmatically, rather than using mouse clicks. Malware authors have adapted their approaches to exploit this distinction. Their intelligent malware may therefore remain dormant until mouse clicks are detected, and so go undetected in sandboxes. In addition, sandboxing typically leverages virtualization technologies, which are used to efficiently create different code execution environments. Malware authors have therefore implemented intelligence to detect the presence of a hypervisor to evade detection. Limitations of Simulated Environments Sandboxes rely on their ability to simulate an end point environment, and then run code within that environment to identify malicious behavior. These simulation approaches often contain a number of limitations, including the following: Multi-component malware. Malware is often comprised of multiple sets of code that get distributed individually. Often, it is only when all the pieces are in place on a given target device that the malware gets activated. If distinct pieces of malware are executed in isolation in a sandbox, they therefore may not exhibit malicious behavior. Some advanced malware (such as APTs) may lay completely dormant until activated by a specific action or combination of conditions. Environmental variables. While sandboxes may attempt to emulate real endpoints, the wide variances and infinite combinations of user devices, platforms, applications, versions, patches, and so on make this impossible to realize in a comprehensive fashion. These differences can mean that malicious code goes undetected by a sandbox, but is still able to compromise the end point. Isla: Purposes and Capabilities Isla was specifically engineered to combat Web-based malware by delivering a security system that isolates and protects networks and endpoints. Isla represents an innovative, fundamentally differentiated alternative to other security technologies, such as secure Web gateways, firewalls, and intrusion detection systems. Unlike these other offerings, Isla doesn t rely on detection methodologies at all. Instead, it offers capabilities for isolating and transforming all Web content. Isla is built to effectively assume that all Web content is malicious. It isolates raw Web content from endpoints and the network, and then transforms that content into benign formats. Through this approach, Isla can stop all browser-borne malware, including malicious code that exploits zero-day vulnerabilities. Key Solution Capabilities With Isla, no Web content enters the network or endpoint devices. Isla transforms the content requested by a user into an optimized, encrypted, and proprietary data format before it ever makes it into 4

5 the network or onto the endpoint. This content is in a benign format that malware doesn t recognize and can t exploit, rendering it harmless to the endpoint. As a result, functions that try to hide malicious code can t gain a foothold in the network. For example, attackers using approaches like steganography to conceal malware within images or files won t be able to bypass Isla. When Isla is employed, endpoints remain isolated from the Internet. Isla leverages patent-pending technology that provides several unique isolation capabilities: Isolation in depth: Isla is the only solution that offers six degrees of isolation between the end user and an attack. Content Isolation- Isla isolates all web content in a hardened rendering engine with no access to the endpoint or other processes executing within the Remote Application Container or RAC. Process Isolation- The Isla RAC uses a hardened SE Linux operating system kernel which applies mandatory access controls to isolate each running process from each other. Session Isolation- Each Isla session is contained within its own RAC which is isolated from all other sessions using Intels VT-X technology. This delivers hardware based separation of the execution environment of each RAC ensuring that attackers have no access to other sessions. Appliance Isolation- The Isla appliance uses a hardened SE Linux kernel with mandatory access controls to ensure the appliance is isolated from attack be external threat actors. Connection Isolation- Isla utilizes a secure, proprietary transport protocol between the user and the appliance ensuring complete isolation of each connection. Physical Isolation- Deploying Isla outside the perimeter of the protected network ensures that no malware can attack the endpoint or be used for covert surveillance of the network. Key Solution Advantages Isla offers many critical advantages: Effective security. Through its unique isolation and transformation capabilities, Isla is extremely effective at keeping Web-based malware off endpoints and outside of corporate networks. With the solution, users can fully leverage the Web, without fear of malware. Flexible, scalable performance. Isla can effectively and efficiently scale based on the number of enterprise users. With the solution, users don t see any compromise in performance relative to traditional browsing approaches. Easy to deploy and maintain. Compared to many security technologies, Isla is far simpler to implement and operate. High ROI. According to a Ponemon Institute report, during a recent 12 month period, organizations spent $3.2M on average to clean up Web-based malware attacks.1 Because Isla is highly effective at stopping browser-based malware, costs associated with forensics, remediation, and business disruption can be significantly reduced. 5

6 Solution Limitations It is important to understand that Isla isn t designed to function as a replacement for an organization s sandboxing solutions or to replace other important security technologies. The solution can t secure the entire enterprise, but rather only guards against Web based threats. Isla won t address the risks posed by poor security controls or malicious employees, nor will it guard against attacks that are waged through other vectors, such as network-based exploits or malware that gets downloaded through USB drives or client-based . How Isla Can Work With Network Sandboxing Technologies Isla and network sandboxing technologies offer very different capabilities and approaches. For organizations that have invested in sandboxing technologies to bolster their threat intelligence capabilities, Isla can provide complimentary isolation technology to secure and prevent web attacks. All file transfers initiated by users through their web browsers are first processed within the Isla RAC to determine if the users security policy allows file downloads. If the user is authorized by the security team to download (or upload) files Isla can forward the files for inspection by a third-party solution such as a Network Sandbox server. Downloads can either be delayed until the sandbox has declared if a file is malicious or benign, or can be concurrently transferred to the end user while the sandbox inspects the file. In this case Isla can work as the enforcement point to control the download of malicious files or can provide the visibility into encrypted files that the network sandbox would normally not be able to inspect. Conclusion With the Isla solution, your organization can address one of its most critical and frequently targeted vulnerabilities the Web browser. Isla offers an innovative, highly differentiated approach that is effective at stopping all Web-based malware, making it an optimal complement to an organization s existing sandboxing investments. About Cyberinc Cyberinc delivers high-performance security solutions that enable businesses to leverage the power of the Web and benefit by complete protection against browser-borne malware. The company s initial anti-malware offering is Isla, a powerful and innovative solution that isolates all known and unknown Web-based malware. 6