+ All Categories
Home > Documents > Enriching Threat Intelligence Platforms Capabilities

Enriching Threat Intelligence Platforms Capabilities

Date post: 12-Apr-2022
Category:
Upload: others
View: 1 times
Download: 0 times
Share this document with a friend
12
Enriching Threat Intelligence Platforms Capabilities Mario Faiella 1 , Gustavo Gonzalez-Granadillo 1 , Ib´ eria Medeiros 2 , Rui Azevedo 2 , and Susana Gonzalez-Zarzosa 1 1 Atos Research & Innovation, Cybersecurity Laboratory, Spain {mario-ferdinando.faiella, gustavo.gonzalez susana.gzarzosa}@atos.net 2 LASIGE, Faculty of Sciences, University of Lisboa, Portugal [email protected], [email protected] Keywords: Threat Intelligence Platforms, Open Source Intelligence (OSINT), Data Enrichment, MISP, Threat Score Abstract: One of the weakest points in actual security detection and monitoring systems is the data retrieval from Open Source Intelligence (OSINT), as well as how this kind of information should be processed and normalized, considering their unstructured nature. This cybersecurity related information (e.g., Indicator of Compromise - IoC) is obtained from diverse and different sources and collected by Threat Intelligence Platforms (TIPs). In order to improve its quality, such information should be correlated with real-time data coming from the moni- tored infrastructure, before being further analyzed and shared. In this way, it could be prioritized, allowing a faster incident detection and response. This paper presents an Enriched Threat Intelligence Platform as a way to extend import, quality assessment processes, and information sharing capabilities in current TIPs. The plat- form receives structured cyber threat information from multiple sources, and performs the correlation among them with both static and dynamic data coming from the monitored infrastructure. This allows the evaluation of a threat score through heuristic-based analysis, used for enriching the information received from OSINT and other sources. The final result, expressed in a well defined format, is sent to external entities, which is further used for monitoring and detecting incidents (e.g., SIEMs), or for more in-depth analysis, and shared with trusted organizations. 1 Introduction The number and the impact of cyber attacks has dras- tically increased during the last years, as revealed by reports written by governments and companies, espe- cially in terms of how much these threats could harm them from an economical point of view. The Council of the Economic Advisers of the United States 1 esti- mated that malicious cyber activity had an economic impact in the U.S. economy between 57 billion and 109 billion dollars in 2016 (CEA, 2018). Cyberse- curity Ventures 2 identified cyber crime as the ”great- est threat to every company in the world”, predicting that it will cost the world more than six trillion dol- lars annually by 2021 (Ventures, 2017). Moreover, the global management consulting firm Accenture 3 , during a study conducted in 2017 (Accenture, 2017), affirmed that cyber crime, on an annual average, is 1 https://whitehouse.gov/cea/ 2 https://cybersecurityventures.com/ 3 https://www.accenture.com/ costing organizations 11.7 million dollars, more or less 23 percent more than the previous year. These successful incursions potentially allow groups of at- tackers to acquire valuable intellectual properties and secrets. With the aim of facing these menaces, it is crucial to have timely access to relevant, accurate in- formation about them, for protecting precious internal and sensitive data as well as critical assets. Collecting and processing Open Source Intelli- gence (OSINT) information is becoming a fundamen- tal approach for obtaining cybersecurity threat aware- ness. Recently, the research community has demon- strated that useful information and Indicators of Com- promise (IoC) can be obtained from OSINT (Liao et al., 2016; Sabottke et al., 2015). Besides the re- search oriented efforts, all Security Operation Centre (SOC) analysts get updated about new threats against their IT infrastructures by collecting and analyzing cybersecurity OSINT data. Nevertheless, skimming through various news feeds is a time-consuming task for any security analyst.
Transcript
Page 1: Enriching Threat Intelligence Platforms Capabilities

Enriching Threat Intelligence Platforms Capabilities

Mario Faiella1, Gustavo Gonzalez-Granadillo1, Iberia Medeiros2, Rui Azevedo2, and SusanaGonzalez-Zarzosa1

1Atos Research & Innovation, Cybersecurity Laboratory, Spain{mario-ferdinando.faiella, gustavo.gonzalez susana.gzarzosa}@atos.net

2LASIGE, Faculty of Sciences, University of Lisboa, [email protected], [email protected]

Keywords: Threat Intelligence Platforms, Open Source Intelligence (OSINT), Data Enrichment, MISP, Threat Score

Abstract: One of the weakest points in actual security detection and monitoring systems is the data retrieval from OpenSource Intelligence (OSINT), as well as how this kind of information should be processed and normalized,considering their unstructured nature. This cybersecurity related information (e.g., Indicator of Compromise -IoC) is obtained from diverse and different sources and collected by Threat Intelligence Platforms (TIPs). Inorder to improve its quality, such information should be correlated with real-time data coming from the moni-tored infrastructure, before being further analyzed and shared. In this way, it could be prioritized, allowing afaster incident detection and response. This paper presents an Enriched Threat Intelligence Platform as a wayto extend import, quality assessment processes, and information sharing capabilities in current TIPs. The plat-form receives structured cyber threat information from multiple sources, and performs the correlation amongthem with both static and dynamic data coming from the monitored infrastructure. This allows the evaluationof a threat score through heuristic-based analysis, used for enriching the information received from OSINTand other sources. The final result, expressed in a well defined format, is sent to external entities, which isfurther used for monitoring and detecting incidents (e.g., SIEMs), or for more in-depth analysis, and sharedwith trusted organizations.

1 Introduction

The number and the impact of cyber attacks has dras-tically increased during the last years, as revealed byreports written by governments and companies, espe-cially in terms of how much these threats could harmthem from an economical point of view. The Councilof the Economic Advisers of the United States1 esti-mated that malicious cyber activity had an economicimpact in the U.S. economy between 57 billion and109 billion dollars in 2016 (CEA, 2018). Cyberse-curity Ventures2 identified cyber crime as the ”great-est threat to every company in the world”, predictingthat it will cost the world more than six trillion dol-lars annually by 2021 (Ventures, 2017). Moreover,the global management consulting firm Accenture3,during a study conducted in 2017 (Accenture, 2017),affirmed that cyber crime, on an annual average, is

1https://whitehouse.gov/cea/2https://cybersecurityventures.com/3https://www.accenture.com/

costing organizations 11.7 million dollars, more orless 23 percent more than the previous year. Thesesuccessful incursions potentially allow groups of at-tackers to acquire valuable intellectual properties andsecrets. With the aim of facing these menaces, it iscrucial to have timely access to relevant, accurate in-formation about them, for protecting precious internaland sensitive data as well as critical assets.

Collecting and processing Open Source Intelli-gence (OSINT) information is becoming a fundamen-tal approach for obtaining cybersecurity threat aware-ness. Recently, the research community has demon-strated that useful information and Indicators of Com-promise (IoC) can be obtained from OSINT (Liaoet al., 2016; Sabottke et al., 2015). Besides the re-search oriented efforts, all Security Operation Centre(SOC) analysts get updated about new threats againsttheir IT infrastructures by collecting and analyzingcybersecurity OSINT data. Nevertheless, skimmingthrough various news feeds is a time-consuming taskfor any security analyst.

Page 2: Enriching Threat Intelligence Platforms Capabilities

Furthermore, analysts are not guaranteed to findnews relevant to the IT infrastructure they oversee.Tools are therefore required, not only to collect OS-INT, but also to process it, aiming at enhancing thequality of the information carried on OSINT to SOCanalysts, for instance, to benefit from the potentialthey have. In addition, such tools must filter only therelevant parts for the SOC analysts, thus decreasingthe amount of information and consequently, the timerequired to analyze it and act upon. When appropri-ate, the filtered information must be further processedto extract IoCs.

Moreover, a proper quality assessment is needed,to check if gathered data can be considered as valu-able Threat Intelligence (denoted as TI). Sillaber et al.(Sillaber et al., 2016) identified TI quality evaluationas one of the main challenges in actual cybersecurityinformation sharing scenarios, mainly caused by thelimitation of existing TI sharing tools, as well as thelack of suitable and globally recognized standards andontologies (Mavroeidis and Bromander, 2017). Theseassessment processes can provide more insights forinferring the impact that some cyber attacks couldhave with respect to internal assets and resources, pri-oritizing threat detection and incident response.

In addition, the ability to share OSINT informa-tion is often not enough. TI must be expressed, andthen, shared using specific standards, allowing in-volved parties to speed up processing and analysisphases of received information, achieving interoper-ability among them.

In this paper we propose an Enriched Threat Intel-ligence Platform, (hereinafter denoted as ETIP), aim-ing at extending import and information sharing capa-bilities of internal detection and monitoring systems(e.g., SIEMs) improving also quality assessment ofreceived cybersecurity events.

The final objective is to integrate the relevant se-curity data coming from public sources (e.g., socialnetworks), after going through a quality informationenhancing process, with data gathered from the in-frastructure through specific detection and monitor-ing systems (e.g., SIEMs, IDS, IPS), to anticipate andimprove threat detection and incident response. Thisintegration has been defined as a crucial activity inorder to produce real and valuable TI (Skopik et al.,2016).

In this context, on one hand, it arises the need of acomponent that relates and aggregates collected OS-INT data, generating thus new enriched data. On theother hand, it also requires a component that consid-ers potential security issues in the monitored infras-tructure, to be correlated with the received OSINTdata, providing a threat score for the latter that helps

to identify its relevance and priority.This threat score will complement the usage of

static information about the monitored infrastructurewith dynamic and real-time threat information re-ported from inside the own monitored infrastructurein the way of IoCs. This dynamic evaluation is basedon heuristic analysis which allows determining thepriority of the incoming OSINT data, by assigninga threat score to it. The produced object integratingthe information received from OSINT data sourcesthrough its calculated threat score is sent directly toother security systems and tools (e.g., SIEMs) for vi-sualization, storage, processing, or feedback and, op-tionally, could also be shared with external trusted or-ganizations.

The remainder of this paper is structured as fol-lows: Section 2 presents related works, while Section3 introduces and compares threat intelligence plat-forms. Section 4 describes the architecture of our pro-posed Enriched Threat Intelligence Platform (ETIP).Section 5 details the Threat Score Evaluation processand Section 6 illustrates the applicability of our ap-proach with a use case scenario and preliminary re-sults. Finally, conclusions and perspective for futurework are presented in Section 7.

2 Related Work

Several standard formats have been proposed to fa-cilitate cyber intelligence sharing among platforms.Examples of such formats are the Open Indicatorsof Compromise (OpenIoC4), Structured Threat Infor-mation eXpression (STIX5), Trusted Automated eX-change of Indicator Information (TAXII6).

Few studies of existing threat intelligence plat-forms (TIPs) have been identified. Tounsi and Rais(Tounsi and Rais, 2018) provides a survey about opensource threat intelligence platforms, including theMalware Information Sharing Platform (MISP)7, theCollective Intelligence Framework (CIF)8, the Col-laborative Research Into Threats (CRITs)9, and SoltraEdge10. Sauerwein et al. (Sauerwein et al., 2017),provide an exploratory study of software vendors and

4https://www.darknet.org.uk/2016/06/openioc-sharing-threat-intelligence/

5https://oasis-open.github.io/cti-documentation/stix/intro

6https://oasis-open.github.io/cti-documentation/taxii/intro

7http://www.misp-project.org8https://csirtgadgets.com/collective-intelligence-

framework9https://crits.github.io/

10https://www.soltra.com/en/

Page 3: Enriching Threat Intelligence Platforms Capabilities

research perspectives of threat intelligence sharingplatform, and conclude that the market for threat in-telligence sharing is still developing. Moreover, alsoENISA provides an updated report about opportuni-ties and limitations of actual TIPs (ENISA, 2017),suggesting various guidelines that should be followedfor overcoming them.

Owen (Owen, 2015) proposes Moat, a powerfultool that covers known bad actors and consume datafrom multiple sources such as vulnerability systemsand port scanners. Moat has been integrated withSIEMs using STIX and XML formats for sharing pur-poses but it is not yet defined for other well-knownstandards such as TAXII.

Some commercial SIEMs (e.g., LogRhythm11)have added security intelligence to its SIEMs andanalytic platforms. Their approach uses rich con-text enabled by threat intelligence from STIX/TAXII-compliant providers, commercial and open-sourcefeeds, as well as internal honeypots. As a result, theplatform uses these data to reduce false-positives, de-tect hidden threats, and prioritize concerning alarms.

To the best of our knowledge, more research isneeded about threat intelligence sharing platforms,and their integration with other security tools. Ourapproach suggests the use of a platform for collect-ing and aggregating cyber security related informa-tion from OSINT, relying on MISP for storing andmanaging the resultant IoCs, which will be furtherenriched with a threat score, for prioritizing possibledefence actions. The outcome of this platform willfeed systems, like SIEMs and IDS, with actionableinformation that will improve the detection of cyberthreats, and could also be shared, in an automatedway, with internal SOCs and CSIRTs, as well as withother trusted organizations.

3 Threat Intelligence Platforms

Many companies started relying on Threat Intelli-gence Platforms (TIPs) for overcoming gaps and lim-itations of actual detection and monitoring systems,especially SIEMs (ThreatConnect, 2018). They are incharge of retrieving structured and unstructured datafrom diverse external sources, and perform variouscomplex operations, such as filtering, aggregation,normalization, detection, analysis and enrichment, aswell as the injection of results into SIEMs. However,their implementation and usage are still in their in-fancy and, as stated in (Sauerwein et al., 2017), manydrawbacks have to be addressed, for instance, in termsof dynamic trust assessment of external sources and

11https://logrhythm.com

advanced analysis capabilities, where manual work isstill needed, especially for making the retrieved infor-mation effectively actionable.

TIPs are ideal tools for data collection, storage,sharing, and for integration with external entities, thatcould be other security platforms and tools, as wellas specific groups for handling incident response andthreat management (e.g., SOC, CSIRTs). SeveralTIPs are available in the market (most of them undercommercial license). In terms of open-source solu-tions, we have identified the following:

1. The Malware Information Sharing Platform(MISP),

2. The Collective Intelligence Framework (CIF),

3. The Collaborative Research Into Threats (CRITs),and

4. SoltraEdge (SE), but only a limited version isavailable with this kind of license.

The comparison among them is summarized in Ta-ble 1, and has been performed taking into accountthe following criteria, mainly based on the study con-ducted by Tounsi et al. (Tounsi and Rais, 2018), to-gether with some personal considerations, especiallyabout hardware requirements:

• Import/Export format: MISP and CRITs areable to work with a great number of formats(e.g., PDF, doc, xls, txt, JSON, XML, STIX).MISP supports an ad-hoc standard for represent-ing Threat Intelligence (a customized JSON12

format), and basic built-in capabilities for STIXv.2.013 conversion. It also allows adding modulesfor ad-hoc importing/exporting without modify-ing the core functionalities. CIF is not as flex-ible as the previous two TIPs, especially if spe-cific standards (e.g., STIX) will be considered,while the free and limited version of SoltraEdgepresents some limitations when dealing with non-STIX data.

• Integration with/Export to standard securitytools: MISP allows an easy interaction with In-trusion Detection Systems (IDSs) and SIEMs, andcontains flexible REST APIs for integrating inter-nal solutions with the platform. CIF is also a vi-able platform to integrate with IDS and SIEMs,although less flexible than MISP. CRITs is a hugerepository of TI, not specifically built for interact-ing with systems such as SIEMs and IDS, how-ever its flexibility allows building ad-hoc solu-

12JavaScript Object Notation, https://www.json.org13https://oasis-open.github.io/cti-

documentation/stix/intro

Page 4: Enriching Threat Intelligence Platforms Capabilities

tions for these purposes. The free SoltraEdge ver-sion has many limitations, especially in terms ofAPI support for interacting with other platforms.

• Support of collaboration: MISP allows central-ized support, by sharing the same instance amonga trusted community; and decentralized support,when multiple instances interact in a peer-to-peer way. CIF allows the usage of a private in-stance and the implementation of a shared in-stance through a centralized service. CRITs andSoltraEdge allow the usage of a private instance,or a shared one in the context of a trusted com-munity. However, CRITs has very poor built-insharing capabilities.

• Data Exchange Standards: MISP and CRITsare able to deal with many different standards, in-cluding STIX and TAXII. The limited version ofSoltra-Edge has very poor capabilities to deal withstandards different to STIX and TAXII. CIF, hasbeen designed to work with other CIF instancesusing private solutions for meeting high perfor-mance requirements with partial or no support onstandards such as STIX and TAXII.

• Analysis capabilities: high analysis capabilitiesis a weakness for all current TIPs (Sauerweinet al., 2017). CRITs and SoltraEdge are huge cen-tral repositories for collaborating analysis ratherthan pure sharing platforms. They have betterbuilt-in analysis capabilities compared to MISPand CIF. However, this advantage is partially lostwith the limited version of SoltraEdge.

Table 1: Comparison of Threat Intelligence Platforms

Evaluated Criteria MISP CIF CRITs SEImport/Export Format • ◦ • −Integration Capabilities • • ◦ ◦Data Exchange Std. • ◦ ◦ ◦Support of Collaboration • • ◦ ◦Analysis Capabilities ◦ ◦ • ◦Graph Generation ◦ ◦ • ◦License • • • ◦Hardware Requirements • − • •−Low/Basic ◦Medium/Average • High/Advanced

• Graph generation: visualization capabilities arestrictly related to the analysis of the aforemen-tioned features, and the same consideration can bededucted. More generically, this is another limi-tation of current TIPs (Sauerwein et al., 2017).

• License: all TIPs considered in this analysis (in-cluding the limited version of SoltraEdge) are re-leased with open source licenses.

• Hardware requirements: MISP, CRITs andSoltraEdge have very similar requirements interms of RAM and hard disk size needed. CIF, in-stead, has higher requirements, especially in termsof processing capabilities.Due to its ability to be integrated with SIEMs and

IDSs; its high flexibility features for integrating inter-nal and custom solutions; the support of specific dataexchange standard, such as STIX, as well as goodbuilt-in information sharing capabilities; the avail-ability of a very detailed on-line documentation14;and a huge and responsive on-line community, in caseof development issues; the selected threat intelligenceplatform is the MISP.

4 Enriched Threat IntelligencePlatform Architecture

The Enriched Threat Intelligence Platform (ETIP)is composed of two main modules: (i) the ComposedIoC Module, and (ii) the Context Aware IntelligenceSharing Module as shown in Figure 1.

OSINT Feeds

Context Aware Intelligence Sharing Module

Infrastructure and OSINT

Data

External Entities (i.e., SIEMs, CSIRTs, SOCs, …)

MISP Instance

Heuristic Module

DB

Enriched Threat Intelligence Platform (ETIP)

TIPsIoCs Aggregating

Process

Composed IoC Module

single IoCs

Composed IoCs

Enriched IoCs

Figure 1: Enriched Threat Intelligence Platform architec-ture.

While the first module collects several securityevents (i.e., IoCs) provided from different OSINTfeeds, and then interrelates them, generating thusIoCs with more information – composed IoCs –, thesecond module receives these composed IoCs andcorrelates them with information provided by securitytools deployed in the organization network infrastruc-ture. Applying a heuristic analysis to these data, theresulting IoC can be further enriched, providing moreinsights about how much the incoming informationcould be considered as real intelligence by the enter-prise.

14https://www.circl.lu/doc/misp/book.pdf

Page 5: Enriching Threat Intelligence Platforms Capabilities

4.1 Composed IoC Module

We propose a component to generate composed IoCs,i.e., for collecting different IoCs from different TIPs,correlating them, and then, generating new composedIoCs. The architecture of the component is repre-sented in Figure 2. The main parts are the following:

OSINTFeed 1

OSINTFeed n

TIP1 TIP2

TIPm…

Collector

IoC NormalizerIoCs

ComposedIoCs

Deduplicator

IoC Aggregator

Figure 2: Composed IoC Module Architecture.

• OSINT Feeds. Open source intelligence informa-tion regarding to security events, such as cyber-attacks, exploitation of software vulnerabilities,malware domains, IP blacklists.

• TIPs. Different TIPs are used in parallel to collectseveral OSINT data provided from diverse feeds,which take advantage of the enrichment capabil-ities they offer, such as improving OSINT threatintelligence with external data not included in OS-INT feeds (e.g., asn source, whois).

• Collector. The output of the different TIPs, as aform of IoCs, is channelled to a collector module.The TIP’s IoCs are seen as OSINT feeds but in anIoC format (e.g., STIX, MISP format).

• IoC Normalizer. Since IoCs might be collectedin different formats (depending on the formatadopted by TIPs), it is necessary to normalizethem in a single and common format (e.g., MISPformat). After this process, they are stored in adatabase to be processed by the component.

• Deduplicator. IoCs received from different TIPscan be equals, since TIPs can be configured withthe same OSINT feeds. The deduplicator mod-ule analyzes the received IoCs with those alreadyexist in the database with the aim to identify du-plicated IoCs and remove them before being pro-cessed by the IoC aggregator module.

• IoC Aggregator. Aggregates different but re-lated IoCs, and generates new ones. The pro-cess consists on identifying IoCs that contain rel-evant interrelated information, aggregating themin a same set, and then, merging that informationinto a single IoC, creating a new IoC that we callcomposed IoC. These new IoCs are stored in thedatabase for later be used by the context awarethreat intelligence component (see Section 4.2).

4.1.1 Implementation

The proposed component was implemented using theMISP platform, for which the deduplicator and aggre-gator modules were developed in Python 3, and inte-grated in MISP. This latter acts as the collector andIoC normalizer to receive and normalize the data thatcan be provided from different TIPs, and then uses thedeveloped modules to process the received data.

The component offers to the end user the possi-bility of configuration based on two criteria: (1) thetrust level of the IoC assigned by the MISP commu-nity, where, for example, an IoC with level 2 meansthat IoC has the trustiest level of confidence and itsinformation is relevant; (2) the interrelation type be-tween IoCs which will be considered by the IoC ag-gregator module. This interrelation can be based onIoC as a whole or their attributes, which the formeronly allows interrelations between IoCs that belongto the same threat category, whereas the latter permitsa most deep analysis and connection between IoCs,allowing to generate new data provided by IoCs ofdifferent categories (e.g., IoCs belonging to the MISPnetwork category and from type of vulnerability).

IoC 0 (76)

IoC 1.A (32)

IoC 1.B (74)

IoC 1.C (46)

IoC 1.D (51)

IoC 2.B (71)

IoC 3.A (102)

IoC 2.A (16)

OSINT Feed 1 OSINT Feed 2 OSINT Feed 3

Figure 3: Schematic for the creation of a composed IoC

The component considers dividing the OSINTfeeds in two categories: (1) low level feeds, whichconsist mainly of IP addresses and URLs; and (2) highlevel feeds, which contain a more advanced analysiswith information about network artifacts, campaigns,etc.; that feed TIPs (e.g., CRIT, MISP). It performsqueries to the database to identify new entries andother entries that have matches, and then merge themforming a new IoC and inject it into the database,

Page 6: Enriching Threat Intelligence Platforms Capabilities

which is labelled with a tag that allows identifyingit as a rich IoC and avoids the creation of loops.

Figure 3 exemplifies a composed IoC. In the fig-ure, starting from an IoC that contained 76 elements,we were able to identify 7 other IoCs, originatingfrom 3 distinct OSINT feeds, that were correlated.The merging of these IoCs allowed the creation of anew IoC containing 468 elements.

4.2 Context Aware Intelligence SharingModule

The context aware intelligence sharing module is ableto correlate static and real-time information (e.g., In-dicators of Compromise), related to the monitoredinfrastructure, with data coming from external OS-INT sources through OSINT data fusion and analy-sis tools, to check the relevance and accuracy of thedata. Furthermore, the module is also able to shareboth the original and the enriched information withexternal entities, in an automated way.

The proposed module architecture, depicted inFigure 4, is composed of two main elements: (i) aMISP Instance, in charge of gathering data from bothOSINT-based sources and the monitored infrastruc-tures, as well as sending the enriched IoCs to inter-nal components, systems and tools (e.g., SIEMs) orsharing them with trusted organizations; and (ii) theHeuristic Component, in charge of performing theheuristic analysis, with the final aim of computing aThreat Score, enriching the data coming from OSINT-based sources, and sending it back to the MISP In-stance.

Input Data

OSINT Data Collector

MISP Database

Infrastructure Data Collector

HeuristicDatabase

Heuristic Engine

Threat Score Agent

MISPInstance

Heuristic Component

External Entities (i.e., SIEMs, CSIRTs, SOCs, …)

Figure 4: Context Aware Intelligence Sharing Module

4.2.1 MISP Instance

From Figure 4, the OSINT and Infrastructure data col-lectors are responsible of capturing useful data fromOSINT, IoCs and the infrastructure in order to eval-uate a set of pre-defined heuristics and to compute a

threat score. Collected OSINT data are stored in theMISP Database, whereas collected infrastructure dataare stored in the Heuristic Component Database.

The integration between security tools, as well asinternal SOC and CSIRTs, and the context aware in-telligence sharing module is possible thanks to theadoption of MISP. The objective is to use, as much aspossible, the built-in sharing capabilities of the plat-form when this interaction takes place, such as a ze-roMQ publish-subscribe model15. MISP comes withso-called “MISP-modules”, used both for ad-hoc im-port and export of threat information. If required, newmodules could be created from scratch and integratedwith the MISP Instance, without modifying the corefunctionalities of the platform.

The heuristic component receives all data com-ing from the monitored infrastructures, through MISP.Data could be dynamic (e.g., IoC detected in the in-frastructures) or static and generic information abouta specific infrastructure (e.g., used sensors, operat-ing systems, specific lists of IP addresses). Thesedata are stored in the MISP database, representedthrough the JSON format (e.g., STIX, MISP events),or through simple documents related to generic in-formation. Since its usage is of great interest tothe heuristic component, data could be also storedin a different way, using for instance a private non-relational database such as MongoDB16, which sim-plifies the information retrieval by the heuristic engineand allows for a full control of the analysis performedby the tool.

The adoption of MISP makes it possible to auto-matically share data with external entities thanks toits built-in information sharing capabilities. For thosecases in which the external entity is using a MISPinstance, the sharing process is performed by sim-ply synchronizing both instances. Otherwise, MISPcomes with a list of REST APIs, which are accessedfrom any internal and external services with differ-ent levels of access rights, to directly interact with itsdatabase, to push/pull cyber-security related events.

4.2.2 Heuristic Component

The heuristic component receives information com-ing from multiple sources (e.g., OSINT data, infras-tructure, IoCs, etc.) to be used in the Threat Score(T S) analysis performed by the heuristics engine.This latter considers a set of conditions that are eval-uated for every single feature. A score is assigned toevery feature (i.e., individual score). The sum of all

15http://zeromq.org/16https://www.mongodb.com/

Page 7: Enriching Threat Intelligence Platforms Capabilities

individual scores results into the Threat Score associ-ated to the data being analyzed.

The database from the heuristic component storesthe information of the infrastructure and the OSINTdata collector. The Threat Score Agent is responsi-ble for the generation of the resulting enriched In-dicator of Compromise (eIoC), including the ThreatScore for the security information received from OS-INT data sources. The eIoCs shared by this compo-nent includes the same information received from OS-INT, as well as the associated Threat Score and thefeatures considered in the evaluation.

5 Threat Score (TS) Evaluation

The threat score evaluation is part of the heuris-tic component that uses a threat score function (de-tailed in Section 5.1) to compute the relevance ofthe received data. The process performs an analysismethodology composed of the following steps:

1. Source Identification: during this phase wesearch and identify all possible sources of infor-mation. Examples of these sources are: securitylogs, databases, report data, OSINT data sources,IoCs, etc.

2. Heuristics Identification: different features(e.g., heuristics) are identified from the inputdata. Such features provide relevant informa-tion about the infrastructure (e.g., vulnerabilities,events, faults, errors, etc.) useful in the threatanalysis and classification process. Examples ofheuristics are: CVE, IP source, IP destination,port source, port destination, timestamp, etc.

3. Threshold Definition: for each heuristic, mini-mum and maximum possible values are definedbased on characteristics associated to the instance.We checked, for instance, if the input data con-tains or not a CVE for the detected threat. Athreshold (e.g., 0-5) is assigned to cover all pos-sible results.

4. Score Computation: for each possible instanceof the identified heuristic, a score value is as-signed based on expert knowledge. All individ-ual scores are then aggregated and a final score iscomputed. The resulting value will indicate thepriority and relevance of the security informationcoming from OSINT data sources and the moni-tored infrastructure.

5. Training Period: a set of preliminary tests needto be performed during a training process to eval-uate the performance of the engine. The tests in-

clude real data to analyze the score obtained indi-vidually (for each heuristic) and globally (for thewhole event) which help to analyze false positiveand negative rates.

6. Engine Calibration: in order to minimize devia-tions (e.g., reduce number of false positive, falsenegative) the engine must be calibrated by analyz-ing the obtained results, adding other heuristicsand/or modifying the assigned values to currentattributes.

7. Final Tests: Once the engine is calibrated, we canrepeat previous tests or add new ones in order toevaluate the performance of the tool.

5.1 Threat Score Function

The heuristics-based threat score is composed of a setof individual scores as a complement of other pre-diction tools to indicate the priority and relevanceof incoming security information received from OS-INT and infrastructure data sources. There exists alarge number of different aggregation operators (e.g.,Arithmetic Mean, Geometric Mean, Harmonic Mean,Weighted Mean, Ordered Weighted Averaging) (Ra-vana and Moffat, 2009; Torra and Narukawa, 2007)that can be used for the computation of the threatscore. They differ on the assumptions about the data(data types) and the type of information that we canincorporate in the model.

From the aforementioned aggregation operators,the Weighted Mean (WM) is the selected function tocompute the threat score, due to the following ad-vantages: (i) simple and straightforward function; (ii)avoids indeterminate results and/or null values; (iii)can be used if one or more individual scores are zero;and (iv) individual scores are assumed to have differ-ent weights depending on the source and the relevanceof the information.

The proposed Threat Score (T S) is defined as thesum of all individual heuristic values (Xi) times itscorresponding weight factor (Pi). This latter considersmultiple criteria (e.g., relevance, accuracy, timeliness,variety). The sum is then affected to the completenessparameter (Cp), as shown in Equation 1.

T S =Cp×

(t

∑i=1

Xi×Pi

)(1)

The resulting T S ranges from zero to five (0 ≤T S ≤ 5), the higher the TS value, the more reliablethe IoC. Thus, a T S with a value between zero and one(0 ≤ T S ≤ 1) indicates a Very Low level of priority;a T S with a value between one and two (1≤ T S ≤ 2)

Page 8: Enriching Threat Intelligence Platforms Capabilities

indicates a Low level of priority; a T S with a value be-tween two and three (2≤ T S≤ 3) indicates a Mediumlevel of priority; a T S with a value between threeand four (3 ≤ T S ≤ 4) indicates a High level of pri-ority; and a T S with a value between four and five(4≤ T S≤ 5) indicates a Very High level of priority.

5.2 Heuristic Value

The first part of the (T S) function refers to the valueassigned to a given heuristic (Xi) based on the typeof information processed during the evaluation. Con-sidering, for instance, that one of the features to beevaluated is the presence of a Common VulnerabilityExposure (CVE)17 identified in the input data, the en-gine will check if the word CVE appears in the inputdata in order to retrieve the complete CVE number(i.e., CVE-AAAA-NNNN).

If a CVE is found, the engine checks for itsassociated Common Vulnerability Scoring System(CVSS)18. More specifically, the engine will searchfor its associated base score, which considers accessvector, access complexity, authentication, and impactrelated information based on availability, confiden-tiality and integrity. Depending on the CVSS score,the vulnerability is labeled as none, low, medium,high or critical, as shown in Table 2.

Table 2: Common Vulnerability Score System (CVSS) v3Ratings

Severity None Low Med High CriticalLower Bound 0.0 0.1 4.0 7.0 9.0Upper Bound 0.0 3.9 6.9 8.9 10.0

Source:https://www.first.org/cvss/specification-document

Each evaluated feature is assigned an individualscore based on the defined threshold (e.g., from 0 to5) that will indicate the level of impact of the fea-ture with respect to the event. We define the variable“Score CVE” that will compute the individual scorevalue assigned to the presence of a CVE in the inputdata based on the conditions described in Table 3.

Other features (e.g., source/Destination IP, cre-ation and validity timestamps, etc.) may use posi-tive and/or negative values in the assignment process.Such individual values are then tuned in the trainingand calibration processes so that the final threat scorereduces the number of false positives and negatives.

17https://www.mitre.org18https://www.first.org/cvss/specification-document

Table 3: Examples of Individual Threat Score

Criteria Condition ScoreNo CVE If CVE == ” 0CVE exists withCVSS ‘none’ or0.0

If CVE 6= ” &CVSS = ‘none’ |CVSS = 0.0

1

CVE exists withCVSS ‘low’ orless than 4.0

If CVE 6= ” &CVSS = ‘low’ |CVSS ≤ 4.0

2

CVE exists withCVSS ‘medium’or less than 7.0

If CVE 6= ” &CVSS = ‘med’ |CVSS ≤ 7.0

3

CVE exists withCVSS ‘high’ orless than 9.0

If CVE 6= ” &CVSS = ‘high’ |CVSS ≤ 9.0

4

CVE exists withCVSS ‘critical’or less than 10.0

If CVE 6= ” &CVSS = ‘critical’| CVSS ≤ 10.0

5

5.3 Weighting Criteria

The second part of the (T S) function correspondsto the weighting criteria (Pi). According to HenryDalziel (Dalziel, 2014), Threat Intelligence refers tospecific information that must meet three specific cri-teria: (i) it must be relevant, for the entity who re-ceives it, (ii) actionable and (iii) valuable, from abusiness perspective. In (ENISA, 2015) the conceptof “actionable information” is defined by the Euro-pean Union Agency for Network and Information Se-curity (ENISA), from an organization point of viewas the information that can be used immediately forspecific and strategical decision making. Considering(ThreatConnect, 2018) and (ENISA, 2015), in orderto be “actionable”, information must meet the follow-ing criteria:

Relevance: it must have some impacts on specificreceiver’s assets, such as networks, software andhardware. That is, indicators of compromise will usu-ally be considered relevant when a threat could affectthe monitored infrastructure. In order to determinethe relevance, it is crucial to determine types of threatstargeting your assets/systems, considering real-timeinformation (e.g., IoC), from many internal sources,because they are able to provide dynamic and con-tinuous information about current internal monitoringoperation, together with a global view of the infras-tructure status.

In our analysis, this criterion evaluates if the in-formation associated to a given attribute is useful toidentify a threat. Relevance is computed as shown in

Page 9: Enriching Threat Intelligence Platforms Capabilities

Table 4.

Table 4: Relevance Criteria

Relevance ScoreAttribute with no data 0Optional Attribute 1Attribute does not identify threat buthelps in the analysis

5

Attribute is useful to identify threat 7Mandatory attribute to identify threat 10

Timeliness: threat intelligence is more reliablewhen it allows detecting attacker’s activity, especiallyduring the same intrusion, to monitor how it evolvesduring time. Moreover, information about eventsolder than a few hours are, most of the times, irrel-evant and non-actionable due to the dynamic natureof some threat’s characteristics, considering that someof them are discovered and analyzed months after theinitial compromise.

In our analysis, this criterion evaluates if a de-tected event is related to an already detected one,by the infrastructure or by the OSINT-based compo-nents, and if for instance, such events refer to the samethreat, but with a different level of intrusion, provid-ing new or updated information. Timeliness is com-puted as shown in Table 5.

Table 5: Timeliness Criteria

Timeliness ScoreAttribute with no data 0Attribute has never been seen 1Attribute has been seen with the samevalue

5

Attribute has been seen with a differentvalue

10

Accuracy: the receiver side should be able to pro-cess the received data as soon as possible. It dependsmainly on three factors, which are the confident ofthe source from which data is retrieved, the trust levelplaced in those sources (which, in turn, could dependon factors such as false positives/false negatives rates)and the local dynamic context of the receiver. The lat-ter is crucial in order to avoid inaccurate results andefforts when dealing with incident response.

In our analysis, information coming from OSINT-based components will be compared to the informa-tion coming from the infrastructure, if there is a matchof one or more attributes, a score will be computed.Accuracy is computed as shown in Table 6.

Table 6: Accuracy Criteria

Accuracy ScoreAttribute with no data 0Attribute has some data with no match 1There is a match of one source and theinfrastructure

5

There is a match of two sources and theinfrastructure

10

Variety: detection and prevention should not relyon a single technique or tool. It is crucial to usea combination of systems, tools (e.g., IDS, IPS andFirewalls) and sources (e.g., OSINT), especially whenthey are able to detect the threat at different levels ofintrusions (kill chain phases).

In our analysis, this criterion evaluates the sourcesfrom where the information is originated or detectede.g., infrastructure, OSINT-based components. Vari-ety is computed as shown in Table 7.

Table 7: Variety Criteria

Variety ScoreAttribute with no data 0Data come from one source 1Data come from two sources 5Data come from all sources 10

Ingestibility: received information must be easy toingest into internal data management systems for fur-ther processing and analysis phases. This is achiev-able using specific standards for representing thisdata, allowing the receiver to process data as fast aspossible, helping also security analysts, as well asthrough the usage of specific transfer protocols forsharing the related intelligence.

Ingestibility is not considered in our analysis sincewe are assuming that all received data is expressed ina structured way and uses a specific standard formatto be processed in the system. The data collectionwill be handled directly by the MISP instance. Thiscriterion would have been meaningful in case of re-ception of unstructured information, but this scenariois not considered by the context aware OSINT plat-form. The analysis will focus on other criteria withthe possibility of adding new ones in the future.

Completeness: Threat intelligence should providevaluable and complete information to the final re-ceiver, evaluated from the local cyber context pointof view of the latter. Sometimes, sources are incom-plete when considered alone, but their provided data

Page 10: Enriching Threat Intelligence Platforms Capabilities

become actionable once combined or processed withother internal data available to the destination or re-ceived from other external sources.

In our analysis, this criterion is used as an over-all assessment of the heuristic and not for individ-ual score evaluation of the attributes. Each heuristicis composed of one or more attributes (e.g., CVE iscomposed of six attributes: (i) no cve, (ii) cvss none,(iii) cvss low, (iv) cvss medium, (v) cvss high, (vi)cvss critical. Completeness is measured as the num-ber of attributes with a non-empty value over the totalnumber of attributes, as shown in Equation 2.

Cp =Non Empty Attributes

Total Attributes(2)

6 Preliminary Results

In this section we will illustrate the advantages of ourapproach, and the benefits our platform will bring interms of prioritizing threat information received fromexternal sources (e.g., OSINT). We will use the Con-text Aware Intelligence Sharing Module to evaluaterelevance, accuracy, and other features on the infor-mation received from the Composed IoC Module. Forthe threat score evaluation we will consider both: thedata coming from the infrastructure through securitysystems and tools (e.g., SIEMs, IDS), as well as, IoCsobtained by open source and public feeds. The re-sulting threat score will be inserted in the informationassociated to the analized IoC. The higher the threatscore value, the higher the priority of the associatedinformation when handled by incident response teamsand security analysts.

The Composed IoC module will provide both: sin-gle and composed IoCs to the Context Aware Intel-ligence Sharing module. We expect that the com-posed IoCs will have an associated threat score higherthan the threat score of each single IoCs they con-tain. The entire process considered in this use caseis characterized by four sequential phases: Collect-ing and Aggregating phases, performed by the Com-posed IoC module, followed by the Sharing phase,which involves both modules, and the TS Evaluationphase, completely handled by the Context Aware In-telligence Sharing module.

Collecting Phase: to collect OSINT data we con-figured a MISP instance with 34 OSINT feeds fromhigher value information (e.g., CVE vulnerabilities)and low value information (e.g., IP blacklists). Thesefeeds are provided by diverse public free entities andreach MISP in different formats, such as csv and txt

files. OSINT data are normalized in a single format,namely the MISP format, and then stored as IoCsin the MISP database. Afterwards, the deduplicatormodule we developed is executed to load the IoCs andsearch for duplicates in order to delete them. This taskallows improving MISP in two forms: identify dupli-cated IoCs and reduce the quantity of data stored, andtherefore, increasing the MISP performance.

Aggregating Phase: After removing the duplicatedIoCs, the aggregator component analyses the result-ing IoCs to look for connections among them. For theconnections found, the aggregator puts the involvedIoCs in the same group of IoCs, since they are relatedto the same malicious threat. At the end, we haveseveral and different groups of IoCs forming clusters,each one for a particular threat category. At the pointof view of a threat category, a cluster can containIoCs correlated between them and related with a same(sub-)threat (or attack) and possibly with other valu-able malicious information that can be provided in asame IoC. This means that a cluster can contain sub-clusters of IoCs regarding to different attacks. Suchsub-clusters can well characterize, this point of view,attacks that have been executed, for which individualIoCs could not allow their identification. Finally, eachsub-cluster is represented as one IoC, i.e., all its IoCsare merged in a single one, generating a composedIoC, and then, they are stored in the MISP database.

Sharing Phase: the final outcome of the composedIoC module is sent to the context aware intelligencesharing module for proceeding with the final compu-tation of the threat score. This integration is achievedeasily thanks to the adoption of MISP.

More precisely, two different MISP instances areused, one by each module. For simplicity, and forfacilitating reader comprehension, we will refer tothem as MISPA and MISPB, respectively. These in-stances have been synchronized between each otherto allow a real-time and completely automated infor-mation sharing, following the guidelines provided inthe MISP book19 for setting up a MISP synchroniza-tion server on MISPA. This server has been associ-ated to a specific user with synchronization privileges,which is replicated in both instances. Injecting, andpublishing IoCs in MISPA on behalf of this user, trig-gers a push operation of one or more IoCs directly onMISPB, completing the one-way information sharingneeded for this use case scenario.

When the synchronization server is set up, thesync user authentication key must be specified. This

19https://www.circl.lu/doc/misp/book.pdf

Page 11: Enriching Threat Intelligence Platforms Capabilities

information is provided by MISPB, when the user iscreated.

TS Evaluation Phase: to perform the computationof the threat score, MISPB needs to be extended withnew functionalities. For this specific use case, wedeveloped a new MISP export module, integrating itwith the core software of the platform, following theguidelines20 provided by the MISP community anddevelopers. In this way, the module is available di-rectly from the MISP UI, where it can be triggeredmanually by the user for a specific IoC, to retrieveand send the IoC directly to the Heuristic Module ofthe platform (Figure 4), where the threat score func-tion has been implemented, and added to the originalIoC as a new MISP attribute.

Aiming at correlating IoCs with infrastructuredata, as well as with other useful information aboutcyber events from open source and public feeds, aMongoDB21 database is used, and the informationis stored as JSON documents. The final IoC (i.e.,enriched IoC) could be shared with specific securitytools or internal SOCs and CSIRTs, with the addi-tional threat score used for determining the priority ofthe contained data, in case of some defence activitieswould be needed.

In order to provide practical examples of the func-tionality of our platform, eleven samples of composedIoCs have been considered, and the entire process pre-viously described has been executed in each of them.As a result, the threat score (T S) is computed for ev-ery single IoC (sIoC) integrating the composed ones,making it possible to compare with the threat scorecomputed for the composed IoCs (cIoC).

For the heuristic analysis, a subset of nine MISPattributes22 has been selected, composed of the oneswhich are more relevant according to the monitoredinfrastructure (i.e., vulnerability, filename, ip-src, ip-dst, hostname, domain, url, link, and md5). This doesnot mean that other attributes are discarded, they sim-ply have a higher importance when specific criteriaare evaluated, especially for relevance and complete-ness.

Results are summarized in Table 8. Each row isassociated to a sample of composed IoCs (e.g., S1,..., S11), specifying the number of single IoCs (sIoC)composing them, their individual Threat Score (T S),and the global TS associated to the composed IoC(cIoC).

More information about our platform can be foundin https://caisplatform.wixsite.com/english.

20https://github.com/MISP/misp-modules21https://www.mongodb.com/22https://www.circl.lu/doc/misp/categories-and-types/

Table 8: Threat Score Results

Samples N. ofsIoCs

individual TS GlobalTS

S1 5 1.86, 2,55, 1.80,0.71, 1.94

3.18

S2 3 1.43, 2.32, 1,58 2.53S3 3 2.48, 1.54, 1.09 2.87S4 6 1.18, 1.40, 1.54,

0.64, 1.41, 2.033.07

S5 2 2.84, 1.66 3.22S6 17 1.39, 2.22, 2.21,

1.99, 1.87, 0.70,1.66, 1.10, 0.56,0.96, 0.94, 0.56,1.58, 2.66, 2.27,1.36, 1.08

3.98

S7 7 2.09, 3.27, 1.89,0.89, 2.88, 1.93,1.66

2.84

S8 4 3.06, 2.68, 2.11,1.55

3.11

S9 11 1.66, 1.21, 2.35,1.92, 1.33, 1.29,1.6, 0.90, 0.88,1.02, 0.56

4.13

S10 2 2.43, 2.31 2.54S11 2 0.99, 0.55 1.29

As depicted in Table 8, in most of the cases, theT S of the composed IoCs is higher than the T S foreach of the related single ones. This improvement isstrictly dependent on two main factors:1. The number of attributes present in the IoC. The

higher this number, the higher the probability ofincreasing the overall quality when the aggrega-tion is performed; and

2. The quality of the single IoCs. The higher thequality of the information found in the attributespresent in the sIoCs, the lower the probability toincrease the overall quality when aggregating sev-eral IoCs.For the first factor, we have seen samples S6 and S9

with a high number of single IoCs (17 and 11 IoCs re-spectively), for which the T S of their cIoC has greatlyimproved compared to the one of each sIoC. For thesecond factor, we have seen samples S2, S3, S7, andS10, in which the aggregation process is not able toadd a relevant level of quality to the final IoC. In thesecases, the quality of the information identified in thesIoC samples results in high T S values. Although inmost of the cases, the T S value of the cIoC is higherthan the one associated to each sIoC, the improvementis low, having in some cases a lower T S value in the

Page 12: Enriching Threat Intelligence Platforms Capabilities

cIoC compared to one of the sIoC (i.e., S7).It is important to note that among all the criteria

used in the T S computation, the completeness (i.e.,Cp) is the criterion that affects the most the final re-sult. Whereas, all other criteria are adding individualvalues to the T S, the completeness criterion is mul-tiplying to the overall addition, affecting to a higherlevel the T S results of single or composed IoCs.

7 Conclusion

This paper presents ET IP, an enriching threat intel-ligence platform, as an extended import, quality as-sessment processes and information sharing capabil-ities in current TIPs. The proposed platform gath-ers and processes structured information from exter-nal sources (e.g., OSINT sources) and from the moni-tored infrastructure. The platform is composed of twomain modules: (i) a Composed IoC Module, in chargeof collecting, normalizing, processing and aggregat-ing IoCs from OSINT feeds; and (ii) a Context AwareIntelligence Sharing Module, able to correlate, assessand share static and real time information with dataobtained from multiple OSINT sources.

The ETIP platform computes a Threat Score (T S)associated to each IoC before sharing it with both in-ternal monitoring systems and tools (e.g., SIEMs) andtrusted external parties. Enriched IoCs will contain athreat score that will enable SOC analysts to priori-tize the analysis of incidents. The Threat Score eval-uates heuristics with two types of weights: (i) indi-vidual weights assigned to every attribute (e.g., rele-vance, accuracy, variety, etc.); and (ii) global weight(i.e., completeness criterion) assigned to the heuristic.The higher the T S value, the more reliable the IoC.Thus, as the T S value approaches to zero, the IoC canbe considered as poor, incomplete and/or not reliablewith a very low priority level.

Future work will concentrate in developing newattributes to enrich the threat score analysis, improv-ing the quality of the refined threat intelligence to beshared, providing not only the final threat score, butalso detailed information about each single criterionused in the evaluation of the score itself, which inturn helps to improve threat detection and incident re-sponse.

Acknowledgment

The research in this paper has received fundingfrom the EC through funding of DiSIEM project,ref. project H2020-700692, NeCS project, ref.project H2020-675320 and LASIGE Research Unit,ref. UID/CEC/00408/2019.

REFERENCES

Accenture (2017). Cost of cyber crime study. Online.CEA (2018). The cost of malicious cyber activity to the u.s.

economy. Online Report.Dalziel, H. (2014). How to define and build an effective cy-

ber threat intelligence capability. In Syngress, eBook.ENISA (2015). Actionable information for security incident

response. In Online Technical Paper.ENISA (2017). Exploring the opportunities and limitations

of current threat intelligence platforms.Liao, X., Yuan, K., Wang, X., Li, Z., Xing, L., and Beyah.,

R. (2016). Acing the ioc game: Toward automaticdiscovery and analysis of open-source cyber threat in-telligence. In ACM SIGSAC Conference on Computerand Communications Security, pages 755–766.

Mavroeidis, V. and Bromander, S. (2017). Cyber threat in-telligence model: An evaluation of taxonomies, shar-ing standards, and ontologies within cyber threat in-telligence. In Intelligence and Security InformaticsConference, pages 91–98. IEEE.

Owen, T. (2015). Threat intelligence & siem. In MastersResearch Project, Lewis University.

Ravana, S. D. and Moffat, A. (2009). Score aggregationtechniques in retrieval experimentation. In TwentiethAustralasian Database Conference.

Sabottke, C., Suciu, O., and Dumitras, T. (2015). Vulnera-bility disclosure in the age of social media: exploitingtwitter for predicting real-world exploits. In In 24thUSENIX Security Symposium, pages 1041–1056.

Sauerwein, C., Sillaber, C., Mussmann, A., and Breu, R.(2017). Threat intelligence sharing platforms: An ex-ploratory study of software vendors and research per-spectives. In Conference on Wirtschaftsinformatik.

Sillaber, C., Sauerwein, C., Mussmann, A., and Breu, R.(2016). Data quality challenges and future researchdirections in threat intelligence sharing practice. InACM on Workshop on Information Sharing and Col-laborative Security, pages 65–70. ACM.

Skopik, F., Settanni, G., and Fiedler, R. (2016). A prob-lem shared is a problem halved: A survey on the di-mensions of collective cyber defense through securityinformation sharing. computers & security, 60:154–176.

ThreatConnect (Accessed February 2018). Threat intel-ligence platforms. everything you’ve ever wanted toknow but didn’t know to ask. In Ebook.

Torra, V. and Narukawa, Y. (2007). Modeling decisions:Information fusion and aggregation operators. InSpringer-Verlag Berlin Heidelberg.

Tounsi, W. and Rais, H. (2018). A survey on technical threatintelligence in the age of sophisticated cyber attacks.In Computers & Security, volume 72, pages 212–233.

Ventures, C. (2017). 2017 cybercrime report. Online.


Recommended