Partner Perspectives  Connecting marketers to our tech communities.
6/11/2015
04:35 PM
Ryan Vela
Ryan Vela
Partner Perspectives
Connect Directly
Twitter
RSS
0%
100%

Breach Defense Playbook: Hunting For Breach Indicators

Do you proactively hunt for malware on your network, or do you wait for your tools to tell you?

Every organization should perform a breach indicator assessment on a regular basis to identify potential indicators of compromise (IOCs). Without knowing if you have IOCs, you can’t mitigate and remediate potential unwanted software on your network. Additionally, by identifying IOCs on your network, you can identify security, configuration, and design gaps that will lead to network security enhancements and further people, process, and tool improvements.

The scope of your breach indicator assessment (BIA) should include both network communication and endpoint systems. The network communication BIA should include a real-time collection and analysis of network traffic with the sole purpose of identifying anomalies. The endpoint system BIA should look for anomalous process, files, and behaviors resident on internal workstations, servers, and mobile devices. In the end, you should have a report of a snapshot in time listing quantities of IOCs identified, their potential impacts to the organization, and recommended remediation activities.

The BIA can be thought of as a “hunt and expose” analytical search for IOCs in real time and may include static forensic analysis if a system is found to be associated with suspicious activity.

Network Breach Indicator Assessment

The network BIA should include monitoring network traffic and exposing IOCs in real-time. While you may already have firewalls, proxies, and advanced threat detection appliances on your network, you should also use a tool different than what you already have to compare results with what your SOC, MSSP, or SIEM sees. In other words, while your day-to-day security operations continue, you should use a network BIA to validate the accuracy of the data your teams analyze and the precision of the tools and processes with which the data is adjudicated.

You should deploy sensors as close to choke points as possible to get the most quantity of data flowing into and out of your networks. You should also consider deploying sensors at jump points between network segments to evaluate internal-to-internal traffic. All of the sensors should look for any IOCs from available threat intelligence databases that have access to both open and closed sources. So as to not impact operations, it is common to deploy these BIA sensors off of a mirror or span port and in promiscuous or “listen-only” mode.

Your edge-deployed sensors should pay attention to unusual amounts of data transmitted from a specific source or to a specific destination. The sensors should focus on misuse of standard ports and protocols; use of non-standard ports and protocols; and malformed packet transmission. The sensors should alert on communications originating from the internal network destined for systems with known connections to “botnets” or other malicious Internet-based networks. Lastly, the sensors should alert on attacks to third parties originating from your internal network address space. These types of attacks may be indications of botnet activity.

When looking at internal-to-internal communication, your internal sensors should look at activity patterns used by attackers targeting internal systems and segments for lateral movement. Specific misuse of system administrator programs and credential-gathering tools are good indications of lateral movement IOCs. Attackers commonly target less secure networks and systems as their initial entry point and then work their way laterally to escalate their access privileges so they can gain access to more secure targets containing sensitive data.

Your sensor tools should give you full network visibility of both encrypted and non-encrypted channels and remain protocol and port agnostic. The sensors should be able to function at line-speed in real time and detect advanced threats, infiltration, and data leakage.

When performing your network BIA, you will want to obtain data over at least one week to include a weekend. Weekend traffic is often different than business-hours traffic. Of course, the more data you obtain, the more comprehensive your analysis will be, but this must be balanced with resources available to complete the assessment. In other words, the more data you obtain, the more time will be required for your team to analyze the output.

During your assessment, engage with technology owners and stakeholders within your organization so that they can help you understand if certain network communication is normal or suspicious. Don’t work in a vacuum. If you should happen to find a critical IOC that points to a potential intrusion, then you should immediately escalate the finding to the appropriate security operations personnel for response.

System Breach Indicator Assessment

When hunting and exposing IOCs on endpoint systems, you should use an automated scanning tool to look at system registries, file date-time stamps, file metadata, processes running in memory, and other system artifacts. Your scope should include servers, workstations, and mobile devices regardless of operating system.

This collection of data can then be analyzed and adjudicated for any IOCs present. Scanning should be performed on systems while they are running and processing data. You must ensure that when you are performing your scanning that your tool is appropriately tested for your environment and minimizes any impact to operations and performance of your systems.

You should analyze the memory of systems to look for IOCs of running processes, handles, files, keywords, network communications, privileged user account misuse, and other items. You should analyze file systems by looking at programs that are set to run automatically such as pre-fetch actions, registry files, master file tables, installed services, file date-times, and other artifacts.

If you do find suspicious IOCs, then you can escalate the system BIA for that specific system with forensic tools to further adjudicate the alert. This may include taking an image of the hard drive, capturing memory, isolating the system from the network, or taking the system offline completely.

In the end, you should produce a report that includes the scope of activities you performed, your approach to the assessment, a timeline of your activities, and the results of the BIA. You should follow your results and observations with a concrete set of tactical recommendations that can enhance the security of network communication and system security. As always, it is recommended that you maintain a graded chart so as you perform additional assessments in the future, you can evaluate your organization’s improvement.

Ryan Vela is a Regional Director for Fidelis Cybersecurity. He has 15-years' experience in conducting investigations and digital forensic analysis. Ryan served as a Strategic Planner at the Defense Computer Forensics Laboratory (DCFL), where he established plans for the ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Australian Teen Hacked Apple Network
Dark Reading Staff 8/17/2018
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
Fidelis Cybersecurity provides organizations with a robust, comprehensive portfolio of products, services, and expertise to combat today's sophisticated advanced threats and prevent data breaches. Our commercial enterprise and government customers around the globe can face advanced threats with confidence through use of our Network Defense and Forensics Services – delivered by an elite team of security professionals with decades of hands-on experience – and our award-winning Fidelis XPS™ Advanced Threat Defense Products, which provide visibility and control over the entire threat life cycle.
Featured Writers
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-2765
PUBLISHED: 2018-08-20
pyro before 3.15 unsafely handles pid files in temporary directory locations and opening the pid file as root. An attacker can use this flaw to overwrite arbitrary files via symlinks.
CVE-2018-15594
PUBLISHED: 2018-08-20
arch/x86/kernel/paravirt.c in the Linux kernel before 4.18.1 mishandles certain indirect calls, which makes it easier for attackers to conduct Spectre-v2 attacks against paravirtual guests.
CVE-2018-15572
PUBLISHED: 2018-08-20
The spectre_v2_select_mitigation function in arch/x86/kernel/cpu/bugs.c in the Linux kernel before 4.18.1 does not always fill RSB upon a context switch, which makes it easier for attackers to conduct userspace-userspace spectreRSB attacks.
CVE-2018-15573
PUBLISHED: 2018-08-20
** DISPUTED ** An issue was discovered in Reprise License Manager (RLM) through 12.2BL2. Attackers can use the web interface to read and write data to any file on disk (as long as rlm.exe has access to it) via /goform/edit_lf_process with file content in the lfdata parameter and a pathname in the lf...
CVE-2018-15574
PUBLISHED: 2018-08-20
** DISPUTED ** An issue was discovered in the license editor in Reprise License Manager (RLM) through 12.2BL2. It is a cross-site scripting vulnerability in the /goform/edit_lf_get_data lf parameter via GET or POST. NOTE: the vendor has stated "We do not consider this a vulnerability."