Journal:Interoperability challenges in the cybersecurity information sharing ecosystem - Revision history

Shawndouglas: Fixes

2020-10-27T19:15:25Z

Fixes

← Older revision		Revision as of 19:15, 27 October 2020
Line 21:		Line 21:

	==Abstract==		==Abstract==
	Threat intelligence helps businesses and organizations make the right decisions in their fight against cyber threats, and strategically design their digital ~~defences~~ for an optimized and up-to-date security situation. Combined with advanced security analysis, threat intelligence helps reduce the time between the detection of an attack and its containment. This is achieved by continuously providing [[information]], accompanied by data, on existing and emerging cyber threats and vulnerabilities affecting corporate networks. This paper addresses challenges that organizations are bound to face when they decide to invest in effective and interoperable [[cybersecurity]] information sharing, and it categorizes them in a layered model. Based on this, it provides an evaluation of existing sources that share cybersecurity information. The aim of this research is to help organizations improve their cyber threat information exchange capabilities, to enhance their security posture and be more prepared against emerging threats.		Threat intelligence helps businesses and organizations make the right decisions in their fight against cyber threats, and strategically design their digital defenses for an optimized and up-to-date security situation. Combined with advanced security analysis, threat intelligence helps reduce the time between the detection of an attack and its containment. This is achieved by continuously providing [[information]], accompanied by data, on existing and emerging cyber threats and vulnerabilities affecting corporate networks. This paper addresses challenges that organizations are bound to face when they decide to invest in effective and interoperable [[cybersecurity]] information sharing, and it categorizes them in a layered model. Based on this, it provides an evaluation of existing sources that share cybersecurity information. The aim of this research is to help organizations improve their cyber threat information exchange capabilities, to enhance their security posture and be more prepared against emerging threats.

	'''Keywords''': cyber threat information, cyber threat intelligence, interoperability, cybersecurity, evaluation		'''Keywords''': cyber threat information, cyber threat intelligence, interoperability, cybersecurity, evaluation
Line 101:		Line 101:
	An organization's information sharing policies and procedures are formal statements that reflect its objectives and detailed instructions to achieve these objectives respectively. They are typically part of the organization’s information security policy and have to be endorsed by the organization’s top management.		An organization's information sharing policies and procedures are formal statements that reflect its objectives and detailed instructions to achieve these objectives respectively. They are typically part of the organization’s information security policy and have to be endorsed by the organization’s top management.

	Among the issues that the organization has to consider at the policy layer when deciding to share CTII are the five "Ws" and one "H" that have to be answered prior to sharing, as depicted in Figure 2. The policy should clearly address them, while well-established procedures and appropriate robust measures will properly support them to avoid policy violations, such as the leakage of classified or sensitive information. Therefore, to ensure that the security and privacy posture of the ~~organisation~~ is not negatively affected by the introduction of CTII sharing, the service’s risk analysis should address the threats that are associated with the exchange of CTII with third parties and the consumption of the received information. The deployed security measures that will protect CTII and ensure that this is handled only by authenticated and authorized entities will minimise the associated risks.		Among the issues that the organization has to consider at the policy layer when deciding to share CTII are the five "Ws" and one "H" that have to be answered prior to sharing, as depicted in Figure 2. The policy should clearly address them, while well-established procedures and appropriate robust measures will properly support them to avoid policy violations, such as the leakage of classified or sensitive information. Therefore, to ensure that the security and privacy posture of the organization is not negatively affected by the introduction of CTII sharing, the service’s risk analysis should address the threats that are associated with the exchange of CTII with third parties and the consumption of the received information. The deployed security measures that will protect CTII and ensure that this is handled only by authenticated and authorized entities will minimise the associated risks.

Shawndouglas: Finished adding rest of content.

2020-10-27T19:11:03Z

Finished adding rest of content.

Show changes

Shawndouglas: Saving and adding more.

2020-10-27T18:51:01Z

Saving and adding more.

Show changes

Shawndouglas: Saving and adding more.

2020-10-27T18:03:09Z

Saving and adding more.

← Older revision		Revision as of 18:03, 27 October 2020
Line 92:		Line 92:
	\|}		\|}

	===~~3.1.~~ Legal interoperability===		===Legal interoperability===
	Legal interoperability is about ensuring that the legal frameworks under which organizations operate and provide services are aligned and do not impede the sharing of CTII. Legal frameworks open up the potential for improving the collaboration among public–private organizations and may encourage or require the sharing of cyber threat information. Examples of such frameworks are the E.U.’s NIS Directive<ref name="EURLexDir2016-1148" /> and the U.S. Cybersecurity Information Sharing Act (CISA) of 2015.		Legal interoperability is about ensuring that the legal frameworks under which organizations operate and provide services are aligned and do not impede the sharing of CTII. Legal frameworks open up the potential for improving the collaboration among public–private organizations and may encourage or require the sharing of cyber threat information. Examples of such frameworks are the E.U.’s NIS Directive<ref name="EURLexDir2016-1148" /> and the U.S. Cybersecurity Information Sharing Act (CISA) of 2015.

Line 103:		Line 103:
	As such, legal interoperability requires visibility control over CTII. The organization has to have the means to perform deep inspection on what is practically going to be shared to identify any information that may cross the well-established boundaries regarding information sharing, and this should be reflected to the policies and procedures adopted by the organization.		As such, legal interoperability requires visibility control over CTII. The organization has to have the means to perform deep inspection on what is practically going to be shared to identify any information that may cross the well-established boundaries regarding information sharing, and this should be reflected to the policies and procedures adopted by the organization.

	===~~3.2.~~ Policies and procedures for interoperability===		===Policies and procedures for interoperability===
	An organization's information sharing policies and procedures are formal statements that reflect its objectives and detailed instructions to achieve these objectives respectively. They are typically part of the organization’s information security policy and have to be endorsed by the organization’s top management.		An organization's information sharing policies and procedures are formal statements that reflect its objectives and detailed instructions to achieve these objectives respectively. They are typically part of the organization’s information security policy and have to be endorsed by the organization’s top management.

Line 140:		Line 140:
	Policies can be technically supported by the use of specific protocols, such as the Traffic Light Protocol (TLP)<ref name="FIRSTTraffic">{{cite web \|url=https://www.first.org/tlp/docs/tlp-v1.pdf \|format=PDF \|title=Traffic Light Protocol (TLP) \|author=FIRST \|accessdate=03 March 2020}}</ref> and the Information Exchange Policy (IEP)<ref name="FIRSTInforma">{{cite web \|url=https://www.first.org/iep/ \|title=Information Exchange Policy (IEP) \|author=FIRST \|accessdate=03 March 2020}}</ref>, which can semantically support the unambiguous transfer of policy rules among sharing parties, as explained in the following section.		Policies can be technically supported by the use of specific protocols, such as the Traffic Light Protocol (TLP)<ref name="FIRSTTraffic">{{cite web \|url=https://www.first.org/tlp/docs/tlp-v1.pdf \|format=PDF \|title=Traffic Light Protocol (TLP) \|author=FIRST \|accessdate=03 March 2020}}</ref> and the Information Exchange Policy (IEP)<ref name="FIRSTInforma">{{cite web \|url=https://www.first.org/iep/ \|title=Information Exchange Policy (IEP) \|author=FIRST \|accessdate=03 March 2020}}</ref>, which can semantically support the unambiguous transfer of policy rules among sharing parties, as explained in the following section.

	===~~3.3.~~ Semantic and syntactic interoperability===		===Semantic and syntactic interoperability===
	Semantics are introduced to convey the necessary meaning for syntactically correct messages. Although sources may disseminate unstructured information that hinder data processing (such as information found on social media, news, or even on CERT and CSIRTs) in the CTII sharing process, several standards have been introduced for properly exchanging CTII among stakeholders. Compliance with standards facilitates the automated sharing of information as well as its ingestion, analysis, and integration. Although the existence of a small set of standards facilitates interoperability, adopting a wide variety of competing non-interoperable ones introduces significant overhead and can eventually hinder the exchange of information. The most prominent standards of CTII sharing are:		Semantics are introduced to convey the necessary meaning for syntactically correct messages. Although sources may disseminate unstructured information that hinder data processing (such as information found on social media, news, or even on CERT and CSIRTs) in the CTII sharing process, several standards have been introduced for properly exchanging CTII among stakeholders. Compliance with standards facilitates the automated sharing of information as well as its ingestion, analysis, and integration. Although the existence of a small set of standards facilitates interoperability, adopting a wide variety of competing non-interoperable ones introduces significant overhead and can eventually hinder the exchange of information. The most prominent standards of CTII sharing are:

Line 197:		Line 197:
	\|}		\|}

			The latest version of STIX (2.x) is defined using JSON schemas, thus rendering it easier to parse and expand than its XML-based predecessor (STIX 1.x). CAPEC is supported in both STIX 1.x, as an instance type, and STIX 2.x, as an external reference for the "attack pattern" object type.

			STIX and MAEC were designed based on similar use cases. Despite their similarities, they differ in the level of description. MAEC is intended to provide a comprehensive, structured way of capturing detailed information regarding malware samples, whereas STIX is meant to capture a broad spectrum of cyber threat information, including basic information on malware in a more conceptual framework. An analysis of the types of malware-related information that can be captured by MAEC, STIX, and MAEC embedded in STIX is provided by The MITRE Corporation.<ref name="MITRECharact14">{{cite web \|url=https://stixproject.github.io/about/Characterizing_Malware_MAEC_and_STIX_v1.0.pdf \|format=PDF \|title=Characterizing Malware with MAEC and STIX v 1.0 \|author=MITRE Corporation \|date=21 April 2014 \|accessdate=03 March 2020}}</ref>

			STIX 2.x does not provide support for MAEC content. As a result, STIX 2.x cannot describe malware in as much detail as STIX 1.x.<ref name=OASISstix2-elev19">{{cite web \|url=https://stix2-elevator.readthedocs.io/_/downloads/en/v2.0.1/pdf/ \|format=PDF \|title=stix2-elevator Documentation Release 1.0.0 \|author=OASIS \|date=29 January 2019 \|accessdate=03 March 2020}}</ref> Nevertheless, STIX 2.1 will include a new object type called "malware-analysis", which could possibly include MAEC content.<ref name="OASISMappings">{{cite web \|url=https://stix2-elevator.readthedocs.io/en/latest/stix-mappings.html \|title=Mappings from STIX 1.x to STIX 2.x \|author=OASIS \|accessdate=03 March 2020}}</ref>

			Some of the aforementioned standards, such as STIX 2.0 and MISP, also support data markings which can facilitate enforcement of policies regarding the sharing of information to achieve technical and semantic interoperability. Data markings include:

			* statements, e.g., copyright, terms of use, applied to the shared content; and
			* Traffic Light Protocol (TLP v1.0)<ref name="FIRSTTraffic" /> designations.

			TLP v1.0 is a set of designations used to ensure that sensitive information is shared with the appropriate audience by providing four options, as shown in Figure 3. Although optimized for human readability and person-to-person sharing and rather than automated sharing exchanges, TLP can still help restrict information sharing only with specific entities or platforms and avoid any further unnecessary or unauthorized dissemination thereof. TLP is supported by STIX 2.0 and MISP protocols.


			[[File:Fig3 Rantos Computers2020 9-1.png\|500px]]
			{{clear}}
			{\|
			\| STYLE="vertical-align:top;"\|
			{\| border="0" cellpadding="5" cellspacing="0" width="500px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\| <blockquote>'''Fig. 3''' The Traffic Light Protocol (TLP)</blockquote>
			\|-
			\|}
			\|}

			TLP, however, cannot support fine-grained policies. Considering this limitation, FIRST developed the Information Exchange Policy (IEP)<ref name="FIRSTInforma" />, a JSON-based framework that content producers can use to specify restrictions for threat intelligence regarding the following:

			* Handling: It can be used to ensure the confidentiality of the information being shared.
			* Action: It can be used to define the permitted actions or uses of the information received that can be carried out by a recipient.
			* Sharing: It can be used to define any permitted redistribution of information that is received.
			* Licensing: It can be used to define any applicable agreements, licenses, or terms of use that govern the information being shared.

			Some of the aforementioned standards were developed to improve the sharing of cyber threat-related information, like incidents, patterns, and indicators, and not vulnerabilities, which can be considered a type of information that has its own needs and sets of standards for dissemination. Standards and languages that address vulnerabilities include:

			:1. '''Common Vulnerability Enumeration (CVE)''': A de facto standard for listing vulnerability information where each CVE entry should include a CVE ID number; a description of the vulnerability; the anticipated impact, in the form of a CVSS (Common Vulnerability Scoring System) value; and references to vulnerabilities reports and/or advisories.

			:2. '''Common Vulnerability Reporting Framework (CVRF)'''<ref name="OASIS_CSAFComm17">{{cite web \|url=http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html \|title=CSAF Common Vulnerability Reporting Framework (CVRF) Version 1.2 \|author=OASIS \|date=13 September 2017 \|accessdate=03 March 2020}}</ref>: An XML-based standard that supports the creation, update, and interoperable exchange of security advisories as structured information on products, vulnerability information, and the impact and remediation statuses among interested parties. According to MITRE, CVRF allows interested parties to download the entire CVE list at once, or download CVEs for a specific year, whereas each CVE can record when it was initially published by the CVE Team, and when it was most recently modified.

			:3. '''Open Vulnerability and Assessment Language (OVAL)''': A language that can be used for representing system information, expressing specific machine states, and reporting the results of an assessment.

			===Technical interoperability===
			Technical interoperability is much related to the implementation of the necessary tools and APIs to support the automated exchange of information, which includes both consumption and delivery, as well as the support of the underlying communication protocols used for conveying CTII information. It typically involves many layers of the TCP/IP stack in formulating and transferring these messages, yet the anticipated approach towards interoperable solutions is the adoption of well-established standardized protocols that can be easily supported by the communicating parties.

			Protocols that have been proposed for the transmission of CTII include the following (please note that in this paper we do not consider typical TCP/IP protocols, including those found at the application layer):

			:1. '''Trusted Automated Exchange of Intelligence Information (TAXII)'''<ref name="OASISCyberThreat" />: TAXII is an application-layer protocol that is used to exchange CTII, represented in STIX, over HTTPS.

			:2. '''Resource-Oriented Lightweight Information Exchange (ROLIE)'''<ref name="IETFResource18">{{cite web \|url=https://tools.ietf.org/html/rfc8322 \|title=Resource-Oriented Lightweight Information Exchange (ROLIE) \|author=Field, J.; Banghart, S.; Waltermire, D. \|publisher=Internet Engineering Task Force \|date=February 2018 \|accessdate=03 March 2020}}</ref>: ROLIE defines a REST-style approach for security information publication, discovery, and sharing. Using ROLIE, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information are provided as web-addressable resources. IETF’s MILE working group has drafted two extensions to ROLIE, one for CSIRTs needs<ref name="IETFDefin19">{{cite web \|url=https://tools.ietf.org/html/draft-ietf-mile-rolie-csirt-05 \|title=Definition of ROLIE CSIRT Extension, draft-ietf-mile-rolie-csirt-05 \|author=Banghart, S.; Field, J. \|publisher=Internet Engineering Task Force \|date=05 September 2019 \|accessdate=03 March 2020}}</ref> and another for the exchange of vulnerabilities. [40]<ref name="IETFDefinVulnExt19">{{cite web \|url=https://tools.ietf.org/html/draft-ietf-mile-rolie-vuln-02 \|title=Definition of the ROLIE Vulnerability Extension, draft-ietf-mile-rolie-vuln-02 \|author=Banghart, S. \|publisher=Internet Engineering Task Force \|date=05 September 2019 \|accessdate=03 March 2020}}</ref>

			Other technical issues that have to be considered during sharing are related to the protection of information against unauthorized disclosure or modification, the mechanisms that are used thereof, and the corresponding cryptographic algorithms.

			==The CTII landscape==




			<ref name="ENISAStateOf19">{{cite web \|url=https://www.enisa.europa.eu/publications/technical-reports-on-cybersecurity-situation-the-state-of-cyber-security-vulnerabilities/ \|title=State of Vulnerabilities 2018/2019 - Analysis of Events in the life of Vulnerabilities \|author=Katos, V.; Rostami, S.; Bellonias, P. et al. \|publisher=ENISA \|date=14 January 2019 \|accessdate=03 March 2020 \|doi=10.2824/139301}}</ref>

Shawndouglas: Saving and adding more.

2020-10-27T17:07:58Z

Saving and adding more.

← Older revision		Revision as of 17:07, 27 October 2020
Line 149:		Line 149:
	:3. '''Common Attack Pattern Enumeration and Classification (CAPEC)'''<ref name="MITRE_CAPEC">{{cite web \|url=https://capec.mitre.org/index.html \|title=CAPEC: Common Attack Pattern Enumeration and Classification \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref>: MITRE Corporation's CAPEC provides a comprehensive dictionary of known patterns of attack employed by adversaries to exploit known weaknesses.		:3. '''Common Attack Pattern Enumeration and Classification (CAPEC)'''<ref name="MITRE_CAPEC">{{cite web \|url=https://capec.mitre.org/index.html \|title=CAPEC: Common Attack Pattern Enumeration and Classification \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref>: MITRE Corporation's CAPEC provides a comprehensive dictionary of known patterns of attack employed by adversaries to exploit known weaknesses.

	:4. '''Malware Attribute Enumeration and Characterization (MAEC)'''<ref ~~nae~~="MITRE_MAEC">{{cite web \|url=https://maecproject.github.io/ \|title=Malware Attribute Enumeraion and Characterization (MAEC) \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref> : MITRE Corporation's GitHub-based MAEC is a structured language used for encoding and sharing information about malware based upon attributes such as behaviors, artifacts, and relationships between malware samples. It facilitates correlation, integration, and automation of malware analysis and reduces potential duplication of malware during analysis.		:4. '''Malware Attribute Enumeration and Characterization (MAEC)'''<ref name="MITRE_MAEC">{{cite web \|url=https://maecproject.github.io/ \|title=Malware Attribute Enumeraion and Characterization (MAEC) \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref> : MITRE Corporation's GitHub-based MAEC is a structured language used for encoding and sharing information about malware based upon attributes such as behaviors, artifacts, and relationships between malware samples. It facilitates correlation, integration, and automation of malware analysis and reduces potential duplication of malware during analysis.

			:5. '''Managed Incident Lightweight Exchange (MILE)''': IETF's MILE working group develops standards to support computer and network security incident management, focusing on the definition of data formats for representing incident and indicator data, and on standardizing how application-layer protocols such as HTTPS and XMPP are utilized for sharing the structured data. Standards adopted by MILE include 1. IODEF v2 (Incident Object Description Exchange Format)<ref name="IETFTheIncident16">{{cite web \|url=https://tools.ietf.org/html/rfc7970 \|title=The Incident Object Description Exchange Format Version 2 \|author=Danyliw, R. \|publisher=Internet Engineering Task Force \|date=November 2016 \|accessdate=03 March 2020}}</ref><ref name="IETFIncidentObject17">{{cite web \|url=https://tools.ietf.org/html/rfc8274 \|title=Incident Object Description Exchange Format Usage Guidance \|author=Kampanakis, P.; Suzuki, M. \|publisher=Internet Engineering Task Force \|date=November 2017 \|accessdate=03 March 2020}}</ref>, an XML-based data representation of security incident reports and indicators designed to be compatible with IDMEF (Intrusion Detection Message Exchange Format) and capable of placing an IDMEF message into incident objects; and 2. Intrusion Detection Message Exchange Format (IDMEF)<ref name="IETFTheIntrusion07">{{cite web \|url=https://tools.ietf.org/html/rfc4765 \|title=The Intrusion Detection Message Exchange Format (IDMEF) \|author=Debar, H.; Curry, D.; Feinstein, B. \|publisher=Internet Engineering Task Force \|date=March 2007 \|accessdate=03 March 2020}}</ref>, an XML-based data format that is used by intrusion detection and response systems to report alerts about suspicious events.

			A comparison of the above CTII sharing technologies with respect to the data format and the types of data they can support is provided in Table 1.

			{\|
			\| STYLE="vertical-align:top;"\|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="100%"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3"\|'''Table 1.''' CTII technologies characteristics
			\|-
			\|-
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;"\|Technology
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;"\|Format
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;"\|Type of data
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|STIX1.x
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|XML
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|TTP, Threat Actor, Incident, Exploit Target, Course of Action, Report, Package
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|STIX2.x
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|JSON
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Attack Pattern, Campaign, Course of Action, Identity, Indicator, Intrusion Set, Malware, Observed Data, Report, Threat Actor, Tool, Vulnerability, Sighting
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|MISP
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|JSON
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Sighting, Threat Actor, Incident, Network Activity, Antivirus Detection, Hashes, Malware Sample, External Analysis, Traffic Light Protocol
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|CAPEC
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|XML
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Attack Pattern, Cross Site Forgery, SQL Injection, Buffer Overflow
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|MAEC
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|JSON
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Malware, Cyber Observable, Entity Association, Incident Management
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|IODEFv2
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|XML/HTML
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Incident Management, Hashes, Indicator
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|IDMEF
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|XML
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|IP Addresses, Malware, Alert, (Login, Date of Creation, Classification)
			\|-
			\|}
			\|}

Shawndouglas: Saving and adding more.

2020-10-27T16:29:28Z

Saving and adding more.

← Older revision		Revision as of 16:29, 27 October 2020
Line 144:		Line 144:

	:1. '''Structured Threat Information Expression (STIX)'''<ref name="OASISCyberThreat">{{cite web \|url=https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti \|title=OASIS Cyber Threat Intelligence (CTI) TC \|author=OASIS \|accessdate=03 March 2020}}</ref> : This OASIS-adopted standard is an information model and serialization solution used to exchange CTII. STIX 2.X is based on JSON, while its predecessors (e.g., STIX 1.X) were XML-based. STIX 1.X together with CybOX 2.X [26], a standardized language for encoding and communicating information about cyber observables, were integrated into STIX 2.0.		:1. '''Structured Threat Information Expression (STIX)'''<ref name="OASISCyberThreat">{{cite web \|url=https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti \|title=OASIS Cyber Threat Intelligence (CTI) TC \|author=OASIS \|accessdate=03 March 2020}}</ref> : This OASIS-adopted standard is an information model and serialization solution used to exchange CTII. STIX 2.X is based on JSON, while its predecessors (e.g., STIX 1.X) were XML-based. STIX 1.X together with CybOX 2.X [26], a standardized language for encoding and communicating information about cyber observables, were integrated into STIX 2.0.

			:2. '''Malware Information Sharing and Threat Intelligence Sharing Platform (MISP)'''<ref name="MISP" />: A data model composed of “events,” which usually represent threats or incidents, which in turn are composed of a list of “attributes,” such as IP addresses and domain names. Objects in MISP allow combinations of attributes and “galaxies,” which enable a deeper analysis and categorization of events.

			:3. '''Common Attack Pattern Enumeration and Classification (CAPEC)'''<ref name="MITRE_CAPEC">{{cite web \|url=https://capec.mitre.org/index.html \|title=CAPEC: Common Attack Pattern Enumeration and Classification \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref>: MITRE Corporation's CAPEC provides a comprehensive dictionary of known patterns of attack employed by adversaries to exploit known weaknesses.

			:4. '''Malware Attribute Enumeration and Characterization (MAEC)'''<ref nae="MITRE_MAEC">{{cite web \|url=https://maecproject.github.io/ \|title=Malware Attribute Enumeraion and Characterization (MAEC) \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref> : MITRE Corporation's GitHub-based MAEC is a structured language used for encoding and sharing information about malware based upon attributes such as behaviors, artifacts, and relationships between malware samples. It facilitates correlation, integration, and automation of malware analysis and reduces potential duplication of malware during analysis.

Shawndouglas: Saving and adding more.

2020-10-27T16:21:54Z

Saving and adding more.

← Older revision		Revision as of 16:21, 27 October 2020
Line 119:		Line 119:
	\|}		\|}
	\|}		\|}

			The adopted procedures should facilitate information sharing according to the organization’s strategy and policy and should not be an impediment to the accurate, fast, and secure exchange of high-quality information. Organizations’ policies may also be driven by security-related standards that address the sensitive issue of information sharing, such as the [[ISO/IEC 27000-series\|ISO 27010:2015]]<ref name="ISOInfoTech15">{{cite web \|url=https://www.iso.org/standard/68427.html \|title=ISO/IEC 27010:2015 Information technology — Security techniques — Information security management for inter-sector and inter-organizational communications \|publisher=International Organization for Standardization \|date=November 2015 \|accessdate=27 October 2020}}</ref>, which provides guidance on managing information within sharing communities and therefore facilitates trust establishment among stakeholders. Trust establishment with stakeholders is the foundation in CTII sharing and should be mainly addressed in the context of the “Who to share it with” question. A methodology that can be used for evaluating CTII sources based on quantitative parameters is proposed by Schaberreiter ''et al.''<ref name="SchaberreiterAQuant19">{{cite journal \|title=A Quantitative Evaluation of Trust in the Quality of Cyber Threat Intelligence Sources \|journal=ARES '19: Proceedings of the 14th International Conference on Availability, Reliability and Security \|author=Schaberreiter, T.; Kupfersberger, V.; Rantos, K. et al. \|pages=1–10 \|at=83 \|year=2019 \|doi=10.1145/3339252.3342112}}</ref> The methodology is based on a weighted evaluation method that allows each entity to adapt it to its own needs and priorities.

			In the context of formulating its policy and procedures, an organization may consider adopting a cybersecurity sharing framework for managing cyber threat information, which sets provisions for information sharing and exchange. There are several frameworks and programs adopted and supported by governments or the industry, like the U.S. Department of Homeland Security’s (DHS) Automated Indicator Sharing (AIS)<ref name="DHSAuto" /> and Cyber Information Sharing and Collaboration Program (CISCP)<ref name="DHSCyberInf0" />, which are more focused on critical infrastructure sectors; the standardized Cybersecurity Information Exchange Framework (CYBEX)<ref name="RutkowskiCYBEX10">{{cite journal \|title=CYBEX: The cybersecurity information exchange framework (x.1500) \|journal=ACM SIGCOMM Computer Communication Review \|author=Rutkowski, A.; Kadobayashi, Y.; Furey, I. et al. \|volume=40 \|issue=5 \|pages=59–64 \|year=2010 \|doi=10.1145/1880153.1880163}}</ref>; and the Malware Information Sharing Platform (MISP)<ref name="MISP">{{cite web \|url=https://www.misp-project.org/ \|title=MISP - Open Source Threat Intelligence Platform & Open Standards for Threat Information Sharing \|publisher=MISP Project \|accessdate=03 March 2020}}</ref>; as well as proposed frameworks, like the Cybersecurity Information Exchange with Privacy (CYBEX-P), which also addresses data privacy and classified data management issues.<ref name="SadiqueASys19">{{cite journal \|title=A System Architecture of Cybersecurity Information Exchange with Privacy (CYBEX-P) \|journal=Proceedings from the 2019 IEEE 9th Annual Computing and Communication Workshop and Conference \|author=Sadique, F.; Bakhshaliyev, K.; Springer, J. et al. \|pages=493–98 \|year=2019 \|doi=10.1109/CCWC.2019.8666600}}</ref>

			Data sanitization<ref name="BishopHowToSan04">{{cite journal \|title=How to sanitize data? \|journal=Proceedings from the 13th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises \|author=Bishop, M.; Bhumiratana, B.; Crawford, R. et al. \|pages=217-222 \|year=2004 \|doi=10.1109/ENABL.2004.36}}</ref> is one of the solutions organizations should consider using to ensure that no classified or sensitive information is disclosed to unauthorized entities while sharing CTII with external entities. In this context, an organization should carefully review and classify the information that their security appliances use and report (e.g., logs from IDS/IPS), and ensure that no information violating the organization’s policy is accidentally shared using CIE tools. For example, the CIE solution should not disclose the internal IP that has been reported by the IDS/IPS as a target of malicious activity.

			Sharing of information, if not public, should be driven by agreements among the sharing parties, which address policy restrictions. Such agreements should address, among others, the following issues<ref name="ISAO300-2">{{cite web \|url=https://www.isao.org/storage/2019/04/ISAO-300-2-Automated-Cyber-Threat-intelligence-Sharing.pdf \|format=PDF \|title=ISAO 300-2: Automating Cyber Threat Intelligence Sharing v1.0 \|author-ISAO Standards Organization \|date=05 April 2019 \|accessdate=03 March 2020}}</ref>:

			* the type of information that satisfies the organization's business needs;
			* the form of information exchange that is going to take place, such as emails, bulletins, documents, and automated sharing;
			* the confidentiality requirements for the exchanged information and the dissemination restrictions;
			* the parties authorized to access, process, and use the information;
			* the technical standards used for the exchange of information to satisfy the syntactic and semantic interoperability;
			* any language issues for cross-border dissemination; and
			* any communication protocols and access to services.

			Security organizations use licensing agreements as one of the tools for controlling access to the CTII they produce and process. Several agreement schemes can be adopted by the organization, depending on its business model and needs, as well as the types of services provided to consumers and third parties. Schemes that enforce restricted use include, but are not limited to, commercial, academic or research, and personal use licenses. Other licenses may be related to information reuse options and further dissemination of this information to third parties or other communities. For example, several vendors build their own communities, where information collected by their deployed security appliances is properly analyzed, evaluated, and disseminated back to their customers.

			Policies can be technically supported by the use of specific protocols, such as the Traffic Light Protocol (TLP)<ref name="FIRSTTraffic">{{cite web \|url=https://www.first.org/tlp/docs/tlp-v1.pdf \|format=PDF \|title=Traffic Light Protocol (TLP) \|author=FIRST \|accessdate=03 March 2020}}</ref> and the Information Exchange Policy (IEP)<ref name="FIRSTInforma">{{cite web \|url=https://www.first.org/iep/ \|title=Information Exchange Policy (IEP) \|author=FIRST \|accessdate=03 March 2020}}</ref>, which can semantically support the unambiguous transfer of policy rules among sharing parties, as explained in the following section.

			===3.3. Semantic and syntactic interoperability===
			Semantics are introduced to convey the necessary meaning for syntactically correct messages. Although sources may disseminate unstructured information that hinder data processing (such as information found on social media, news, or even on CERT and CSIRTs) in the CTII sharing process, several standards have been introduced for properly exchanging CTII among stakeholders. Compliance with standards facilitates the automated sharing of information as well as its ingestion, analysis, and integration. Although the existence of a small set of standards facilitates interoperability, adopting a wide variety of competing non-interoperable ones introduces significant overhead and can eventually hinder the exchange of information. The most prominent standards of CTII sharing are:

			:1. '''Structured Threat Information Expression (STIX)'''<ref name="OASISCyberThreat">{{cite web \|url=https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti \|title=OASIS Cyber Threat Intelligence (CTI) TC \|author=OASIS \|accessdate=03 March 2020}}</ref> : This OASIS-adopted standard is an information model and serialization solution used to exchange CTII. STIX 2.X is based on JSON, while its predecessors (e.g., STIX 1.X) were XML-based. STIX 1.X together with CybOX 2.X [26], a standardized language for encoding and communicating information about cyber observables, were integrated into STIX 2.0.

Shawndouglas: Saving and adding more.

2020-10-26T23:08:26Z

Saving and adding more.

← Older revision		Revision as of 23:08, 26 October 2020
Line 78:		Line 78:

	==Interoperable CTII sharing==		==Interoperable CTII sharing==
	CTII information is generated and shared among devices and organizations that typically have well-established procedures to appropriately handle [[Information privacy\|personal] and classified information found within. When CTII is about to be shared, especially with external entities, several interoperability and security issues have to be confronted. These issues can be categorized into the four layers depicted in Figure 1, further analyzed in the following sections.		Cyber threat information and intelligence (CTII) information is generated and shared among devices and organizations that typically have well-established procedures to appropriately handle [[Information privacy\|personal] and classified information found within. When CTII is about to be shared, especially with external entities, several interoperability and security issues have to be confronted. These issues can be categorized into the four layers depicted in Figure 1, further analyzed in the following sections.


Line 92:		Line 92:
	\|}		\|}

			===3.1. Legal interoperability===
			Legal interoperability is about ensuring that the legal frameworks under which organizations operate and provide services are aligned and do not impede the sharing of CTII. Legal frameworks open up the potential for improving the collaboration among public–private organizations and may encourage or require the sharing of cyber threat information. Examples of such frameworks are the E.U.’s NIS Directive<ref name="EURLexDir2016-1148" /> and the U.S. Cybersecurity Information Sharing Act (CISA) of 2015.

			Legal constraints may also prohibit or restrict the uncontrolled sharing of CTII. Examples of the latter are any personally identifiable information (PII) that may be part of the shared sightings, such as usernames of entities that have been identified as sources of malicious activity and restrictions that stem from the corresponding telecommunications privacy legal framework. One of the main legal restrictions arises from the E.U.'s [[General Data Protection Regulation]] (GDPR)<ref name="EURLexDir2016/679">{{cite web \|url=https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX%3A32016R0679 \|title=Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) \|work=EUR-Lex \|publisher=European Union \|date=27 April 2016 \|accessdate=03 March 2020}}</ref> and relates to any PII shared with external entities without the user’s consent. CTII sharing with external entities should not impact [[Information privacy\|privacy]], and sharing parties must take measures to properly anonymize or [[Pseudonymization\|pseudonymize]] any records of data that could otherwise be used to identify individuals.

			Liability is another key factor that has to be considered when sharing information. Organizations have to take into account that they may be liable for any damage caused to stakeholders or entities that appear to be threat actors, by sharing information that may prove inaccurate or false. For instance, what would happen if an IDS/IPS falsely identified some malicious activity coming from a popular website and this was immediately reported to sharing parties?

			Legal interoperability is even more important when data sharing spans multiple countries or legal domains. Therefore, restrictions imposed by each such domain must be carefully reviewed prior to information dissemination. The organization has to establish boundaries on any sharing activities so that these will not infringe on any legal restrictions.

			As such, legal interoperability requires visibility control over CTII. The organization has to have the means to perform deep inspection on what is practically going to be shared to identify any information that may cross the well-established boundaries regarding information sharing, and this should be reflected to the policies and procedures adopted by the organization.

			===3.2. Policies and procedures for interoperability===
			An organization's information sharing policies and procedures are formal statements that reflect its objectives and detailed instructions to achieve these objectives respectively. They are typically part of the organization’s information security policy and have to be endorsed by the organization’s top management.

			Among the issues that the organization has to consider at the policy layer when deciding to share CTII are the five "Ws" and one "H" that have to be answered prior to sharing, as depicted in Figure 2. The policy should clearly address them, while well-established procedures and appropriate robust measures will properly support them to avoid policy violations, such as the leakage of classified or sensitive information. Therefore, to ensure that the security and privacy posture of the organisation is not negatively affected by the introduction of CTII sharing, the service’s risk analysis should address the threats that are associated with the exchange of CTII with third parties and the consumption of the received information. The deployed security measures that will protect CTII and ensure that this is handled only by authenticated and authorized entities will minimise the associated risks.


			[[File:Fig2 Rantos Computers2020 9-1.png\|400px]]
			{{clear}}
			{\|
			\| STYLE="vertical-align:top;"\|
			{\| border="0" cellpadding="5" cellspacing="0" width="400px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\| <blockquote>'''Fig. 2''' The five "Ws" and one "H" of CIE policy</blockquote>
			\|-
			\|}
			\|}

Shawndouglas: Saving and adding more.

2020-10-26T22:48:47Z

Saving and adding more.

← Older revision		Revision as of 22:48, 26 October 2020
Line 6:		Line 6:
	\|title_full = Interoperability challenges in the cybersecurity information sharing ecosystem		\|title_full = Interoperability challenges in the cybersecurity information sharing ecosystem
	\|journal = ''Computers''		\|journal = ''Computers''
	\|authors = Rantos, Konstantinos; Spyros, Arnolnt~~, Spyros~~; Papanikolaou, Alexandros; Kritsas, Antonios; Ilioudis, Christos; Katos, Vasilios		\|authors = Rantos, Konstantinos; Spyros, Arnolnt; Papanikolaou, Alexandros; Kritsas, Antonios; Ilioudis, Christos; Katos, Vasilios
	\|affiliations = International Hellenic University, Innovative Secure Technologies, Bournemouth University		\|affiliations = International Hellenic University, Innovative Secure Technologies, Bournemouth University
	\|contact = Email: krantos at cs dot ihu dot gr		\|contact = Email: krantos at cs dot ihu dot gr
Line 62:		Line 62:
	* recommended security tool configurations, regarding automated collection and processing as well as healing of identified security issues; and		* recommended security tool configurations, regarding automated collection and processing as well as healing of identified security issues; and
	* vulnerabilities, i.e., known weaknesses in software implementations or procedures, and corresponding mitigations, such as security patches (although in the information security literature, vulnerabilities are not threats, they are considered an important component in the CTII sharing ecosystem).		* vulnerabilities, i.e., known weaknesses in software implementations or procedures, and corresponding mitigations, such as security patches (although in the information security literature, vulnerabilities are not threats, they are considered an important component in the CTII sharing ecosystem).

			The U.K. National Computer Emergency Response Team CERT-UK, together with the U.K.’s Centre for the Protection of National Infrastructure, define four subtypes of threat intelligence in a whitepaper published by MWR Infosecurity.<ref name="ChismonThreat15">{{cite web \|url=https://www.foo.be/docs/informations-sharing/Threat-Intelligence-Whitepaper.pdf \|format=PDF \|title=Threat Intelligence: Collecting, Analyzing, Evaluating \|author=Chismon, D.; Ruks, M. \|publisher=MWR InfoSecurity Ltd \|date=2015 \|accessdate=03 March 2020}}</ref> A similar categorization is also adopted by ENISA.<ref name="ENISAAction14">{{cite web \|url=https://www.enisa.europa.eu/publications/actionable-information-for-security/at_download/fullReport \|format=PDF \|title=Actionable Information for Security Incident Response \|author=ENISA \|date=November 2014 \|accessdate=03 March 2020}}</ref> Based on the two schemes, stakeholders exchange information of one of the following types:

			* strategic reports providing high-level threat analyses that are consumed at board level or by other senior decision-makers;
			* operational details providing information about impending attacks against an organization;
			* advisories which include vulnerabilities, exploits, patches and patch statuses, or high-level tactical patterns of activity on host-, service-, network-, or internet-level tools and methodologies;
			* indicators of compromise, which include IP addresses, DNS names, URLs, specific values of format-specific fields (e.g., email headers), artifacts (e.g., hashes, registries, and keys) related to malware and sequences of low-level events (e.g., syscalls and packets) linked to malicious behavior; and
			* low-level activity, i.e., network flow records and full packet captures, application logs, including typical IDS alerts, samples of executable files, documents, and email messages.

			Depending on the type of information that is being shared, organizations have the capability for prompt reaction, as a response to newly-emerged threats or vulnerabilities, for properly adapting their security defenses against changes in their situational awareness at a more tactical level, while making more strategic decisions on the allocation of their resources for upcoming threats.

			Tounsi and Rais<ref name="TounsiASurv18" /> classify and distinguish existing threat intelligence types, focusing on technical threat intelligence issues, emerging research, trends, and standards. They also explain why there is a reluctance among organizations to share threat intelligence, while also providing sharing strategies that can help overcome policy interoperability issues. Following a layered model, Burger ''et al.''<ref name="BurgerTaxon14">{{cite journal \|title=Taxonomy Model for Cyber Threat Intelligence Information Exchange Technologies \|journal=WISCS '14: Proceedings of the 2014 ACM Workshop on Information Sharing & Collaborative Security \|author=Burger, E.W.; Goodman, M.D.; Kampanakis, P. et al. \|pages=51–60 \|year=2014 \|doi=10.1145/2663876.2663883}}</ref> propose a taxonomy to help classify existing threat-sharing standards and analyze interoperability. However, the five layers proposed by the authors do not address legal or semantic issues that are analyzed in this paper.

			So far, although CTII sharing is identified in the literature as an important issue, it is treated as a problem that can be solved with the adoption of some technical standards.<ref name="JohnsonGuideTo16" /><ref name="BurgerTaxon14" /><ref name="SkopicAProb16">{{cite journal \|title=A problem shared is a problem halved: A survey on the dimensions of collective cyber defense through security information sharing \|journal=Computers & Security \|author=Skopik, F.; Settanni, G.; Fiedler, R. \|volume=60 \|pages=154–76 \|year=2016 \|doi=10.1016/j.cose.2016.04.003}}</ref> To the best of the authors’ knowledge, no work has been published so far detailing a holistic approach to the interoperability problem of CTII sharing.

			==Interoperable CTII sharing==
			CTII information is generated and shared among devices and organizations that typically have well-established procedures to appropriately handle [[Information privacy\|personal] and classified information found within. When CTII is about to be shared, especially with external entities, several interoperability and security issues have to be confronted. These issues can be categorized into the four layers depicted in Figure 1, further analyzed in the following sections.


			[[File:Fig1 Rantos Computers2020 9-1.png\|700px]]
			{{clear}}
			{\|
			\| STYLE="vertical-align:top;"\|
			{\| border="0" cellpadding="5" cellspacing="0" width="700px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\| <blockquote>'''Fig. 1''' Cyber threat information and intelligence (CTII) exchange interoperability layers</blockquote>
			\|-
			\|}
			\|}

Shawndouglas: Saving and adding more.

2020-10-26T22:13:25Z

Saving and adding more.

← Older revision		Revision as of 22:13, 26 October 2020
Line 51:		Line 51:

	The cooperation among organizations in the E.U. and the publication of detected security incidents are also encouraged, although there are also cases where they are obligatory, as stated in E.U. Directive 2016/1148 on the security of network and information systems.<ref name="EURLexDir2016-1148">{{cite web \|url=https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016L1148&qid=1603749013818 \|title=Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union \|work=EUR-Lex \|publisher=European Union \|date=06 July 2016 \|accessdate=03 March 2020}}</ref> Implementation guidance for meeting the requirements of that directive is provided by ETSI.<ref name="ETSICyber17">{{cite web \|url=https://www.etsi.org/deliver/etsi_tr/103400_103499/103456/01.01.01_60/tr_103456v010101p.pdf \|format=PDF \|title=CYBER; Implementation of the Network and Information Security (NIS) Directive \|author=ETSI \|work=ETSI TR 103 456 V1.1.1 \|date=October 2017 \|accessdate=03 March 2020}}</ref> In this context, a computer security incident response team (CSIRT; also known as computer emergency response team or CERT) network has been established, which counts more than 400 members willing to share incidents and risk-related information (an inventory of the E.U.'s CSIRT network members is maintained by ENISA<ref name="ENISA_CSIRTs">{{cite web \|url=https://www.enisa.europa.eu/topics/csirts-in-europe/csirt-inventory \|title=CSIRTs in Europe \|author=European Union Agency for Cybersecurity \|accessdate=03 March 2020}}</ref>). The network, however, is not restricted only to CSIRTs, but also includes commercial organizations, E.U. institutions, law enforcement agencies, private- and public-sector organizations, and national and military agencies.		The cooperation among organizations in the E.U. and the publication of detected security incidents are also encouraged, although there are also cases where they are obligatory, as stated in E.U. Directive 2016/1148 on the security of network and information systems.<ref name="EURLexDir2016-1148">{{cite web \|url=https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016L1148&qid=1603749013818 \|title=Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union \|work=EUR-Lex \|publisher=European Union \|date=06 July 2016 \|accessdate=03 March 2020}}</ref> Implementation guidance for meeting the requirements of that directive is provided by ETSI.<ref name="ETSICyber17">{{cite web \|url=https://www.etsi.org/deliver/etsi_tr/103400_103499/103456/01.01.01_60/tr_103456v010101p.pdf \|format=PDF \|title=CYBER; Implementation of the Network and Information Security (NIS) Directive \|author=ETSI \|work=ETSI TR 103 456 V1.1.1 \|date=October 2017 \|accessdate=03 March 2020}}</ref> In this context, a computer security incident response team (CSIRT; also known as computer emergency response team or CERT) network has been established, which counts more than 400 members willing to share incidents and risk-related information (an inventory of the E.U.'s CSIRT network members is maintained by ENISA<ref name="ENISA_CSIRTs">{{cite web \|url=https://www.enisa.europa.eu/topics/csirts-in-europe/csirt-inventory \|title=CSIRTs in Europe \|author=European Union Agency for Cybersecurity \|accessdate=03 March 2020}}</ref>). The network, however, is not restricted only to CSIRTs, but also includes commercial organizations, E.U. institutions, law enforcement agencies, private- and public-sector organizations, and national and military agencies.

			Similar initiatives in the U.S. that promote the exchange of information include the U.S. Department of Homeland Security (DHS) Cyber Information Sharing and Collaboration Program (CISCP)<ref name="DHSCyberInf0">{{cite web \|url=https://www.cisa.gov/ciscp \|title=Cyber Information Sharing and Collaboration Program (CISCP) \|author=Cybersecurity & Infrastructure Security Agency \|publisher=U.S. Department of Homeland Security \|accessdate=03 March 2020}}</ref> and its Automated Indicator Sharing (AIS) capability.<ref name="DHSAuto">{{cite web \|url=https://www.cisa.gov/automated-indicator-sharing-ais \|title=Automated Indicator Sharing \|author=Cybersecurity & Infrastructure Security Agency \|publisher=U.S. Department of Homeland Security \|accessdate=03 March 2020}}</ref>

			Examples of such shareable information include the following:

			* indicators of compromise (IOCs), i.e., system artifacts or observables that contain patterns, such as malicious Internet Protocol addresses (IPs) or hashes of files containing malware, which can help identify suspicious or malicious activity;
			* tactics, techniques, and procedures (TTPs), i.e., (detailed) descriptions of the behavior of an actor that can assist operational activities, such as details of exploits and malware delivery mechanisms (examples include tradecrafts, i.e., behaviour used to conduct a malicious activity, infrastructure used to deliver malicious content or maintain command and control capabilities, and attackers’ intentions<ref name="DNIGuideToCyber18">{{cite web \|url=https://www.dni.gov/files/CTIIC/documents/ODNI_A_Guide_to_Cyber_Attribution.pdf \|format=PDF \|title=A Guide to Cyber Attribution \|author=Office of the Director of National Intelligence \|date=14 September 2018 \|accessdate=03 March 2020}}</ref>);
			* security alerts, i.e., notifications—usually human-readable—regarding security issues, such as vulnerabilities;
			* threat intelligence reports, i.e., collections of threat intelligence for various topics, such as threat actors, malware, and attack techniques;
			* recommended security tool configurations, regarding automated collection and processing as well as healing of identified security issues; and
			* vulnerabilities, i.e., known weaknesses in software implementations or procedures, and corresponding mitigations, such as security patches (although in the information security literature, vulnerabilities are not threats, they are considered an important component in the CTII sharing ecosystem).

← Older revision		Revision as of 17:07, 27 October 2020
Line 149:		Line 149:
	:3. '''Common Attack Pattern Enumeration and Classification (CAPEC)'''<ref name="MITRE_CAPEC">{{cite web \|url=https://capec.mitre.org/index.html \|title=CAPEC: Common Attack Pattern Enumeration and Classification \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref>: MITRE Corporation's CAPEC provides a comprehensive dictionary of known patterns of attack employed by adversaries to exploit known weaknesses.		:3. '''Common Attack Pattern Enumeration and Classification (CAPEC)'''<ref name="MITRE_CAPEC">{{cite web \|url=https://capec.mitre.org/index.html \|title=CAPEC: Common Attack Pattern Enumeration and Classification \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref>: MITRE Corporation's CAPEC provides a comprehensive dictionary of known patterns of attack employed by adversaries to exploit known weaknesses.

	:4. '''Malware Attribute Enumeration and Characterization (MAEC)'''<ref ~~nae~~="MITRE_MAEC">{{cite web \|url=https://maecproject.github.io/ \|title=Malware Attribute Enumeraion and Characterization (MAEC) \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref> : MITRE Corporation's GitHub-based MAEC is a structured language used for encoding and sharing information about malware based upon attributes such as behaviors, artifacts, and relationships between malware samples. It facilitates correlation, integration, and automation of malware analysis and reduces potential duplication of malware during analysis.		:4. '''Malware Attribute Enumeration and Characterization (MAEC)'''<ref name="MITRE_MAEC">{{cite web \|url=https://maecproject.github.io/ \|title=Malware Attribute Enumeraion and Characterization (MAEC) \|author=MITRE Corporation \|date=2020 \|accessdate=03 March 2020}}</ref> : MITRE Corporation's GitHub-based MAEC is a structured language used for encoding and sharing information about malware based upon attributes such as behaviors, artifacts, and relationships between malware samples. It facilitates correlation, integration, and automation of malware analysis and reduces potential duplication of malware during analysis.

			:5. '''Managed Incident Lightweight Exchange (MILE)''': IETF's MILE working group develops standards to support computer and network security incident management, focusing on the definition of data formats for representing incident and indicator data, and on standardizing how application-layer protocols such as HTTPS and XMPP are utilized for sharing the structured data. Standards adopted by MILE include 1. IODEF v2 (Incident Object Description Exchange Format)<ref name="IETFTheIncident16">{{cite web \|url=https://tools.ietf.org/html/rfc7970 \|title=The Incident Object Description Exchange Format Version 2 \|author=Danyliw, R. \|publisher=Internet Engineering Task Force \|date=November 2016 \|accessdate=03 March 2020}}</ref><ref name="IETFIncidentObject17">{{cite web \|url=https://tools.ietf.org/html/rfc8274 \|title=Incident Object Description Exchange Format Usage Guidance \|author=Kampanakis, P.; Suzuki, M. \|publisher=Internet Engineering Task Force \|date=November 2017 \|accessdate=03 March 2020}}</ref>, an XML-based data representation of security incident reports and indicators designed to be compatible with IDMEF (Intrusion Detection Message Exchange Format) and capable of placing an IDMEF message into incident objects; and 2. Intrusion Detection Message Exchange Format (IDMEF)<ref name="IETFTheIntrusion07">{{cite web \|url=https://tools.ietf.org/html/rfc4765 \|title=The Intrusion Detection Message Exchange Format (IDMEF) \|author=Debar, H.; Curry, D.; Feinstein, B. \|publisher=Internet Engineering Task Force \|date=March 2007 \|accessdate=03 March 2020}}</ref>, an XML-based data format that is used by intrusion detection and response systems to report alerts about suspicious events.

			A comparison of the above CTII sharing technologies with respect to the data format and the types of data they can support is provided in Table 1.

			{\|
			\| STYLE="vertical-align:top;"\|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="100%"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3"\|'''Table 1.''' CTII technologies characteristics
			\|-
			\|-
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;"\|Technology
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;"\|Format
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;"\|Type of data
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|STIX1.x
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|XML
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|TTP, Threat Actor, Incident, Exploit Target, Course of Action, Report, Package
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|STIX2.x
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|JSON
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Attack Pattern, Campaign, Course of Action, Identity, Indicator, Intrusion Set, Malware, Observed Data, Report, Threat Actor, Tool, Vulnerability, Sighting
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|MISP
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|JSON
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Sighting, Threat Actor, Incident, Network Activity, Antivirus Detection, Hashes, Malware Sample, External Analysis, Traffic Light Protocol
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|CAPEC
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|XML
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Attack Pattern, Cross Site Forgery, SQL Injection, Buffer Overflow
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|MAEC
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|JSON
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Malware, Cyber Observable, Entity Association, Incident Management
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|IODEFv2
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|XML/HTML
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|Incident Management, Hashes, Indicator
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|IDMEF
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|XML
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\|IP Addresses, Malware, Alert, (Login, Date of Creation, Classification)
			\|-
			\|}
			\|}