Cyber attacks increase daily in both rate of occurrence and success. Cybercrime costs the global economy $450 billion dollars annually, and 53 percent of companies assessed in the Hiscox Cyber Readiness Report 2017 were unprepared for a cyberattack. With these stats in mind, it’s clear the ability to carry out the process of incident response (IR) is critical to organizations around the world. The IR process relies heavily on data, expert analysts and a swift response to incidents. We’ll discuss what IR is and why it’s important, provide some example data types IR analysts use and walk through an example IR scenario.

What is incident response?

The term incident response originally referred to the process by which an entity utilized resources to address and recover from a declared security incident. However, these days, the term is often used to describe the overall process of responding to any anomalous event, whether an official incident has been declared or not.

This definition raises another question: “So, what’s an incident?” The National Institute of Stands and Technology (NIST) created standards that include some helpful definitions. These are the the ones you need to know:

• Event: Any observable occurrence within a computing environment
• Adverse event: An event whose occurrence is negative for the entity
• Incident: A direct violation of a company’s computing and/or security policies

While these are the official definitions, those in the trenches use a much simpler vocabulary. Usually, IR means taking action on any of the above. For that matter, the term incident is often ascribed to a compromise or breach that is grave in nature.

Next, let’s review some examples of how IR looks in action:

• An anti-virus (AV) solution fires an alert for a known ransomware sample—Engage in IR.
  • If the AV solution properly mitigated the threat, no further action is needed. However, if the ransomware infection spreads to multiple hosts and vital data becomes compromised or potentially lost, it’s time to declare an incident.
• An advanced persistent threat (APT), such as a nation-state-sponsored threat actor, has been identified within the network—Engage in IR.
  • This is a prime example of an “all hands on deck” type of incident. You’ll need to work quickly to contain the breach and protect any intellectual property, customer information and other sensitive data.

Why is IR so important?

Having IR capability isn’t  just important—it’s critical. Per a Verizon report on data breaches, “No locale, industry, or organization is bulletproof when it comes to the compromise of data.” Companies around the world, regardless of size, are at risk for compromise. Simply read the headlines or ask any IR analyst. Even an air-gapped system in a bunker 20 miles beneath the surface of the Earth can be compromised.

The reason no company is safe is due to the rapid evolution of the threat landscape. Symantec, one of the leading AV and threat research companies in the world, reported 430 million new, unique malware samples in 2015. That number was up 36 percent from 2014 figures. That’s a lot of malicious code creating roadblocks on the information superhighway. Symantec also asserts that one in every 220 email messages contained malware in 2015 alone.

These infiltrations can come from many different sources, but remember, it only takes a single employee to access an infected email for a company to become compromised. Would you personally trust every single employee within your company or partner companies to avoid malware infections? Seriously incidents cost an average of $4 million, which is devastating to small businesses and large enterprises alike.

Why is data important to incident response?

Just as a detective relying on surveillance systems, witness testimony and forensic evidence to make a case, IR needs good data. The data gathered by security incident and event management (SIEM) platforms are the pieces to the puzzle of a security breach. Collecting, analyzing and monitoring this data allows you to act quickly as soon as you’re notified of a breach and prevent it from happening in the future. So, what types of data do SIEMs gather?

The best SIEMs collect as much information as possible. While auto correlation of events is fantastic, data collection throughout the network is pivotal. When data is available for analysis, IR analysts are able to stitch snippets of various data sources together to paint a holistic picture. If data is not available to the IR teams, this activity cannot occur.

Much of the data made available to IR analysts comes from network security monitoring (NSM). The practice of NSM involves collecting and analyzing network and host data to facilitate with IR. What data are analysts looking at? While this is not an exhaustive list, the following are examples of the types of data that analysts find useful for IR purposes:

• Firewall/Proxy logs
• Endpoint logs
• Wire data

Firewall/Proxy logs

The logs generated by firewalls and proxies are two of the most useful log types when it comes to investigating network-based activity. These logs are particularly useful when the logging mechanism itself is able to parse out the protocols and applications being used in traffic, such as what’s available with a next-generation (NG) firewall.

Endpoint logs

The hosts within a network are considered endpoints, and these logs are crucial. Endpoint logs can consist of application-based logs generated by processes running on the box, but the most commonly-associated endpoint logs are operating system logs. Event logs are the logs most associated with endpoints logs, as they exist within Windows environments. Event logs such as the system, security and application logs provide a wealth of information.

Wire data

From a network forensic analysis standpoint, wire data is an important data source. Wire data is the totality of data that traverses the network, which includes the metadata along with full payloads of each transaction.

Use case: Data to the rescue!

The examples provided above are just the tip of the iceberg when it comes to data sources that IR analysts can use in their trade. As we look at use cases, it becomes clear how this data informs our decisions and maps out the best response to a data breach.

Our scenario:

An intrusion detection system (IDS) fires a heuristic-based alert that has identified internal-to-external Hypertext Transfer Protocol (HTTP) connectivity to what looks like attacker-controlled infrastructure.

What we have: A potentially malicious URL along with an event time for when the internal host communicated with the external infrastructure.

Response steps:

1. The IR analyst searches through proxy and/or firewall logs to identify HTTP-based activity to the target URL. This activity hopefully garners the following information:
   • The internal IP address associated with the request.
   • The type of HTTP request sent to the external server (GET, POST or other).
   • The HTTP status code returned by the external server. In a perfect world, the IR analyst might find that a GET request was performed, but the response code was a 404 (not found), meaning that the action was unsuccessful. However, if a 200 (OK) was returned, the access attempt was successful.
2. The IR analyst searches through endpoint logs, such as Windows Event Logs, to determine which host the given was user using at the time of the alert
   • If configured properly (i.e. command-line auditing is enabled within the Windows environment), these logs can also specify the processes that were running on the identified host when the alert fired. While not commonly available in most company log sources, this data can help determine if general browsing activity or the presence of malware was responsible for the outbound activity.
3. Wire data can be used to determine exactly what happened during the HTTP transaction. While proxy/firewall logs may reveal the types and return responses of HTTP requests, wire data can provide the forensic-level artifacts, including the data transmitted within the external server’s response.
   • For example, let’s say the original request was a GET request. By reviewing the wire data, the IR analyst determines the exact payload that was delivered to the internal user. If such a payload were a Hypertext Markup Language (HTML) page containing code that functions as a credential harvesting ploy, the IR analyst sees exactly where the code POSTs data. Going forward, the analyst can check proxy/firewall logs for any connectivity to this particular location.
   • Depending on the use of Security Sockets Layer (SSL) within the external infrastructure, along with the potential for SSL decryption within the networked environment, the analyst might be able to see exactly what the user input into the credential harvesting form. The analyst can also discover whether or not user credentials were compromised—a serious distinction.

While our example ends here, there are many other ways to parse this data and create a clear picture. Ultimately, the role of an IR analyst is to stitch together the story using data. If a variety of data stores are not available, certain key questions may not be answered. And while capturing more data requires an extensively tiered security environment and a significant data infrastructure investment, this pays off in more data and a better response plan at your fingertips.

Wrap-up

As the number and sophistication of cyber attacks picks up pace, so should your incident response and preparation. The best IR teams have a balance of data availability, documented processes and technical know-how. In addition to staffing IR roles and developing IR processes, organizations that want to protect themselves from costly security breaches need to make available varied data sources to those working IR. Without these investments in systems and data sources, IR analysts will only have a few of the tools they need to perform their job, and shortcuts in security will result in costly cleanup after your data has been compromised.

Learn more: Hands-on incident response fundamentals