Current Security Operations and DFIR problems

Cyber security, DFIR, Incidentresponse

By Rukhsar Khan on Tuesday, December 11, 2018

A Security Operations Center (SOC) team is responsible to detect suspicious and malicious cyber activity in an organization. Once such activity is confirmed, the SOC team generates a security incident that includes the corresponding information and hands it off to the Computer Emergency Response Team (CERT) or Computer Security Incident Response Team (CSIRT). The responsibility of the latter teams is to either validate the potential security incident and coordinate the Incident Response (IR) process or if it turned out that the security incident was a false positive, mark it as such and close it. SOC, CERT and CSIRT are also known as Security Operations (Secops) and their primary goal is to detect and respond to Cyber Security threats in order to defend an organizations networked computer environment including their crown jewels.

If Security Operations indentifies that the organization has been breached, their work is usually finished since they lack the expertise to fully comprehend a breach. So they hand the incident off to a DFIR team. This team consists of the most skilled and sought-after experts in the Cyber Security industry. DFIR experts have the ability to forensically understand and report on the full scope and complete impact of a data breach, starting off with the date, time and method of the initial compromise over privilege escalation and lateral movement until the ultimate attack target is accomplished which is then exploited and the breach is executed, whether that’s the exfiltration of confidential data or the manipulation of systems or anything else bad. For discovering this, DFIR experts use tens or hundreds of different methods and tools. They also gather and preserve evidence and provide the means for its usability during litigation.

Major Secops problems and the reasons we have found

Let’s begin with an overview of the major Secops problems and the reasons we have found behind these.

Major Secops problems:

Most organizations are pretty bad at Security Operations. According to Forrester, the 2017 median breach confirmation time is approx. 101 days.

How to express IOCs and the findings in a meaningful way? Common language – e.g. OpenIOC, STIX, etc. – between systems and tools in the organization required!

How to convert data formats? Cyber Security vendors are currently providing result sets of queried data in their own JSON format. Conversion of data formats required!

Figure 1.1: Major Secops problems and their reasons

If you give an attacker 100 days of time to move freely in your environment after he has compromised it the evidence is fairly strong that your organization is pretty bad at Security Operations. This is what currently happens in a lot of organizations. According to a Forrester report1 the median breach confirmation time in 2017 was 101 days. So basically it took 101 days for Security Operations to confirm a breach and hand it off to the DFIR team.

On the contrary, many Secops teams are currently sending too many unqualified breach confirmations to DFIR which is annoying those teams that much that they often request them not to forward anything at all.

A major reason that we have found why this is so relates to the fact that Secops is scratching on the surface only. They have their defined use cases which range from trivial to complex ones, however, an approch that would classify, categorize and organize attack scenarios holistically is completely lacking.

Also, when it comes to integrating with a CTI solution, Secops is mostly concentrating on “Isolated IOCs” only. By “Isolated IOCs” we mean IP addresses, hash values, domain names, etc. that are neither put into relationship nor is there provided any additional context as part of the CTI. Firstly, isolated IOCs are of little value if no context is provided and secondly, they are changing too rapidly during an attack so that one can not entirely rely on these. The Verizon DBIR 2016 Report states for example that 99% of malware hashes were seen for just 58 seconds or less.

A robust and actionable CTI can help organizations in providing detailed context around an IOC. E.g. if your IOC is a bad known IP address, related entities like related IP addresses, domain names, email addresses, hash values, malware, products and tools, a Threat Actor and his used TTPs – tactical intelligence, a Threat Actor and his motivations – strategic intelligence, intelligence reports, etc. shall be provided. Having these kind of real facts helps in staying focused during the analysis without loosing track.

Checking the local relevance – findings – of IOCs adequately is another important step during an analysis. Once CTI provided IOCs have been validated in the local context it’s essential to pull in the corresponding timestamps – first-, last-packet –, source-destination relationships, bytes sent, bytes received, protocols and ports used, duration, domain name, etc. Not only is Secops currently not looking into these kind of details. They often even don’t have the right technology in place that would provide this level of information.

IOCs and local findings along with all their corresponding context needs to be expressed in a meaningful way. For this, a common expression language is required that allows to seemlessly share data between systems and tools and in addition to this also visualizes the relationships between these. OpenIOC and STIX are examples of such an expression language. OpenIOC was originally developed by Mandiant which is now owned by Fireeye whereas STIX is developed by OASIS which is a non-profit consortium that drives the development of open standards. In other words, STIX is Open Source and the current version is 2. STIX2 is specified in JSON format whereas its predecessors, STIX 1.1 and 1.2, were specified in XML format.

Unfortunately most Cyber Security vendors have not yet adopted STIX as their preferred output format. Result sets of queried data are still provided in the vendor’s native JSON formats which leads to heavy data conversion efforts if one wants to use STIX today. However, vendors have realized the importance of such an expression language and are therefore providing additional tools or have STIX2 compatibility on their roadmap.

Major DFIR problems and the reasons we have found

Figure 1.2 begins with a summary of the major DFIR problems and the reasons we have found behind these.

Major DFIR problems:

A plethora of tools with uncountable inputs and different output formats used manually on command line interfaces.

No or little integration with the organizational infrastructure. Hence, data collection is an entirely manual and time consuming process that heavily relies on input from the Secops and Infrastructure teams.

No proper communication and information sharing across the organization.

No or poor process driven, standardized procedures for known threat scenarios (poor playbooks).

Major reasons:

Forensic tools – open source and commercial – are mostly self-contained with little integration with 3rd party systems. e.g. Opentext Encase or Access Data FTK have no REST API, same is true for open source tools!

Very difficult to provide standardized procedures. Every breach is unique!

Figure 1.2: Major DFIR problems and their reasons

Major problems that we have encountered during the last couple of months in DFIR teams is that they have to deal with a plethora of tools with uncountable inputs and different output formats that are used manually on command line interfaces.

One of the biggest challenges we have found is the lacking or little integration of the DFIR tool landscape with the organizational infrastructure. Hence, when DFIR teams are conducting a breach analysis, they heavily rely on input from the Secops and Infrastrucure teams when it comes to data collection. This is currently an entirely manual and time consuming process.

Also, a proper communication and information sharing with the rest of the organization is currently not possible except by means of a ticketing system.

A lot of DFIR teams are also lacking or dealing with poor process driven, standardized procedures for known threat scenarios which prevents them from conducting the breach analysis in a structured and organized way (poor playbooks). Often, organizations are afraid of funding internal DFIR teams because it’s hard to measure their success in a pre-defined timeline. In other words, if a DFIR team is not structured well, there is a high probability that the breach analysis timeline is not predictable. That’s why a lot of organizations hire an external DFIR Service Provider that acts as an Incident Response Retainer in case of an emergency.

Forensic tools used by DFIR teams, whether those are commercial products or open source tools, have one thing in common. They are mostly self-contained with no or little integration with 3rd party systems. As to the best of our knowledge, neither does Opentext Encase nor Access Data FTK, two well-known commercial products in the forensic field, have a REST API. The same is true for open source tools like Volatility, Plaso, Log2timeline, etc. This is the main reason we have found why DFIR teams are heavily dependant on the data provisioning from Secops and Infrastructure teams and are also not able to properly communicate and share information with the rest of the organization.

Also, it’s very difficult to provide process driven and standardized procedures because every breach is in one way or the other unique. However, there are many common pattern which are found in similar breaches.

with commercial and non-commercial products and tools from IBM, Recorded Future, Carbon Black, A10 Networks, Volatility and more . . .

This class is about Incident Response in a post-compromised environment.

In this class we will show you the major reasons why Security Operations is currently doing bad and what is required within Security Operations in order to produce high value results that can be consumed by a Threat Hunting and Forensic team. We will also focus on how to streamline security analysis, starting off with the initial triage within Security Operations to Threat Hunting to Forensics in case of an advanced targeted attack by quickly forming up a defense team that is able to collaborate directly from within IBM Resilient as the central hub for Incident Response.

The goal is to rapidly identify and respond to advanced adversaries that have gained a foothold in a compromised environment (post-compromise). The initial triage will be conducted by the Security Operations team (L1) which will hand-off valuable results to the Threat Hunting team (L2) which will in turn produce results that will be consumed by the DFIR team (L3) for a deep dive forensic analysis focusing on a few affected systems out of hundreds or thousands of systems... Read more