Threat Information Sharing with Athena

The aim of this article is to provide an introduction to using structured Threat Intelligence (TI) formats, some of the challenges present (in particular with data transformation) and to share a tool MWR has developed to automate indicator exchange into multiple formats, “Athena”. This will enable organisations to make use of data they have, to better detection in a repeatable and consistent fashion using open source standards.

There is a wealth of information published on commonly used TI and TI transport standards (STIX, TAXII and CyBox) . Whereas, the challenge stems from where to start, how to use this information and gaining value from threat information. This article aims to demonstrate methods of utilising Athena to automate the collection and data export of threat information to multiple formats. This overcomes the challenge of needing to edit raw file formats such as XML and JSON and therefore is a handy tool for a multitude of scenarios in extracting and transforming Indicators of Compromise (IoCs).

Threat Intelligence remains a hot topic in the security space. There is a tendency within many organisations to mass ingest lots of information in the form of data feeds. This on its own is counterproductive, and what should be prioritised is information quality over volume to aid detection, prevention and response.

In most organisations there are likely opportunities to benefit from sharing threat information between teams, business units or globally. In organisations that have developing intelligence functions, quick value is derived from collecting artefacts from successful or unsuccessful security incidents, potentially from an incident response. This is reactive and can inform preventative measures. More advanced usage of threat information is centred on threat group tracking and attempting to proactively identify threats via their modus operandi. This enables organisations to attempt to prevent attack paths seen in the wild via procedural or technical controls. However, the output quality of advanced usage of threat information is very much dependent upon personnel having a technical understanding and keeping abreast of threats.

The benefits of information sharing, where none existed before, are:

• Improved detection and preventative measures by introducing a high confidence source of information. For example, automated incident response artefacts into a SIEM solution and preventing a reoccurrence of a confirmed attack by implementing a blocking rule at the email gateway using the detected indicators (if a phishing attack).
• Maximised value of previous findings and decreased effort of future investigations. For example, when SIEM events are correlated with response artefacts, the threat is better understood allowing for more targeted response to the risk. Likewise, a central store of incident response artefacts enables the potential for threat tracking.
• With sharing, often comes trusted relationships and the possibility of receiving quality information from similar organisations in either a manual or automated fashion. The most widely known information sharing communities are often government run. For example, the NCSC (National Cyber Security Centre) Cyber Security Information Sharing Partnership (CiSP) [1].

It is important to note, the individual act of sharing threat information has minimal value unless the information is used to better understand attacker actions. In doing so, then informing detection. For example, building low signal to noise use cases within SIEMs against threats that are applicable to an organisation.

Many organisations will at some point want to implement an information sharing mechanism between security functions in an effort to best utilise organisation specific threat information. This responsibility often sits within a threat intelligence team and takes the form of sharing Indicators of Compromise (IoC). The most valuable threat information exchanges to an organisation tend to be between a detect and response function as well as red and blue teams. For example, Incident response functions may carry out detailed forensic investigations on host and packet data which may illuminate some or all attacker IoCs. Similarly, a red team will carry out actions that will leave the same evidential material. As such, this threat information can be shared with detection teams to better understand and mitigate the risk.

The collection of IoCs can be labour intensive and therefore, there is a natural inclination toward automation using structured threat intelligence formats. Whilst, this is a good place to start, no standard can replace personnel with detailed knowledge of attacker techniques in detection. Therefore, continuous development is required to maximise the benefit from threat information exchanges. A pitfall of many information sharing standards is they do not cover every possible IoC with distinct gaps in certain parts of the kill chain. For example, a distinct lack of host persistence artefacts in the STIX format. When reviewing the different structured threat intelligence formats, it is immediately apparent that the standards and their associated functionality are extensive. This can be daunting as there isn’t an obvious place to start.

There are a number of indicator sharing frameworks, such as: STIX/Cybox (Structured Threat Information eXchange/ Cyber Observable eXpression), OpenIOC and IODEF (Incident Object Description Exchange Format). MWR chose to use STIX/Cybox because the data model met requirements, specifically an extensive set of functionality within the data model that describes incident details and their related artefacts. Its wide usage within private and public sector also enables efficient sharing of technical intelligence with external sharing partners.

STIX is a language and serialisation format for the consistent, machine readable exchange of cyber threat intelligence [2]. Cybox is the functionality underpinning the language and defines the structured representations for observable objects and their properties within a network, for example, descriptions of technical artefacts like: domains, IP addresses, and file objects. The final component to the standard is TAXI (Trusted Automated eXchange of Indicator Information) which is an application layer protocol for the communication of cyber threat information. This is the API (Application Programming Interface) for the standard.

The STIX/Cybox data model covers 8 core “concepts” that a cyber incident could be decomposed to. Many of these core concepts delve into complex uses for threat information such as: tracking threat actors, malware campaigns and deriving indicators to determine their detection. However, not every organisation will have the desire or need to carry out these activities. As such, the simplest usage of threat information is to convey information about a cyber security incident seen in your own environment.

In a typical incident response or event detection, security personnel will naturally collect information about the host, network specifics and log information that would prove a malicious act has occurred, how it occurred and where possible, produce a chain of events. STIX terms this as an “incident” and an incident has related technical artefacts which are termed as “observables”. A further useful insight from security incidents are the attacker actions and is termed a “TTP” in STIX. All of these concepts have a consistent XML structure by which they are recorded and stored.

It is important to understand what outcomes an organisation hopes to see from threat information sharing and ensure that the necessary “STIX concepts” are included. This exercise should be focussed on low volume, high confidence data and then automating its package and transmission using the standard. In the case of organisations wishing to share information between response and detect teams, the value received from storing and correlating IoCs will often be minimal, as the chances of the same artefacts being used has a low probability for anything other than commodity threats. The true value from maintaining a repository of high confidence artefacts comes in utilising them to understand attacker actions and implementing effective detection cases to alert or highlight suspicious activity applicable to the organisation environment. For example, building low signal to noise use cases within SIEMs. Condensing the STIX concepts down to enabling threat information exchange between detect and response teams can be summarised below:

• Incident (and its related Observables) – This is an incident response report with structured handling of the technical artefacts.
• TTP (Tactics, Techniques and Procedures) – A useful concept to security analysts and detective functions in attempting to understand attacker behaviour in a structured fashion.

Utilising only the appropriate data model components and their underlying Cybox functionality drastically cuts down the scope of effort, yet still allows sufficient context to be seen by security analysts if an incident observable is detected on a monitored estate.

Understanding the data requirements within any organisation should inform whether threat information sharing is relevant to an organisation and by proxy, determine whether Athena can be used to part automate the process. Athena was produced to automate the production process of STIX Incidents (and related observables) and to transform this threat data to formats wider than STIX, in particular to JSON.

Whilst Athena can be used as a standalone application by any security team, it is best used or incorporated with a TI process and not ad-hoc packaging of indicators. Therefore, there are a few important decisions that need to be considered:

• Will an information repository be used to store indicators?
• Is there a natural progression to external information sharing?

Athena automates the output of a structured sharing standard (STIX, JSON) but doesn’t dictate how this is shared or communicated. Therefore, it is important to have a mechanism in place (automated or manual) that enables the output to be shared effectively. This is often solved by maintaining a threat information store, usually a web application linked to a database and an API. Examples of such platforms are: Creative Research into Threats (CRITS) , Soltra Edge  and Malware Information Sharing Platform (MISP) . MWR chose to use MISP because of its open source extensible nature and API. Therefore, Athena also outputs into MISP JSON.

Whilst having a centralised store of threat information is important to explore more complex threat information usage such as threat group tracking. It can add shorter term value. For example, an unforeseen advantage, was a reduction in time IR required to submit to the Verizon DBIR utilising the MISP API. A central repository will likely aid in process automation as well as detection benefits.

One of the benefits of information sharing is the potential to receive it from other high confidence sources. Therefore, willingness to share indictors with a select or open set of organisations is beneficial to both detection but also industry in raising the bar against threat actors. The benefit of utilising an information repository is that they often come inbuilt with a TAXI server which is the STIX transport mechanism. This allows easy retrieval and dissemination with selected parties.

The primary motivator for producing Athena was the fact that editing raw XML and debugging it whilst carrying out an incident response is tedious and cumbersome. Furthermore, there was a distinct lack of open source tooling that would flexibly handle a basic set of IoCs and output them into a variety of formats to make them shareable across platforms.

MWR currently uses Athena within IR such that: an investigator can carry out host and network forensics, extract the unique IoCs, input the IoCs into Athena and export a structured set of information that can be ingested by MISP. The output is a structured artefact handling document focused on the minimum required to derive situational context from the incident at the time. Therefore, it should not replace the detailed IR report. These findings are then used to enrich Countercept, MWRs threat hunting service.

Here we have outlined the benefits of sharing threat information between the various interested entities within teams and organisations, as well as within the security community as a whole. While many standards are available, their varied formats are complex in nature and create barriers to the effective creation and sharing of IoCs, particularly those arising from specific security incidents.

The hope is that sharing this tool will empower others to create their own IoCs to share within their teams and the wider community. In doing so, learn from attacker behaviours to enrich their own detection teams.

We welcome any feedback, suggestions or contributions to our developmental roadmap.

There is an overview for Athena and a link to the source code via the MWRLabs Github.