Building Operational Intelligence

Summary

The purpose of this report is to discuss the importance of Operational Intelligence (OI) in the cybersecurity industry. Operational Intelligence is the focus on gathering usable information from your own organization’s data. This report views Operational Intelligence as actionable data gathered from first hand incidents that can be used to identify organizational risks. Industry Intelligence refers to information gathered from external sources (threat feeds, open-source repositories, social media, etc.) which can be used to help search for threats within your own organization. Industry Intelligence can be thought of as, “what could happen to me” and Operational Intelligence is, “what is happening to me.” While I reference Industry Intelligence, this report is primarily focused on Operational Intelligence.

Responsibilities

Overview

Attribution

Attribution is the process of associating threats to a specific threat actor. It is important to understand that the purpose of attribution is not to find somebody to blame but, rather, to help stop or prevent attacks by identifying common tactics, techniques, and procedures used by an attacker. It's important to build your own profiles, and not rely on 3rd party profiling. This is important because it helps you group attacks against your own organization, not attacks against a lot of other organizations. These profiles can be referenced later in order to help shed light on what actions an attacker might have taken (and look for evidence there). Profiling attacks can also help an organization identify attack trends or areas of risk in order to prioritize preventative actions. Finally, attribution can be useful when other organizations are being targeted by similar threats that have not been identified on your network yet. This will allow you to review findings from those reports and compare them to your own in order to identify any missed intelligence. Part of the Operational Intelligence responsibility is to review all security incidents and attribute them to an attacker. If there are no profiles, and enough information to create one, the OI team will build the profile. It might be a good idea to place security incidents that do not have enough information in a separate group for later review.

Figure 1: Diamond Model Example

Downstream Threat

Oftentimes people try to determine how to block attacks further upstream. An email was successfully delivered, how can we block it at the firewall? While this is important and should be examined, it is equally (if not more) important to determine how to stop it further downstream. While it might be better to block an attacker further upstream, it is arguably easier to circumvent those controls. Knowing what the attack requires in order to properly execute and then blocking those actions can make it significantly more difficult for the attacker to understand (and fix) the exploit. This can make it more likely that the attacker will move on to easier targets or waste more time trying to figure out how to get in (either option is better for us).

Incident Spotlight

Some security incidents are more significant than others. Informing relevant stakeholders is necessary to keep them up-to-date with current events. Performing an in-depth analysis on more significant incidents can help people understand their value to the organization, help them learn more analysis, and also help show the full cycle of an incident.

The incident of the month should be a full report, requiring collaboration from all individuals involved in the investigation and remediation. The report should consist of:

• Summary of incident
• Timelines
• Investigation Process
• Malware Analysis Report
• Indicators
• Any (internal) victims
• Any (external) victims
• Security Gaps
• Successes

Operational Threat Summary

Once a quarter and a separate annual summary of the previous timeframe’s operational threats should be written. This report is perhaps the most critical piece of information from this team. The report should explain what attacks were seen, blocked, and detected. The Operational Threat Summary can and should be used to explain to organizational leadership the value of the cybersecurity department. This report will include the following:

• Notable Security Incidents
• Number of attacks detected
• Number of attacks blocked
• Threat Loss Potential
  • Actual cost of security incident
  • Potential cost (if security incidents had gone undetected)

Threat Loss Potential is arguably the most important piece of this report. The Threat Loss Potential section is a way for cybersecurity leaders to show the value of the cybersecurity team. While this might be challenging to collect and determine, it is crucial. Cybersecurity is often looked at as an expense on the accounting spreadsheets and value is difficult to communicate because there is no revenue produced. We can explain the theoretical costs the organization would have incurred had an incident not been prevented or stopped. This can justify the cost of cybersecurity and even allow for further budget increases by demonstrating uncovered risks to the organization.

Conclusion

Security vendors collect data from their customers environments in order to investigate, repackage, and sell that data. This means your data is somebody else’s intelligence. Knowing what is happening to others is important, but it’s just as important that you understand what is happening in your own environment. There is just too much noise to understand everything and knowing how to filter that noise using knowledge from your own environment is critical. Operational Intelligence focuses on the information you gather from your own environment and helps identify ways to secure your organization in ways that 3rd party intelligence will never be able to match.