hawkeye g technical white paper -...

14
HawkEye G Technical White Paper OCT. 2015 RELEASE 3.1

Upload: dinhminh

Post on 28-Jan-2019

214 views

Category:

Documents


0 download

TRANSCRIPT

HawkEye G Technical

White Paper

OCT. 2015

RELEASE 3.1

2

HawkEye G Technical White Paper

Table of Contents

I. Executive Summary ..................................................................................................... 3

II. Detection ...................................................................................................................... 4

III. Verification ................................................................................................................... 7

IV. Response ..................................................................................................................... 9

V. Conclusion ................................................................................................................ 14

3

HawkEye G Technical White Paper

With companies like Target, Neiman Marcus, and Home Depot, and government entities like the Office of Personnel Management and the IRS making the headlines seemingly daily, there’s no doubt that organizations are deep into a continuous battle against attackers. Regardless of the size of your organization, you’re going to be breached.

While prevention should be an integral part of your security architecture, you can’t depend on it to stop every threat. Organizations are lacking the total visibility they need not only into their networks, but their endpoints as well. And even if you have a detection-only solution in place, this can create the entirely new problem of alert overload. Most security teams are working non-stop to manage and respond to the thousands of alerts they’re receiving each week, many of which are ghost alerts or false positives, or aren’t a real security risk at all.

HawkEye G can solve each of the issues listed above by providing organizations integrated detection, verification, and automated response capabilities in a single platform. Some of the main benefits of this comprehensive solution include:

• Detection of known, unknown, and zero-day threats that most anti-virus products miss

• Threat detection without signatures, coupled with cloud-based threat intelligence, and behavioral analytics on endpoint activity

• Endpoint and network correlation through HawkEye G Host and Network Sensors, as well as integrations with other solutions including Palo Alto Networks and FireEye

• Decreased false positives and ghost alerts through aggregated threat scoring and analytics with the purpose-built ThreatSync™ event fusion and behavioral analytics scoring capability

• Faster and more efficient response to threats through policy-based automated and/or machine-guided surgical remediation targeting a single malware process, and bulk remediation actions

• Investigation support for one-click displays of infection spread, “patient zero”, and dwell time

• Integration to SIEM reporting systems and Splunk real-time dashboards

Hexis Cyber Solutions has developed this solution to meet the needs of your security and incident response teams in a single integrated detection and response platform. HawkEye G leverages your existing security investments, avoiding the “one threat, one tech” dilemma that security professionals often face when evaluating new security technologies. The rest of this white paper will dive deeper into how HawkEye G enables you to detect, verify and respond to the threats attacking your organization today.

Executive

Summary

4

HawkEye G Technical White Paper

In order to have a complete 360° view into where hackers may be hiding, you need to make sure that you have visibility into both your endpoints and network to deliver an end-to-end picture of threat actor activity on the endpoint. HawkEye G provides this visibility through our Host and Network Sensors.

Host Sensors

The HawkEye G Host Sensor provides you total visibility into your endpoints, enabling you to detect, verify and respond to cyber threats. Host Sensor capabilities include a combination of real-time event capturing and signature-free detection for unknown threats. The lightweight agent uses real-time eventing to capture the file system events, executing processes, network communications, and registry events to deliver the most-comprehensive endpoint detection available without the overhead found in traditional endpoint technologies.

Real-time eventing delivers three main benefits over traditional scanning and polling/querying approaches:

1. Less than 1% CPU utilization, 25 MB RAM, and 1 KB/sec network usage on average

2. Continuous real-time eventing and recording captures events and observables as they occur, and can then execute countermeasures that will interrupt the malware delivery process reducing the time the external threat actor can operate on the endpoint, if at all

3. As events and observables are captured as they occur (created, changed, deleted), there is no need for them to be scanned and re-scanned if no change occurs, saving host resources and preserving end-user computing experience

The Host Sensor incorporates signature-free detection analytics utilizing host heuristics running locally on the endpoint that analyzes files, processes and registry events as they are executed. Host heuristics use static and dynamic analysis to provide additional confirmation of known malware, and help find zero-day and unknown malware variants, including:

• Host heuristics analysis is executed on an event-driven or baseline basis

• File heuristics are executed when a file is newly created, modified or as part of a baseline function

• Registry heuristics are executed when a persistent point is created or modified

• Process heuristics are executed when a process is started, a module is loaded or a thread is created, including the ability to find memory-resident malware

HawkEye G Host Sensors leverage 175 different heuristics that are then calculated individually and combined with other heuristics to give an overall score that represents the maliciousness and “goodness” of the object, greatly reducing false positives and ghost alerts. Host heuristics are further scored using the Hexis cloud-based Malware Verification Service (MVS) which can raise or lower the threat score of a heuristics hit or even mark the heuristic hit as a known “good.”

Detection

5

HawkEye G Technical White Paper

Detection Effectiveness

Real-world deployments of HawkEye G into organizations with existing security technologies (host AV, next-generation firewall, malware analysis sandboxing vendors, even cloud-based systems like DNS protection) have shown that traditional security products are not effective in preventing or detecting advanced threats.

The following chart shows real-world infection percentages when HawkEye G is deployed into existing systems, with infection rates between 12% - 36%. Not only does the system detect malware not previously discovered, but the host-based response capabilities – fully automated, partially automated, machine-guided, and/or bulk actions – can quickly and easily clean up infected networks at an increased speed and cost savings compared to manual or command line interface based response systems.

Baseline Recording for Malware Hunting

All events and observables captured by the real-time Host Sensor for both online and offline endpoints are stored on the HawkEye G Manager appliance for searching and correlation.

Storing real-time event results enable security analysts to conduct malware hunting missions and ad hoc investigations against the events and observables themselves, regardless if HawkEye G verified those events as confirmed or suspicious infections.

Real-World Infection Detection Rates

Customer A Customer B Customer C

Initial Host Sensor Distribution 1,872 host sensors 400 host sensors 4,500 host sensors(total) (out of 30,000 total) (out of 1,000 total) Prevention Security Technologies Cisco ASA Cisco ASA/IPS/SSM Trend Micro AVin-place FireEye OpenDNS Sophos AV McAfee AV Trend Micro AV Malwarebytes

Infection % 637 infected hosts 50 infected hosts 800+ infected hosts 36% infection rate 12% infection rate 17% infection rate

Value-add Verification of FireEye alerts Reduced manual verification Stopped and cleaned Bulk response via automation of IDS alerts by 50% Conficker in first 30 minutes

6

HawkEye G Technical White Paper

Some examples of real-time malware hunting include:• Upon receiving a list of IOCs from a threat intelligence provider or other security

device, determine if those IOCs exist on any endpoint in the environment, regardless if the host is online or offline. Additionally, find if the malware is dormant, executing or communicating on the network.

• Determine the “infection spread” of malware incidents – is only one host infected or is it spread across dozens or hundreds of hosts?

• Find patient zero, the first infected host for a specific malware sample. Use a time-based search to find other events occurring on that endpoint at the same time as that first infection to find related events.

Network Sensors

The Network Sensor line of security appliances for the HawkEye G platform operates in concert with the real-time Host Sensor providing comprehensive detection across a range of network sizes and speeds, from 10-gigabit line rates down to megabits. This solution supports data centers, Internet aggregation points, headquarter offices, distributed environments, branch offices, and more.

The Network Sensors utilize a low-latency, transparent deep packet inspection technology to detect application usage by external threat actors operating internally in a network regardless of what port or protocol is being used for communications. The inspection module detects and categorizes thousands of protocols and applications looking for outbound communication from infected endpoints, specifically for command and control (C2) traffic, resolution of malicious domain names and downloading of second stage exploit and remote access toolkits.

Network sensors can be deployed in out-of-band (SPAN/Tap) mode for passive monitoring and creation of indicator scores for that host, or in inline mode to add real-time blocking and redirection. When deploying in inline mode, the network sensor can determine the original source host behind web proxies using X-Forward-For (XFF) HTTP header field and DNS servers using DNS injection. Indicators specific to those source hosts are created and fed into HawkEye G’s ThreatSync™ threat scoring model.

HEXIS SECURITY

OPERATIONS CENTER (HSOC)

HEXIS THREAT FEED

HAWKEYE GMANAGER

HQ NETWORKNETWORKSENSOR

INTERNET

NETWORKSENSOR

INTERNET

INLINE Mode

SPAN Mode

HawkEye G Architecture

7

HawkEye G Technical White Paper

Verification As detection of the threats on your endpoints and network improves, you can bet that the number of alerts you’re receiving is going to go up as well. While some of the alerts are valid and require your immediate attention, most of these alerts are probably ghost alerts and false positives.

Our ThreatSync functionality aggregates threat data to confirm host infections through event fusion techniques which normalize alerts into a common model and correlates them with each other. This includes built-in integration with third-party vendors such as Palo Alto Networks and FireEye, with more to come.

Through ThreatSync, HawkEye G can verify the threat and assign a unified value, or threat score, to notify response teams of the threats that need their attention now (malware actively executing and communicating to external locations), the threats that can wait (confirmed malware that is dormant, non-executing), and those threats that might require investigation (zero-day malware or network activity without host confirmation).

Multiple verification methods are executed simultaneously on each event recorded by the real-time Host Sensor – matching to the global/local Threat Feed, query to the cloud-based Malware Verification Services, and analyzing the signature-free host heuristics. Each verification combination produces an individual score for that indicator, and multiple indicators are scored in concert using behavioral analytics based on endpoint activity.

The following screen shot shows a hidden executable (using a .tmp file extension) that received a suspicious score of “7” based on the multiple verification methods – does not match the Threat Feed, a potential classification from the cloud-based Malware Verification Service, and a threat hit using the signature-free host heuristics.

ThreatSync Verification Includes:• Real-time Event Fusion of host and

network sensor events

• Behavioral analytics focused on the threat actor activity

• Confidence-based scoring drives reponse prioritization and automation policies

• 3rd party integrations with Palo Alto Networks and FireEye

ThreatSync™

Integrated Detection with 3rd party Devices

For many organizations, implementing multiple solutions to protect their sensitive data is inevitable. HawkEye G enables you to get the most out of your existing solutions like Palo Alto Networks®, FireEye® and Splunk®. Hexis HawkEye G is able to pull alerts and threat triggers from Palo Alto Next Generation Firewall and WildFire™ malware analysis solutions, as well as FireEye Network Security (NX). From there, the system can automatically verify these alerts without manual intervention, score the activity based on the ThreatSync analytics model, take remediation action (automated or machine-guided), and push alerts through to Splunk and other SIEM vendors. We will continue to build out integrations and grow our ecosystem.

8

HawkEye G Technical White Paper

Threat Feeds

HawkEye G products receive hourly and daily threat feeds from the Hexis Secure Operations Center (HSOC) that deliver early-warning intelligence of malware, command and control servers, bot nets, and second stage download sites. Multiple commercial, OEM, open source, and Hexis research feeds are aggregated and de-duplicated into a single threat feed that is pulled from HawkEye G Manager deployments through mutually authenticated and encrypted communications.

The unified Threat Feed covers the following areas:• Malware data

• Signatures feeds, AV reference feed, user-agent feed, flow feed, and hash feed• Phishing URL feed

• List of URLs to serve exploits used in phishing attacks• Controller feed

• Tracking of over 3,000 active botnet command and control IPs across multiple protocols (HTTP, IRC, P2P, etc.), domain names, HTTP URL, and more

• Open source feeds

• Proprietary threat research conducted by Hexis

Customers can augment the Hexis-provided threat feed with their own file hashes, URLs, domains, and IPs by adding them to the local threat feed on the HawkEye G Manager server, either through the UI or programmatically through supported APIs.

Malware objects from Palo Alto Networks WildFire and FireEye NX are automatically added to the local threat feed when integrated into ThreatSync. In addition to adding the sandbox output into the local threat feed for future detection, the system automatically queries the up-to-date baselines of all hosts protected by the Host Sensor to determine if any host (not just the targeted host) has IOCs for those sandbox artifacts, saving hours of research often performed manually by security analysts to verify the alerts from those platforms.

HawkEye G Threat Verification Details

9

HawkEye G Technical White Paper

Response Once a threat has been detected and verified automatically by the system, a range of network and host-based countermeasures are deployed to remediate and remove the threat. These countermeasures may be automatically executed based on corporate policy or machine-guided involving human-in-the-loop threat response and remediation.

HawkEye G offers you a variety of countermeasures that execute on the host or network traffic. Machine-guided actions are executed using the role-based web interface on a single indicator or using bulk actions on tens, hundreds, or thousands of indicators at one time, without logging into the remote device.

Host-based countermeasures include:Kill Process

• Kills an executing process, both for file-backed or memory residentQuarantine File

• XORs (exclusive or) the file and moves it to a quarantine directory; auto-deletion (time-based or never) deletes quarantine files without user intervention. Works in tandem with kill process action to remove an open file handle on the binary image

Undo Quarantine File

• A manual action to “undo” the remediation, reverting the file to its original location with original file permissions; optional action to add that file hash to the whitelist and re-score all devices that have that same file

Remove Registry Value

• Removes the malware file path from persistent registry keys, for both new registry keys and existing benign keys that have been hijacked by the malware

Undo Remove Registry Value

• Reverts the key value back to the last state before the removalWhitelistafileorprocess• Used to further refine indicators for custom or rare software that might trigger host

heuristics

Network-based countermeasures include:URL Matching and Blocking

• Blocks the access to URLs that serve as downloaders for second-stage malware and remote access toolkits

DNS Injection

• Rewrites the reply of the DNS lookup to substitute the IP address of the internal HawkEye G Bot Trap honey client instead of the real external server; all subsequent traffic to that host from the malware processes are captured by the Bot Trap

IP Redirection

• Transparently redirects traffic to/from the real external server to the Bot Trap for further analysis

10

HawkEye G Technical White Paper

Policy-based Automated Responses

All host-based countermeasures can be executed manually by the security analyst using the role-based HawkEye G web management interface, with full audit logging and SYSLOG output to an external SIEM reporting system or Splunk.

Automated policies are defined using fine-grained policies based on multiple configurations per policy:

• The order of the policy – policies are executed top-down in priority order

• Target on which to execute the policy – IPs, IP subnet, host name, Active Directory-machine groups

• Device threat score – a minimum device score or higher to trigger the policy action

• CYBERCON score – a macro threat level to allow a single change to move into more, less, or no automation

• Actions – including kill process, quarantine file, remove registry value, run forensic surveys, and more

Multiple policies can be defined in tandem to deliver a stepwise automated response capability across an enterprise. For example, automated policies can be defined to quarantine both confirmed and suspicious malware files on important servers, but only kill confirmed processes – this dramatically decreases the dwell time and breaks the cyber kill chain of the threat actor while minimizing any potential side effects to that system since process actions are only on known bad malware.

For user workstations, policies can be set to automatically kill confirmed processes and quarantine files for on-net users, but automatically kill both suspicious and confirmed processes and quarantine files for off-net users that are not protected by the organization’s perimeter security systems.

Policies can also be set for different user groups, for example full automation for back office support staff (admins, accounting, finance, receptionists, etc.), partial automation for executive and management staff, and no automation for critical users like traders, bank tellers, medical devices, payment gateways, and so on.

You can also use the CYBERCON macro setting to change the automation policy during certain times of day or change management periods:

• For small organizations with a single security person, turn on automation during nights, weekends, and holidays, but move to machine-guided mode during business hours

• Turn on full automation if the organization is under an active, sustained attack campaign (like the case with Sony, where they turned off their servers because they didn’t have an automated response capability!)

• Turn off automation entirely during change management windows, e.g. rolling out a new version of Microsoft Office or SAP, or during change management business periods, e.g. no changes from November 1 through January 15 for retail organizations

11

HawkEye G Technical White Paper

End-to-End Data Flow

HawkEye G’s integrated detection and response platform delivers multiple point functions in a single product: host-based detection and response, network-based detection and response, integration and correlation of supported third-party security devices, investigation support, malware hunting, and integration into security reporting systems.

CLOUD INTELLIGENCESERVICE

Machine-Guided Actions

THIRD-PARTYINTEGRATIONS

ThreatSync

HAWKEYE G MANAGER

HAWKEYE GNETWORK SENSOR

HEXISTHREAT FEED

PAN NGFW + WILDFIRE®

HAWKEYE GHOST SENSOR

FIREEYE® NX

Automated Actions

SYSLOG Output

+ ...

ENDPOINT + NETWORK COUNTERMEASURES:

KillQuarantineRegistryBlockForensicsFuture

POLICY MANAGER

HawkEye G Integrated Data Flow

12

HawkEye G Technical White Paper

Deployment

Scenarios

Host Sensor Deployment

HawkEye G supports hosts on the corporate network (“on-net”), hosts not on the corporate network without a VPN but Internet connected (“off-net”), and non-Internet connected machines (“off-line”). The Host Sensor communicates to the HawkEye G Manager through mutually authenticated, encrypted protocols that are NAT-traversal capable over TCP/IP.

It’s important to understand your host and user populations before setting up the system to account for on-net and off-net hosts. If you will be supporting off-net hosts without requiring a VPN, there are two deployment options for the HawkEye G Manager server appliance:

1. Deploy a single HawkEye G Manager appliance in the DMZ that supports both on-net and off-net hosts. Configure the host sensor installation with the host name of the manager appliance in the DMZ and verify that both on-net and off-net devices can communicate with the DMZ server.

2. Deploy one HawkEye G Manager appliance internally for on-net hosts and a separate/dedicated HawkEye G Manager in the DMZ just for off-net hosts. Configure the host sensor installation with two host names, one for the internal and one for the DMZ servers. The Host Sensor will try to communicate with the first in its list, and if it can’t communicate with the internal one in the case of off-net hosts, it will next attempt the DMZ server.

a. This deployment also allow the organization to set up different automation response policies – as one example, the internal server is set up with partial automation (only act on confirmed infections), while the DMZ server for off-net hosts is configured in full automation (both confirmed and suspicious infections) since the off-net host is not protected by perimeter security devices, URL filters, and so forth.

Network Sensor Deployment

The Network Sensor can be deployed in SPAN/Tap more for detection-only, or inline to provide detection with policy-based network actions. All Network Sensor models with copper/RJ45 gigabit Ethernet NIC module support power-off/watchdog fail-open bypass capabilities. Customers can also utilize an external hardware bypass for out-of-band cabling, support for fiber connections, and lower-latency fail-open capabilities.

Multiple Network Sensors

Overcoming Hosts behind a Local DNSIn many cases where an Active Directory controller is used as a DNS server inside the network, all DNS requests that are unknown will be forwarded to an external DNS server. When this DNS forwarding occurs the Network Sensor will see the local DNS as making the request. For better analytics the original requesting host must be exposed behind the local DNS server. One way to do this is to use a Network Sensor in tap mode to watch all DNS requests sent to the internal DNS server. This helps to better correlate the original host with each request hitting the edge Network Sensor.

13

HawkEye G Technical White Paper

Redundant and High Availability ModelsHawkEye G can support very redundant and high availability models. In this situation, multiple Network Sensors are used to ensure all outbound traffic is still inspected. Internal or external hardware bypasses ensure there is no single point of failure. Spanning tree of policy routing will not be affected in this scenario.

Remote Sites or Wireless NetworksNetwork Sensors also support the monitoring or traffic coming from remote sites or wireless networks placed into the network to examine traffic coming from the different sites. In the management console, it’s easy to setup additional policies that inform the operator when a wireless client or a remote worker attempt to access IP addresses or URL sites that are internal to the company and should be restricted by security policies. In this case, HawkEye G can block a URL and return an informative page or redirect the offending host to the Bot Trap for further inspection.

NAT Scenarios

Network Address Translation, or NAT, was originally devised to conserve IPV4 address space. It provides for a set of externally unroutable IP addresses to be used behind a NAT device.

HawkEye G Host Sensors and Network Sensors support NAT-traversal using sensor-to-manager initiated connections since host devices and Network Sensors can be deployed in remote offices or networks that have NAT gateway. Connections are not initiated from the manager to the sensors, even for response actions. Response actions are queried from the host to the manager through the sensor-to-manager initiated communication. The system will operate in NAT environments as long as the Host and Network Sensors can initiate outbound communications to the HawkEye G Manager appliance (through outbound NAT and/or inbound NAT rules).

14

HawkEye G Technical White Paper

About Hexis Cyber SolutionsHexis Cyber Solutions Inc. is a team of cybersecurity experts delivering solutions that enable organizations to defend against and remove cyber threats at machine speeds before they do damage. Hexis' advanced security solutions use real-time endpoint sensors, network detection, and threat analytics to provide organizations with an intelligent and automated threat detection and response solution. Hexis solutions deliver improved visibility into the network and endpoints, threat verification, and automated threat removal capabilities for organizations of all sizes. Hexis Cyber Solutions, Inc. is a wholly-owned subsidiary of The KEYW Holding Corporation (KEYW), based in Hanover, Maryland with engineering offices in Columbia, Maryland and San Mateo, California. Hexis' solutions were developed leveraging KEYW's expertise in supporting our nation's cybersecurity missions.

This white paper presents the capabilities of the HawkEye G platform to detect, verify and respond to the known and unknown threats impacting your organization. You should now have a better understanding of HawkEye G:

• HawkEye G detects known, unknown and zero-day malware that most anti-virus products miss leveraging sensors on both endpoints and the network

• HawkEye G not only detects malware that existing security technologies did not, but quickly responds to and remediates these threats

• HawkEye G’s Endpoint and Network Sensor correlation, in addition to third party integrations, provide greater visibility and verification of threats

• ThreatSync event fusion and behavioral analytics scoring capabilities decrease false positives and ghost alerts through aggregated threat scoring and analytics

• HawkEye G delivers a faster, more efficient response to threats through policy-based automated and/or machine-guided surgical remediation, targeting a single malware process, as well as bulk remediation actions

• Real-time eventing through the HawkEye G Host Sensor enables malware hunting on both online and offline endpoints

• HawkEye G leverages real-time dashboards through integrations with Splunk and other SIEMs

Hexis HawkEye G can provide the security of next-generation endpoint detection and response you need to protect your organization.

For more information, please contact us at +1-443-733-1900 or [email protected].

Conclusion

Copyright © 2015 All rights reserved. Hexis Cyber Solutions and HawkEye are protected by U.S. and international copyright and intellectual property laws and are registered trademarks or trademarks of Hexis in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. Hexis Cyber Solutions is a wholly-owned subsidiary of The KEYW Corporation.

Hexis Cyber Solutions | 7740 Milestone Parkway, Suite 400 | Hanover, MD 21076 | [email protected] | 443.733.1900