Compare commits

...

52 Commits
v1.0 ... master

Author SHA1 Message Date
Alexandre Dulaunoy 819d2d089d
Merge pull request #18 from ldelavaissiere/patch-1
Update information_sharing_dora.md
2022-12-30 16:39:34 +01:00
Laurent de la V 610997017c
Update information_sharing_dora.md
Update further to publication of DORA's final text
2022-12-30 10:38:15 +01:00
Alexandre Dulaunoy 76820357f5
Merge pull request #17 from ldelavaissiere/master
Update README.md
2022-11-12 12:50:11 +01:00
Laurent de la V 1517e34b78
Update README.md
Proposal to link DORA document from the README
2022-11-12 12:44:15 +01:00
Alexandre Dulaunoy f0817f2fd8
Merge pull request #16 from ldelavaissiere/master
Create information_sharing_dora.md
2022-11-12 12:35:06 +01:00
Laurent de la V f3841a25c7
Create information_sharing_dora.md
Proposal to add an entry on DORA
2022-11-12 12:27:38 +01:00
Andras Iklody 04fa03c6bf
Some minor changes to the document 2022-09-27 11:25:47 +02:00
Christophe Vandeplas bbf3a28bc5
Merge pull request #15 from vpiserchia/master
Update README.md
2022-04-26 12:19:49 +02:00
vpiserchia 016e57f9aa
Update README.md
Removed duplicated section
2022-04-26 11:59:23 +02:00
Alexandre Dulaunoy fc48a43b48
chg: [doc] links clarified 2019-03-21 17:01:15 +01:00
Alexandre Dulaunoy 28be8959a1
chg: [Setting up ISAC] updated 2019-03-21 16:03:17 +01:00
Alexandre Dulaunoy 1bd02d44de
chg: [setting-up-ISACs] first version released 2019-03-21 11:28:30 +01:00
Alexandre Dulaunoy d0900c7b7c
chg: [doc] typo fixed 2019-02-27 13:14:14 +01:00
Alexandre Dulaunoy f34bbeb72a
add: PDF links to compliance document 2018-06-16 16:54:03 +02:00
Alexandre Dulaunoy 3251bbd868
add: PDF export of the NISD and MISP 2018-06-16 16:51:55 +02:00
Alexandre Dulaunoy cce80643bc
fix: metadata added for LaTeX + tables converted to Markdown 2018-06-16 16:51:18 +02:00
Alexandre Dulaunoy 4f44a6beea
add: PDF export of the ISO/IEC document 2018-06-16 16:31:38 +02:00
Alexandre Dulaunoy 0088e5ef30
fix: metadata added + all tables converted as Markdown tables 2018-06-16 16:30:48 +02:00
Alexandre Dulaunoy f80acd0428
add: PDF export of the GDPR document 2018-06-16 16:13:12 +02:00
Alexandre Dulaunoy 3a173b8c0e
add: PNG export added 2018-06-16 16:09:47 +02:00
Alexandre Dulaunoy 445eb0281c
fix: images and metadata for LaTeX generation 2018-06-16 16:09:02 +02:00
Alexandre Dulaunoy 433bd92205
fix: some glitches on the SVG 2018-06-16 16:06:34 +02:00
Alexandre Dulaunoy 9c0db4563a
fix: Diagram glitches 2018-06-16 16:03:05 +02:00
Alexandre Dulaunoy 59db8e2cdc
fix: SVG diagram glitches 2018-06-16 16:00:18 +02:00
Alexandre Dulaunoy 11797c66b9
add: export of SVG into PDF 2018-06-16 15:50:31 +02:00
Alexandre Dulaunoy 4ec4c84d73
fix: closing table ;-) 2018-04-18 15:27:16 +02:00
Alexandre Dulaunoy 0094d21fc0
NISD added 2018-04-18 15:17:47 +02:00
Alexandre Dulaunoy d5c59a6397
Merge pull request #13 from circlsupportuser/master
Initial commit of the NISD article and re-factoring of the GDPR article
2018-04-18 14:58:12 +02:00
circlsupportuser e8e31a2d69 How MISP enables stakeholders identified by the NISD to perform key activities 2018-04-18 11:28:02 +02:00
Alexandre Dulaunoy 13ce45a64a
Merge branch 'master' of github.com:MISP/misp-compliance 2018-04-08 16:11:59 +02:00
Alexandre Dulaunoy 1b54b81656
fix: MISP compliance ISO concept exported as PNG (for the crappy GitBook
issue)
2018-04-08 16:11:27 +02:00
circlsupportuser c953ad2c68 Merge remote-tracking branch 'upstream/master' 2018-04-05 11:16:36 +02:00
circlsupportuser 1334fc49b5 Refactor chapter on legal grounds
- Group thoughts related to legal grounds in the paragraph "What are the grounds for processing information for the purpose of information sharing?"
- Group thoughts related to GDPR principles in the paragraph "Does the GDPR allow CSIRTs to share information through MISP?"
- Add more details on the legal grounds available for CSIRTs and other actors involved in cybersecurity
- Correct some wordings
2018-04-05 11:14:16 +02:00
Alexandre Dulaunoy ed2535f9b4
Merge pull request #12 from circlsupportuser/master
Add taxonomy "infrastructure-state" for "Sensitivity reduction"
2018-03-26 17:18:37 +02:00
circlsupportuser fbbb8299f8 Merge remote-tracking branch 'upstream/master' 2018-03-26 16:51:00 +02:00
circlsupportuser 597320374e Add taxonomy "infrastructure-state" for "Sensitivity reduction" requirement 2018-03-26 16:44:16 +02:00
Alexandre Dulaunoy e3809f2321
Merge pull request #11 from remg427/master
Update README.md
2018-03-25 23:35:52 +02:00
remg427 675ff2b113
Update README.md 2018-03-25 22:40:25 +02:00
Alexandre Dulaunoy 964a240fa2
Merge pull request #10 from circlsupportuser/master
Additional taxonomies and feature for "Criticality" and "Sensitivity reduction"
2018-03-22 10:25:42 +01:00
Schneider 3985ccbd75 Merge remote-tracking branch 'upstream/master' 2018-03-22 10:08:19 +01:00
Schneider cb7514d2cc Additional taxonomies and feature for "Criticality" and "Sensitivity reduction" 2018-03-22 10:08:03 +01:00
Alexandre Dulaunoy 252d79168a
fix: typo fixed 2018-03-21 08:07:59 +01:00
Alexandre Dulaunoy 62a127c9d3
fix: main README updated including how to contribute to the project 2018-03-21 07:40:16 +01:00
Alexandre Dulaunoy d52ea592bc
fix: some missing <tr> 2018-03-20 15:03:30 +01:00
Alexandre Dulaunoy 1de9560623
fix: anchor fixed 2018-03-20 14:44:23 +01:00
Alexandre Dulaunoy 9d03c89816
fix: Alternative to electronic messaging are supported in MISP 2018-03-20 14:42:44 +01:00
Alexandre Dulaunoy 1634cdd4f5
Merge pull request #9 from circlsupportuser/master
MISP as supporting platform for sharing information, following ISO/IE…
2018-03-20 14:34:43 +01:00
Schneider 18505505c4 MISP as supporting platform for sharing information, following ISO/IEC 27010:2015 2018-03-20 12:54:16 +01:00
Alexandre Dulaunoy a4afbeb4eb
Merge pull request #8 from circlsupportuser/master
Additional thoughts related to issues #3 and #5
2018-01-29 23:14:40 +01:00
circlsupportuser 14246fff40 Additional thoughts related to issues #3 and #5 2018-01-29 11:17:00 -08:00
Alexandre Dulaunoy 47dc95bba1
fix: fix url and clean-up 2018-01-07 12:30:34 +01:00
Alexandre Dulaunoy fb7bf53de4
fix: ACM reference fixed 2018-01-07 12:25:55 +01:00
25 changed files with 10579 additions and 196 deletions

View File

@ -0,0 +1,66 @@
# Information sharing enabled by DORA
## Introduction
In light of the cyber threat landscape, European institutions have been working for a number of years on the development of new EU legislation to improve the operational and cyber resilience of the Union's financial sector. On 27<sup>th</sup> December 2022, the Official Journal of the European Union published the final text for **DORA**, a new EU Regulation on **digital operational resilience** for the financial sector _(Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector)_. This publication sets DORA to enter into application on 17<sup>th</sup> January 2025. A regulation is a legal act of the European Union that becomes immediately enforceable as law in all member states simultaneously.
DORA will apply to a very wide range of entities, including non-financial sector entities:
- Credit institutions (i.e., banks)
- Payment and electronic money institutions
- Account information service providers
- Investment firms
- Crypto-asset service providers as authorized under MiCA and issuers of asset-referenced tokens
- Central securities depositories
- Central counterparties
- Trading venues
- Trade repositories
- Managers of alternative investment funds
- Management companies
- Data reporting service providers
- Insurance and reinsurance undertakings
- Insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries
- Institutions for occupational retirement provision
- Credit rating agencies
- Administrators of critical benchmarks
- Crowdfunding service providers
- Securitisation repositories
- Critical ICT third-party service providers
## DORA provisions on information sharing
EU co-legislators have dedicated a chapter of DORA to information sharing in an effort to **reinforce the legal grounds** for information sharing arrangements on cyber threat information and intelligence. Under DORA's Art. 45:
**Art. 45(1) - Exchange of cyber threat information and intelligence**
Financial entities may exchange amongst themselves cyber threat information and intelligence, including indicators of compromise, tactics, techniques, and procedures, cyber security alerts and configuration tools, to the extent that such information and intelligence
sharing:
<ol type="a">
<li>aims to enhance the digital operational resilience of financial entities, in particular through raising awareness in relation to cyber threats, limiting or impeding the cyber threats ability to spread, supporting defence capabilities, threat detection techniques, mitigation strategies or response and recovery stages;</li>
<li>takes places within trusted communities of financial entities;</li>
<li>is implemented through information-sharing arrangements that protect the potentially sensitive nature of the information shared, and that are governed by rules of conduct in full respect of business confidentiality, protection of personal data and guidelines on competition policy.</li>
</ol>
**Art. 45(2) - Information sharing arrangements**
For the purpose of Art. 45(1)(c), the information sharing arrangements shall define the conditions for participation and, where appropriate, shall set out the details on the involvement of public authorities and the capacity in which the latter may be associated to the information-sharing arrangements, on the involvement of ICT third-party service providers, and on operational elements, including the use of dedicated IT platforms.
**Art. 45(3) - Notification to competent authorities**
Financial entities shall notify competent authorities of their participation in the information-sharing arrangements referred to in paragraph 1, upon validation of their membership, or, as applicable, of the cessation of their membership, once the latter takes effect.
## Relationship between DORA and the NIS2 Directive
As regards the interaction of DORA with the Network and Information Security (NIS) Directive (including its revision whose final text was published simultaneously to DORA's), financial entities will have full clarity on the different rules on digital operational resilience they need to comply with, in particular for those financial entities holding several authorisations and operating in different markets within the EU. The NIS directive continues to apply. DORA builds on the NIS Directive and addresses possible overlaps via a _lex specialis_ exemption.
## References
1. [EUR-Lex: Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2022.333.01.0001.01.ENG&toc=OJ%3AL%3A2022%3A333%3ATOC)
2. [French Presidency of the Council of the European Union; Digital finance: Provisional agreement reached on DORA](https://presidence-francaise.consilium.europa.eu/en/news/digital-finance-provisional-agreement-reached-on-dora/)
3. [Wikipedia article on Regulation (European Union)](https://en.wikipedia.org/wiki/Regulation_(European_Union))
4. [Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2022.333.01.0080.01.ENG&toc=OJ%3AL%3A2022%3A333%3ATOC)
## Contact and Collaboration
If you have any question or suggestion about this topic, feel free to [contact us](https://www.circl.lu/contact/). This document is a collaborative effort where external [contributors can propose changes and improvement](https://github.com/MISP/misp-compliance/tree/master/GDPR) the document.

View File

@ -1,23 +1,35 @@
---
title: "Information sharing and cooperation enabled by GDPR"
author: [CIRCL Computer Incident Response Center Luxembourg, MISP Project]
date: 2018-06-16
tags: [privacy, misp, information sharing, information exchange]
titlepage: true
toc-own-page: true
number-sections: true
titlepage-rule-color: EC2A3F
colorlinks: true
...
# Information sharing and cooperation enabled by GDPR
## Introduction
The General Data Protection Regulation (GDPR) aims to reduce legal uncertainty and limit the interpretations by setting out clear rules and conditions for the processing and sharing of personal data as well as the protection of natural persons with regard to the processing of personal data. Organisations must ensure that, they process only the minimum amount of personal data necessary to achieve their lawful processing purposes. To this end, the GDPR distinguishes the roles and obligations of data processors and data controllers, provides precise definitions of personal data and establishes the conditions under which information can be shared.
National and governmental Computer Security Incident Response Team (n/g CSIRTs) are teams that serve the government of a country by helping with Critical Information Infrastructure Protection (CIIP). They coordinate incident management with the relevant stakeholders at national level, and cooperate with the national and governmental teams in other countries. One of such CSIRTs is the Computer Incident Response Centre Luxembourg ([CIRCL](https://www.circl.lu/)), which has created and operated several communities to automate information sharing at national, European and international levels, supported by the [Malware Information Sharing and Threat Intelligence Sharing Platform (MISP)](https://www.misp-project.org/).
National and governmental Computer Security Incident Response Team (n/g CSIRTs) are teams that serve the government of a country by helping with Critical Information Infrastructure Protection (CIIP). They coordinate incident management with the relevant stakeholders at national level, and cooperate with the national and governmental teams in other countries.
MISP is a software for sharing, storing and correlating indicators of compromise of targeted attacks, cybersecurity threats and financial fraud indicators, among which SHA1 hashes (a cryptographic function to fingerprint files), threat actor names and Bitcoin addresses. The MISP data model is composed of "events", which usually represent threats or incidents, which in turn are composed of a list of "attributes" (e.g. IP addresses, domain names etc..). Other data models exist in MISP such as "objects", which allow advanced combinations of attributes and "galaxies" which enable a deeper analysis and categorisation of events. Information sharing communities are enabled using tools like MISP.
The [Malware Information Sharing and Threat Intelligence Sharing Platform (MISP)](https://www.misp-project.org/) is a software for sharing, storing and correlating indicators of compromise of targeted attacks, cybersecurity threats and financial fraud indicators, among which SHA1 hashes (a cryptographic function to fingerprint files), threat actor names and Bitcoin addresses. The MISP data model is composed of "events", which usually represent threats or incidents, which in turn are composed of a list of "attributes" (e.g. IP addresses, domain names etc..). Other data models exist in MISP such as "objects", which allow advanced combinations of attributes and "galaxies" which enable a deeper analysis and categorisation of events.
In this context of data exchanging the General Data Protection Regulation (GDPR) has a very influential role in defining what can be done, or not, with the data. Indeed, the GDPR aims to reduce legal uncertainty by setting out clear rules and conditions for the processing and sharing of personal data as well as the protection of natural persons with regard to the processing of personal data. Organisations must ensure that they process only the minimum amount of personal data necessary to achieve their lawful processing purposes. To this end, the GDPR distinguishes the roles and obligations of data processors and data controllers, provides precise definitions of personal data and establishes the conditions under which information can be shared.
Information sharing communities are enabled using tools like MISP. As a Computer Security Incident Response Team for the private sector communes and non-governmental entities in Luxembourg, CIRCL created and operates several communities to automate information sharing at national, European and international levels.
This article shows how MISP is aligned with the GDPR and how it is compliant with this key piece of legislation by explaining what information is exchanged in MISP. Having clarified key concepts of the GDPR: data controllers and processors, the article goes on by describing how both personal and non-personal data are exchanged in MISP. After that, the article explains the principles and the legal grounds by the stakeholders processing personal data, and shows how MISP aligns with that. Finally, a conclusion is provided.
## Who is the Controller and Processor when sharing information through MISP?
The GDPR clarifies the differences in the roles and responsibilities of data controllers and data processors. According to Art. 4(7), the **data controller** “determines the **purposes** and **means** of the processing of personal data”, either alone or in partnership with other data controllers (“joint controllers”).
The GDPR explains that roughly, in the processing of personal data there are controllers, joint controllers, and processors. According to Art. 4(7), the **data controller** “determines the **purposes** and **means** of the processing of personal data”, either alone or in partnership with other data controllers (“joint controllers”).
The concept of data controller and data processor in a sharing environment is not always trivial, but can be summarized in the below diagram.
The concept of data controller and data processor in a sharing environment is not always trivial, but can be summarized in the below diagram, which shows how the process takes place between entities A and B. In the diagram, we take the assumption that both A and B are controllers and they are not acting on behalf of someone else.
<img src="./misp-compliance-gdpr-peer-to-peer-pa.svg" alt="GDPR information sharing processing activities for a peer-to-peer network" style="width: 100%;"/>
![GDPR information sharing processing activities for a peer-to-peer network](./misp-compliance-gdpr-peer-to-peer-pa.svg.png)
*FIGURE 1: PROCESSING ACTIVITIES AND DATA CONTROLLER IN THE GENERAL CASE OF INFORMATION SHARING*
@ -30,7 +42,7 @@ More generally, in a peer-to-peer network, all the peers are separate data contr
Below is a use case of information sharing using the tool MISP:
<img src="./misp-compliance-gdpr-misp-pa.svg" alt="GDPR information sharing processing activities for MISP" style="width: 100%;"/>
![GDPR information sharing processing activities for MISP](misp-compliance-gdpr-misp-pa.svg.png)
*FIGURE 2: PROCESSING ACTIVITIES AND DATA CONTROLLER IN THE SPECIFIC CASE OF SHARING INFORMATION WITH MISP PLATFORM*
@ -47,46 +59,32 @@ In a distributed MISP setup, every entity using a MISP instance connected to oth
## What information exchanged through MISP is personal data?
Personal data is defined as “any information relating to an identified or identifiable natural person (data subject); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person” (Art. 4(1), GDPR).
Article 4(1)of the GDPR defines “personal data” as “any information relating to an identified or identifiable natural person (data subject); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”. This definition is all encompassing and broad because it includes any information relating to an identified individual (i.e. which makes such info personal to that individual), or any information relating to someone who could be identified based on a variety of identifiers.
MISP serves a variety of actors from the public and private sector, therefore the categories of personal data exchanged may vary depending on the type of **actors involved** and the **purpose** of data processing (e.g. information sharing for the purpose of exposing financial fraud may include bank accounts or credit card numbers).
Indeed, in the specific case of MISP, the first purpose of the share information processing activity is not to share personal data but rather Indicators of Compromise (IOCs), pieces of forensic data that identify potentially malicious activity on a system or network that mostly relate to threat actors or threat actor groups. Nevertheless, as these IOCs may contain or not personal data, it can be said that at least a part of the data exchanged in MISP will be personal data.
It is particularly important to note that **IP addresses can be considered as personal data** as they can allow data subjects to be identified (ECJ, Scarlet Extended case). Moreover, unless the controller is able to establish with certainty that the data do not correspond to data subjects that can be identified, the controller will have to treat all IP information as personal data (WP29, Opinion 1/2008). Dynamic IP addresses in some cases are also personal data, sometimes even when only the ISPs are in possession of additional data and able to identify the data subject, only if the data controller or processor has legal means — without disproportionate effort — of obtaining access to the information help by the ISP (ECJ, Patrick Breyer case). The mentioned landmark case provides for the criteria to be used to determine whether dynamic IP addresses qualify as personal data.
It is important to notice here that the identification of a piece of information as personal or not personal data is not as straightforward as it may look. For example, **IP addresses can be considered as personal data** as they can allow data subjects to be identified (ECJ, Scarlet Extended case). Moreover, unless the controller is able to establish with certainty that the data do not correspond to data subjects that can be identified, the controller will have to treat all IP information as personal data (WP29, Opinion 1/2008). Dynamic IP addresses in some cases are also personal data, sometimes even when only the ISPs are in possession of additional data and able to identify the data subject, actors involved have legal means — without disproportionate effort — of obtaining access to the information help by the ISP (ECJ, Patrick Breyer case). The mentioned landmark case provides for the criteria to be used to determine whether dynamic IP addresses qualify as personal data. If there are legal channels available by which the party can identify the individual, the court held that the party managing the data should be regarded as having the means reasonably likely to be used to identify the individual.
In the specific case of MISP used by CSIRTs, the first purpose of the share information processing activity is not to share personal data but rather IOCs mostly related to threat actors or threat actor groups. However, in most cases these IOCs contain personal data. Therefore, when exchanging personal data, **CSIRTs should be aware of their mandate, the mandate of the involved parties, as well as the data processing purposes to the fullest possible extent**.
Having this in mind, the figure below illustrates the MISP categories of data that could be exchanged through MISP which may include personal data in some cases.
One of the safeguards mentioned in the GDPR is pseudonymisation, defined as "the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information [..]". In MISP, event attributes are not linked to each other and usually do not enable the identification a data subject by themselves, without additional information. For example, having only an IP address, is usually not enough to identifiy a data subject without additional information from the ISP. As such, most of the event attributes can be considered as pseudonymised.
This statement should however be balanced, as specific attributes can sometimes by themselves enable an easier identification than others, such as the attribute "passport-number" or even a domain name in case the whois public database contains enough information. Furthermore, the "object" data model in MISP enables linking attributes to each other. Specifically the "person", "victim" and even the "whois" objects to name a few, can break the MISP pseudonymisation characteristic for specific sets of data. Those attributes and objects should be used and shared more carefully, in line with the legitimate purpose of the processing activity.
The figure below illustrates the MISP categories of data that could be exchanged through MISP which may include personal data in some cases.
<p align="center">
<img src="./misp-compliance-gdpr-personal-data.svg" alt="GDPR information sharing personal data in MISP per categories" style="width: 70%;"/>
</p>
![GDPR information sharing personal data in MISP per categories](./misp-compliance-gdpr-personal-data.svg.png)
*FIGURE 3: EXAMPLE OF MISP ATTRIBUTE CATEGORIES POTENTIALLY INVOLVING PERSONAL DATA (NON-EXHAUSTIVE)*
Currently, most of the MISP functionalities (i.e. attribute categories and types) for sharing data does not provide sharing data of special categories as defined in the GDPR (Art. 9), i.e. data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation. As an exception, Passenger Name Record (PNR), which may be considered in certain cases as special category of personal data, are supported by MISP.
Currently, most of the MISP functionalities (i.e. attribute categories and types) for sharing data do not provide sharing data of special categories as defined in the GDPR (Art. 9), i.e. data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation. As an exception, Passenger Name Record (PNR), which may be considered in certain cases as special category of personal data, are supported by MISP.
However, specifically in the case of CSIRTs sharing IOCs through MISP, the processing activities involving sharing information are unlikely to involve special categories of personal data in order to fulfil their mandated purposes. It is not unlikely though, that future release of MISP and needs of CSIRTs would involve sharing such special categories.
Moreover, in MISP, some of the information exchanged can be considered as **pseudonymised** as per defined by the GDPR. Indeed, one of the safeguards mentioned in the GDPR is pseudonymisation, defined in Art. 4(5) as "the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information [..]". In MISP, event's attributes are not linked to each other and usually do not enable the identification a data subject by themselves, without additional information. For example, having only an IP address, is usually not enough to identify a data subject without additional information from the ISP. As such, most of the event attributes can be considered as pseudonymised.
This statement should however be balanced, as specific attributes can sometimes by themselves enable an easier identification than others, such as the attribute "passport-number" or even a domain name in case of the whois public database contains enough information. Furthermore, the "object" data model in MISP enables linking attributes to each other. Specifically the "person", "victim" and even the "whois" objects to name a few, can break the MISP pseudonymisation characteristic for specific sets of data. Those attributes and objects should be used and shared more carefully, in line with the legitimate purpose of the processing activity.
## Does the GDPR allow CSIRTs to share information through MISP?
It is a common misconception that the GDPR decreases the possibility to share information between CSIRTs. The GDPR actually allows information exchange of personal data between CSIRTs as long as it is consistent with its purposes.
The GDPR explains that a processing activity should comply with the six principles in Art. 5, which could be summarized as: "lawfulness, fairness and transparency", "purpose limitation", "data minimisation", "accuracy", "storage limitation" and "integrity and confidentiality".
It is a common misconception that the GDPR decreases the possibility to share information between CSIRTs. The GDPR actually enables information exchange of personal data between CSIRTs as long as it is consistent with its purposes. **Recital 49 of the GDPR confirms that CSIRTs are encouraged to share information** provided that the processing **1)** is performed “to extent **necessary and proportionate for purposes of ensuring network and information security**” such as ensuring that the confidentiality, integrity and availability of the personal data stored or transmitted and the security of the related systems is preserved and **2) constitutes a legitimate interest of the data controller**, such as preventing unauthorised access to electronic communication networks and malicious code distribution or “denial of service” attacks. Additionally, recital 32 states that controllers and processors shall “implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk”. Information sharing has to be perceived as essential security measure to lower the risk.
One can doubt that all entities and companies that work with cybersecurity are allowed to process personal data without having any distinction between CSIRTs and private providers of security services and technologies. Basically, everybody directly or indirectly involved in detecting or helping to detect IT incidents and cyber-attacks could potentially process large sets of personal data legitimately.
First, we need to assess the legal value of recitals in a Regulation. They are not directly enforceable like the proper articles of a Regulation, but they help with the interpretation of the articles of the Regulation. The recital, together with the articles of the Regulation, means that CSIRTS and other subjects involved with cybersecurity can process personal data, provided that all rules are respected, such as the principles of necessity and proportionality.
Second, the recital indeed points out that the processing of personal data is allowed “to the extent strictly necessary and proportionate for the purposes of ensuring network and information security”. The data controller can process personal data only when it is really necessary to do it and according to the purposes of its activities towards its constituency. Therefore, while CSIRTs have a legitimate ground to process personal data that are necessary to fulfill their tasks, other private actors such as cybersecurity software vendors will have much less freedom to process personal data. The ultimate purpose of recital 49 is not to grant a general possibility to process personal data to all actors involved with cybersecurity but to assure that network and information security is achieved at the highest possible extent.
The tasks to verify the correct application of recital 49 by CSIRTs is given primarily to the courts when they will assess the value of the evidence collected and exchanged by the CSIRTs. The Data Protection Authorities (DPAs) may be also confronted with this issue, e.g. in the framework of investigations. However, recital 49 is a guideline and a legal interpretation tool rather than a prescriptive provision.
A processing activity should comply with the six principles in Art. 5, which could be summarized as: "lawfulness, fairness and transparency", "purpose limitation", "data minimisation", "accuracy", "storage limitation" and "integrity and confidentiality". The first step is to make sure the processing activity is lawful.
For the processing activities for which CSIRTs act as data controllers, the lawful grounds for processing might be based on the Art. 6 (e) - processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller. Entities in an information sharing community may have different lawful grounds as described in Art. 6. However, whenever sharing is lawful, it should not be discouraged by these differences, and entities should state clearly their lawful grounds to enhance sharing.
When sharing information through MISP, personal data has usually not been obtained from the data subject. For example, when sharing information about a new malware (e.g. the domain name the malware is receiving instructions from), such information has not been obtained from the author of the malware. Instead, it is a result of the analysis thereof. In this case, Art. 14 triggers the application of the **transparency principle**. This article, requires that specific information, such as identity and contact details of the controller, is provided to the data subject. However, one can argue that providing such information to threat actors can jeopardise an investigation and not be in the public interest. The GDPR has foreseen such use cases and provides exceptions to Art. 14(1) to (4). Specifically in the case of MISP usages, Art. 14(5)(b) is the most relevant, stating that Art. 14(1) to (4) shall not apply if “the obligation referred to in paragraph 1 of this Article is likely to render impossible or seriously impair the achievement of the objectives of that processing”. This restriction needs however, to be balanced with “appropriate measures” such as “making the information publicly available”. For example, CSIRTs could make information about their processing activities publicly available in line with RFC 2350 and GDPR Art. 14(1) and (2).
In most cases, data input in MISP directly relate to an attack, and are already specifically selected from the large amount of data analysed during an incident, for being useful to detect and/or mitigate the attack. In those cases, MISP usage satisfies the **data minimisation principle and the purpose limitation principle**. MISP also includes features to assess the usefulness of IOCs for threat detection and/or mitigation. For example, the field "IDS" in the "attribute" data model allows attributes to be exported directly to the intrusion detection system of one's network. It is easily understandable that attributes marked as "IDS" are necessary to detect and/or mitigate the threat. Other fields can be mentioned such as "Sightings", allowing other organisations to react on the relevance of the specific attribute, and "Related Events" showing which event(s) also include the same attribute (if an attribute is included in several events, it is most likely not a false positive, and therefore relevant to mitigate the related threat).
@ -95,27 +93,57 @@ In the case where an entity no longer needs specific attributes in MISP, the ent
## What are the grounds for processing information for the purpose of information sharing?
Under the GDPR, CSIRTs have the legal grounds for processing and sharing of information if “the data subject has given **consent** to processing for one or more specific purposes” (Art. 6(1)) or if **other legal grounds** apply. For example, CSIRTs can process personal data if it is necessary for the **performance of a contractual agreement** with the data subject. However, obtaining consent of the data subject is in many cases not feasible in practice and often impossible or illogical to obtain, but the policies of some CSIRTs provide that it is required when the data subject is the victim or target of a threat. In those cases where the consent is the legal ground for data processing, the specific conditions as prescribed by the GDPR should be followed: the consent should be freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of his or her personal data, The consent must be given by a statement or a clear affirmative action. Nonetheless, the data controller should be able to demonstrate it (Art. (7) Conditions for consent).
One can doubt that all entities and companies that work with cybersecurity have the same legal grounds to process personal data without having any distinction between CSIRTs and private providers of security services and technologies.
The GDPR allow for six possibilities of legal grounds for a processing activity. For the processing activities related to "information sharing", there is no default legal ground and determination of those grounds should be done on a case-by-case basis.
Furthermore, CSIRTs can process personal data without having obtained prior consent if they have **the legal obligation** to do so, in accordance with the powers and responsibilities set out in their mandate and with their constituency. It is nevertheless important to note that information sharing is not compulsory and under some mandates, CSIRTs may only be able to collect and process personal data for internal purposes.
### Information sharing in the scope of cybersecurity
Alternatively, CSIRTs can process personal data if acting under a specific mandate or delegation from an official authority to **protect public interests** (e.g. public or national security) or **if in the framework of a criminal investigation**. However the GDPR does not apply to such matters.
For example, in the case of CSIRTs sharing information, the legal ground would most likely be either Art. 6(1)(f) **“legitimate interest”** (as mentioned in Recital 49), Art. 6(1)(c) **“compliance with legal obligation”** or Art. 6(1)(e) **“public interest”**. Private or internal CSIRTs monetizing their services would probably use legitimate interest as a legal ground while CSIRTs who need to comply with the Network and Information System Directive (NISD), and/or whose mandate is defined by Law, would most likely use “public interest”.
In addition, Recital 49 explicitly refers to CSIRTs right to process personal data provided that they have a **legitimate interest** and that such interests are not overridden by the fundamental rights and freedoms of data subjects. Collecting and processing information related to incidents and threats constitutes a legitimate interest for CSIRTs as it is aligned with the purpose and scope of most CSIRTs mandates. Indeed, sharing information will enable CSIRTs to better prevent and mitigate attacks by, for example, identifying compromised machines or infected victims and blocking malicious IPs.
![GDPR grounds to process personal data](./misp-compliance-gdpr-grounds.pdf.png)
However, in the light of the purpose limitation principle, CSIRTs do not have a lawful basis for using data obtained during a criminal investigation for other purposes not related to the investigation or retaining data for longer than is necessary for the purposes for which the personal data are processed.
*FIGURE 4: LEGAL GROUNDS FOR CSIRTs WHICH CAN ENABLE A DATA CONTROLLER OR PROCESSOR TO PROCESS PERSONAL DATA*
Information sharing is not only key in the cybersecurity sector, but also in other sectors such as the Financial and Telecom sectors, to increase fraud detection. For example, payment service providers have the legal grounds for processing and sharing of information under the Payment Services Directive (PSD 1) and the revised Directive (PSD 2). Specifically, in recitals (49) of the PSD 1 directive, "provision should be made for the efficient exchange of data between payment service providers who should be allowed to collect, process and exchange personal data relating to persons involved in payment fraud". In the revised Payment Services Directive, Article 94 also mentions that "Member States shall permit processing of personal data by payment systems and payment service providers when necessary to safeguard the prevention, investigation and detection of payment fraud".
In the following paragraphs, four legal grounds which could be used for **information sharing of personal data in the general purpose of ensuring network and information security** will be detailed. Relevant entities for that purpose such as CSIRTs are not limited to those legal grounds. For example, CSIRTs can share personal data if it is necessary for the performance of a contractual agreement with the data subject. The following paragraphs will mainly focus on CSIRTs, but can also be applicable to entities desired to ensure their network and information security.
<p align="center">
<img src="./misp-compliance-gdpr-grounds.svg" alt="GDPR grounds to process personal data" style="width: 70%;"/>
</p>
#### Art. 6(1)(a) - Consent
*FIGURE 4: LEGAL GROUNDS WHICH CAN ENABLE A DATA CONTROLLER OR PROCESSOR TO PROCESS PERSONAL DATA*
Under the GDPR, relevant entities such as CSIRTs may use the legal ground for processing and sharing of information if “the data subject has given consent to processing for one or more specific purposes” (Art. 6(1)). However, obtaining consent of the data subject is in many cases **not feasible in practice** and often impossible or illogical to obtain, but the policies of some CSIRTs provide that it is required when the data subject is the victim or target of a threat. In those cases where the consent is the legal ground for data processing, the specific conditions as prescribed by the GDPR should be followed: the consent should be freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of his or her personal data, The consent must be given by a statement or a clear affirmative action. Nonetheless, the data controller should be able to demonstrate it (Art. 7 Conditions for consent).
#### Art. 6(1)(c) - Legal obligation
CSIRTs can process personal data without having obtained prior consent if they have the legal obligation to do so, in accordance with the powers and responsibilities set out in their mandate and with their constituency. It is nevertheless important to note that information sharing is not compulsory and under some mandates, CSIRTs may only be able to collect and process personal data for internal purposes.
#### Art. 6(1)(e) - Public interest
Alternatively, CSIRTs can process personal data if acting under a specific mandate or delegation from an official authority to protect public interest. More details on Art. 6(1)(e) can be found in Recital 45 which states that "where processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority, **the processing should have a basis in Union or Member State law**". Therefore, if CSIRTs want to use Art. 6(1)(e) as a legal ground for their processing activities, they need to prove that these processing activities are based on a law, such as a mandate defined by a Member State law or the NIS Directive.
In the case of information sharing in the framework of a criminal investigation, related processing activities are outside of the scope of the GDPR, and of EU law, because it is mainly the national law the one that applies to such matters. It is important to notice here that in the light of the purpose limitation principle, CSIRTs do not have a lawful basis for using data obtained during a criminal investigation for other purposes not related to the investigation or retaining data for longer than is necessary for the purposes for which the personal data are processed.
#### Art. 6(1)(f) - Legitimate interest
In addition, **Recital 49** explicitly refers to CSIRTs right to process personal data provided that they have a legitimate interest and that such interests are not overridden by the fundamental rights and freedoms of data subjects. Collecting and processing information related to incidents and threats constitutes a legitimate interest for CSIRTs as it is aligned with the purpose and scope of most CSIRTs mandates. Indeed, sharing information will enable CSIRTs to better prevent and mitigate attacks by, for example, identifying compromised machines or infected victims and blocking malicious IPs.
Recital 49 of the GDPR also gives a clear lawful ground to any other entity desired to ensure their network and information security provided that the processing **1)** is performed “**to extent necessary and proportionate for purposes of ensuring network and information security**” such as ensuring that the confidentiality, integrity and availability of the personal data stored or transmitted and the security of the related systems is preserved and **2) constitutes a legitimate interest of the data controller**, such as preventing unauthorised access to electronic communication networks and malicious code distribution or “denial of service” attacks.
Moreover, recital 32 states that controllers and processors shall “implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk”.
In those two cases, information sharing has to be perceived as essential security measure to lower the risk.
First, we need to assess the legal value of recitals in a Regulation. They are not directly enforceable like the proper articles of a Regulation, but they help with the interpretation of the articles of the Regulation. The recital, together with the articles of the Regulation, means that CSIRTS and other subjects involved with cybersecurity can process personal data, provided that all rules are respected, such as the principles of necessity and proportionality.
Second, the recital indeed points out that the processing of personal data is allowed “to the extent strictly necessary and proportionate for the purposes of ensuring network and information security”. The data controller can process personal data only when it is really necessary to do it and according to the purposes of its activities towards its constituency. Therefore, while CSIRTs have a legitimate ground to process personal data that are necessary to fulfill their tasks, other private actors such as cybersecurity software vendors will have much less freedom to process personal data. The ultimate purpose of recital 49 is not to grant a general possibility to process personal data to all actors involved with cybersecurity but to assure that network and information security is achieved at the highest possible extent.
The tasks to verify the correct application of recital 49 by CSIRTs is given primarily to the courts when they will assess the value of the evidence collected and exchanged by the CSIRTs. The Data Protection Authorities (DPAs) may be also confronted with this issue, e.g. in the framework of investigations. However, recital 49 is a guideline and a legal interpretation tool rather than a prescriptive provision.
### Information sharing in other sector specific legislations
Information sharing is not only mentioned by the GDPR, but also by other legislations for more specific sectors such as the Financial sector, for example to increase fraud detection.
Payment service providers are encouraged to process and share information under the Payment Services Directive (PSD 1) and the revised Directive (PSD 2). Specifically, in recitals (49) of the PSD 1 directive, "provision should be made for the efficient exchange of data between payment service providers who should be allowed to collect, process and exchange personal data relating to persons involved in payment fraud". In the revised Payment Services Directive, Art. 94 also mentions that "Member States shall permit processing of personal data by payment systems and payment service providers when necessary to safeguard the prevention, investigation and detection of payment fraud". Even if the requirement concerning the “sharing of the information on security and operational risks” has been removed from the revised directive, payment service providers (PSPs) are still encouraged to share such information as mentioned in the European Bank Authority (EBA) guidelines on security measures for PSD 2. Specifically Art. 39 of these guidelines mention that “[..] The EBA would nevertheless encourage all PSPs to participate in any platforms enabling the exchange of information on operational and security risks and threat intelligence with other PSPs and relevant third parties such as operators of payment systems, industry associations, etc., as long as these initiatives comply with applicable EU law, such as Directive (EU) 2015/2366 and Regulation (EU) 2016/679 or, if applicable, Regulation (EC) 45/2001 [..].”
## Conclusion
The GDPR provides a new data protection framework that will allow information sharing, based on clear rules and conditions. CSIRTs are encouraged to collect, process and exchange personal data as long as it is performed within their legitimate interest. Information sharing is a powerful mechanism for successful identification and handling of incidents, in the cybersecurity, financial and telecoms sectors among others and will have a key role in the future of fraud detection and incident handling.
The GDPR provides a new data protection framework that will allow information sharing, based on clear rules and conditions. CSIRTs are allowed to collect, process and exchange personal data as long as they have a lawful ground to do it and that the processing is aligned with the GDPR principles.
Information sharing is a powerful mechanism for successful identification and handling of incidents, in the cybersecurity, financial and telecoms sectors among others and will have a key role in the future of fraud detection and incident handling.
## References
@ -126,9 +154,9 @@ The GDPR provides a new data protection framework that will allow information sh
5. [Article 29 Working Party, Opinion 1/2008 on data protection issues related to search engines.](http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2008/wp148_en.pdf)
6. [ECJ, Patrick Beyer case](https://curia.europa.eu/jcms/upload/docs/application/pdf/2016-10/cp160112en.pdf)
7. [Mandate for the "security made in Létzebuerg” (SMILE) gie.](https://www.circl.lu/assets/files/letter-circl-2015.pdf)
8. Cynthia Wagner, Alexandre Dulaunoy, Gérard Wagener, and Andras Iklody. Misp: The design and implementation of a collaborative threat intelligence sharing platform. In *Proceedings of the 2016 ACM on Workshop on Information Sharing and Collaborative Security,* page 49-56. ACM, 2016.
8. Cynthia Wagner, Alexandre Dulaunoy, Gérard Wagener, and Andras Iklody. [MISP: The design and implementation of a collaborative threat intelligence sharing platform](https://www.foo.be/papers/misp.pdf). In *Proceedings of the 2016 ACM on Workshop on Information Sharing and Collaborative Security,* page 49-56. ACM, 2016.
9. [Andrew Cormack. Incident Response: Protecting Individual Rights Under the General Data Protection Regulation, Dec. 2016](https://script-ed.org/article/incident-response-protecting-individual-rights-under-the-general-data-protection-regulation/)
10. [European Banking Authority, “Guidelines on the security measures for operational and security risks of payment services under Directive (EU) 2015/2366 (PSD2)”, 12/12/2017](http://www.eba.europa.eu/-/eba-publishes-final-guidelines-on-security-measures-under-psd2)
## Acknowledgment
@ -139,12 +167,3 @@ This document was partially funded by CEF (Connecting Europe Facility) funding u
## Contact and Collaboration
If you have any question or suggestion about this topic, feel free to [contact us](https://www.circl.lu/contact/). This document is a collaborative effort where external [contributors can propose changes and improvement](https://github.com/MISP/misp-compliance/tree/master/GDPR) the document.

Binary file not shown.

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

View File

@ -16,8 +16,11 @@
viewBox="0 0 229.2583 171.60898"
version="1.1"
id="svg8"
inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"
sodipodi:docname="misp-compliance-gdpr-misp-pa.svg">
inkscape:version="0.92.1 r15371"
sodipodi:docname="misp-compliance-gdpr-misp-pa.svg"
inkscape:export-filename="/home/adulau/git/misp-compliance/GDPR/misp-compliance-gdpr-misp-pa.svg.png"
inkscape:export-xdpi="100"
inkscape:export-ydpi="100">
<defs
id="defs2">
<linearGradient
@ -231,15 +234,15 @@
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.98994949"
inkscape:cx="422.07027"
inkscape:cx="250.84941"
inkscape:cy="353.66295"
inkscape:document-units="mm"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1920"
inkscape:window-height="1000"
inkscape:window-x="-11"
inkscape:window-y="-11"
inkscape:window-height="1056"
inkscape:window-x="0"
inkscape:window-y="24"
inkscape:window-maximized="1"
fit-margin-top="0"
fit-margin-left="0"
@ -269,8 +272,8 @@
transform="translate(-5.5521094,-23.462714)">
<path
id="path3727"
d="m 56.446838,171.02316 h 39.003915 v 22.7028 H 56.446838 Z"
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.30000001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:1.8, 1.8;stroke-dashoffset:0;stroke-opacity:1"
d="m 50.328069,171.86414 h 45.661232 v 22.67838 H 50.328069 Z"
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.32441977;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:1.94651847, 1.94651847;stroke-dashoffset:0;stroke-opacity:1"
inkscape:connector-curvature="0" />
<path
id="path3823"
@ -868,79 +871,75 @@
dy="0"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.17499995px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
id="tspan4051">MISP event</tspan></tspan></text>
<g
id="g6742"
transform="translate(-4.2333335,-7.4083337)">
<path
id="path4085"
d="M 10.441719,82.658089 V 104.01242 H 61.666943 V 82.658089 Z"
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.26458332"
inkscape:connector-curvature="0" />
<path
id="path4087"
d="M 9.9113733,83.223574 H 61.659512 V 103.97169 H 9.9113733 Z"
style="fill:none;stroke:#000000;stroke-width:0.25186074px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
id="text4093"
y="88.107002"
x="12.492154"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
xml:space="preserve"><tspan
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"
id="tspan4091"
y="88.107002"
x="12.492154"
sodipodi:role="line"><tspan
id="tspan4089"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
dy="0"
dx="0">Processing Activity: Share </tspan></tspan><tspan
id="tspan1384"
<path
inkscape:connector-curvature="0"
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.28000909"
d="M 6.2083855,75.249755 V 96.604086 H 63.580809 V 75.249755 Z"
id="path4085" />
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:0.26990625px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 6.5443674,75.824263 H 66.025277 v 20.73007 H 6.5443674 Z"
id="path4087" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
x="11.154056"
y="80.698669"
id="text4093"><tspan
sodipodi:role="line"
x="11.154056"
y="80.698669"
id="tspan4091"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"><tspan
dx="0"
dy="0"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
y="92.957695"
x="12.492154"
sodipodi:role="line">information </tspan></text>
<text
id="text4111"
y="97.428436"
x="12.492154"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
xml:space="preserve"><tspan
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"
id="tspan4109"
y="97.428436"
x="12.492154"
sodipodi:role="line"><tspan
id="tspan4107"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
dy="0"
dx="0">Data controller: Entity B </tspan></tspan></text>
<text
id="text4123"
y="102.0891"
x="12.492154"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
xml:space="preserve"><tspan
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"
id="tspan4121"
y="102.0891"
x="12.492154"
sodipodi:role="line"><tspan
id="tspan4119"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
dy="0"
dx="0">Recipient: Entity A</tspan></tspan></text>
</g>
id="tspan4089">Processing Activity: Share </tspan></tspan><tspan
sodipodi:role="line"
x="11.154056"
y="85.549362"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
id="tspan1384">information </tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
x="9.4695768"
y="90.020103"
id="text4111"><tspan
sodipodi:role="line"
x="9.4695768"
y="90.020103"
id="tspan4109"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"><tspan
dx="0"
dy="0"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
id="tspan4107">Data controller: Entity B </tspan></tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
x="18.203671"
y="94.680771"
id="text4123"><tspan
sodipodi:role="line"
x="18.203671"
y="94.680771"
id="tspan4121"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"><tspan
dx="0"
dy="0"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
id="tspan4119">Recipient: Entity A</tspan></tspan></text>
<path
inkscape:connector-curvature="0"
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.26458332"
d="m 166.17109,28.3545 v 16.693742 h 51.18285 V 28.3545 Z"
d="M 166.17109,29.690848 V 46.38459 h 51.18285 V 29.690848 Z"
id="path4125" />
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:0.25909996px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 166.17353,28.35694 h 53.18249 v 16.688862 h -53.18249 z"
style="fill:none;stroke:#000000;stroke-width:0.29243097px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 166.1902,28.373606 h 58.49455 V 47.701832 H 166.1902 Z"
id="path4127" />
<text
xml:space="preserve"
@ -978,7 +977,7 @@
dx="0"
dy="0"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
id="tspan4147">Data controller: Entity A </tspan></tspan></text>
id="tspan4147">Data controller: Entit</tspan></tspan></text>
<path
inkscape:connector-curvature="0"
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.26458332"
@ -986,27 +985,28 @@
id="path4159" />
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:0.25161341px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 159.92795,75.190155 h 51.74839 v 20.748339 h -51.74839 z"
id="path4161" />
style="fill:none;stroke:#000000;stroke-width:0.28085944px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 159.94257,75.204778 h 56.21793 6.72654 V 96.45841 h -62.94447 z"
id="path4161"
sodipodi:nodetypes="cccccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
x="162.50256"
y="79.932098"
y="79.39756"
id="text4167"><tspan
sodipodi:role="line"
x="162.50256"
y="79.932098"
y="79.39756"
id="tspan4165"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"><tspan
dx="0"
dy="0"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
id="tspan4163">Processing Activity: Share </tspan></tspan><tspan
id="tspan4163">Processing Activity: Share</tspan></tspan><tspan
sodipodi:role="line"
x="162.50256"
y="84.782791"
y="84.248253"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
id="tspan1416"><tspan
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start"
@ -1125,11 +1125,6 @@
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.26458332"
d="m 8.0086483,170.11401 v 16.69374 H 59.191499 v -16.69374 z"
id="path4199" />
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:0.25421941px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 8.0086483,169.91664 H 59.191499 v 16.69373 H 8.0086483 Z"
id="path4201" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
@ -1172,8 +1167,8 @@
id="path4233" />
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:0.25421941px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 163.35482,169.91663 h 51.22521 v 16.69374 h -51.22521 z"
style="fill:none;stroke:#000000;stroke-width:0.27135682px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 163.36339,169.9252 h 58.42435 v 16.6766 h -58.42435 z"
id="path4235" />
<text
xml:space="preserve"
@ -1399,6 +1394,11 @@
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;stroke-width:0.26458332"
dy="0"
dx="0">Data controller: Entity A</tspan></tspan></text>
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:0.2664063px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 8.0147417,169.92273 H 64.263527 v 16.68155 H 8.0147417 Z"
id="path4201" />
</g>
<g
inkscape:groupmode="layer"

Before

Width:  |  Height:  |  Size: 122 KiB

After

Width:  |  Height:  |  Size: 122 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 149 KiB

View File

@ -15,8 +15,11 @@
viewBox="0 0 243.41629 98.505377"
version="1.1"
id="svg8"
inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"
sodipodi:docname="misp-compliance-gdpr-peer-to-peer-pa.svg">
inkscape:version="0.92.1 r15371"
sodipodi:docname="misp-compliance-gdpr-peer-to-peer-pa.svg"
inkscape:export-filename="/home/adulau/git/misp-compliance/GDPR/misp-compliance-gdpr-peer-to-peer-pa.svg.png"
inkscape:export-xdpi="100"
inkscape:export-ydpi="100">
<defs
id="defs2">
<clipPath
@ -384,16 +387,16 @@
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="3.959798"
inkscape:cx="234.02633"
inkscape:zoom="0.93"
inkscape:cx="191.22112"
inkscape:cy="302.48691"
inkscape:document-units="mm"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1920"
inkscape:window-height="1000"
inkscape:window-x="-11"
inkscape:window-y="-11"
inkscape:window-height="1056"
inkscape:window-x="0"
inkscape:window-y="24"
inkscape:window-maximized="1" />
<metadata
id="metadata5">
@ -578,8 +581,8 @@
inkscape:connector-curvature="0" />
<path
id="path1924"
d="m 78.002177,64.356971 h 71.940843 v 16.73361 H 78.002177 Z"
style="fill:none;stroke:#000000;stroke-width:0.26639119px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 78.011979,64.366773 H 161.02865 V 81.080779 H 78.011979 Z"
style="fill:none;stroke:#000000;stroke-width:0.28599614px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
id="text1930"
@ -633,8 +636,8 @@
inkscape:connector-curvature="0" />
<path
id="path1946"
d="M -8.2271192,73.421771 H 44.822052 V 90.110954 H -8.2271192 Z"
style="fill:none;stroke:#000000;stroke-width:0.2587775px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M -8.220427,73.428463 H 50.505324 V 90.104262 H -8.220427 Z"
style="fill:none;stroke:#000000;stroke-width:0.27216187px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
id="text1952"
@ -675,23 +678,23 @@
dx="0">Data controller: Entity A</tspan></tspan></text>
<path
id="path1972"
d="m 183.74984,111.73223 v 16.69374 h 51.18283 v -16.69374 z"
d="m 175.21489,121.68967 v 16.69374 h 51.18283 v -16.69374 z"
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.26458332"
inkscape:connector-curvature="0" />
<path
id="path1974"
d="m 183.74984,111.73223 h 51.18283 v 16.69374 h -51.18283 z"
style="fill:none;stroke:#000000;stroke-width:0.25421941px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 175.2217,121.69648 h 56.85918 V 138.3766 H 175.2217 Z"
style="fill:none;stroke:#000000;stroke-width:0.26783642px;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
id="text1980"
y="116.6585"
x="186.31981"
y="126.61594"
x="177.78487"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
xml:space="preserve"><tspan
id="tspan1978"
y="116.6585"
x="186.31981"
y="126.61594"
x="177.78487"
sodipodi:role="line"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"><tspan
id="tspan1976"
@ -700,13 +703,13 @@
dx="0">Processing Activity: </tspan></tspan></text>
<text
id="text1986"
y="116.6585"
x="221.2506"
y="126.61594"
x="212.71565"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.90278053px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
xml:space="preserve"><tspan
id="tspan1984"
y="116.6585"
x="221.2506"
y="126.61594"
x="212.71565"
sodipodi:role="line"
style="stroke-width:0.26458332"><tspan
id="tspan1982"
@ -715,13 +718,13 @@
dx="0">Collect </tspan></tspan></text>
<text
id="text1992"
y="121.31917"
x="186.31981"
y="131.27661"
x="177.78487"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
xml:space="preserve"><tspan
id="tspan1990"
y="121.31917"
x="186.31981"
y="131.27661"
x="177.78487"
sodipodi:role="line"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"><tspan
id="tspan1988"
@ -730,13 +733,13 @@
dx="0">and store information</tspan></tspan></text>
<text
id="text1998"
y="125.97985"
x="186.31981"
y="135.93729"
x="177.78487"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
xml:space="preserve"><tspan
id="tspan1996"
y="125.97985"
x="186.31981"
y="135.93729"
x="177.78487"
sodipodi:role="line"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88055563px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.26458332"><tspan
id="tspan1994"

Before

Width:  |  Height:  |  Size: 63 KiB

After

Width:  |  Height:  |  Size: 63 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 81 KiB

View File

@ -14,8 +14,11 @@
viewBox="0 0 178.01069 131.56144"
version="1.1"
id="svg5913"
inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"
sodipodi:docname="misp-compliance-gdpr-personal-data.svg">
inkscape:version="0.92.1 r15371"
sodipodi:docname="misp-compliance-gdpr-personal-data.svg"
inkscape:export-filename="/home/adulau/git/misp-compliance/GDPR/misp-compliance-gdpr-personal-data.svg.png"
inkscape:export-xdpi="100"
inkscape:export-ydpi="100">
<defs
id="defs5907">
<clipPath
@ -42,15 +45,15 @@
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.98994949"
inkscape:cx="599.6923"
inkscape:cx="428.47144"
inkscape:cy="236.23202"
inkscape:document-units="mm"
inkscape:current-layer="g6728"
showgrid="false"
inkscape:window-width="1920"
inkscape:window-height="1000"
inkscape:window-x="-11"
inkscape:window-y="-11"
inkscape:window-height="1056"
inkscape:window-x="0"
inkscape:window-y="24"
inkscape:window-maximized="1" />
<metadata
id="metadata5910">
@ -106,8 +109,8 @@
id="tspan971">network</tspan></tspan></text>
<path
id="path6478"
d="m 235.32905,266.34712 c 0,-30.19781 24.51312,-54.72697 54.72697,-54.72697 30.22623,0 54.72697,24.52916 54.72697,54.72697 0,30.23281 -24.50074,54.72697 -54.72697,54.72697 -30.21385,0 -54.72697,-24.49416 -54.72697,-54.72697"
style="fill:none;stroke:#df2d38;stroke-width:3.93188715;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:8;stroke-dasharray:none;stroke-opacity:1"
d="m 235.41662,268.8725 c 0,-31.54297 25.60506,-57.16478 57.16478,-57.16478 31.57266,0 57.16478,25.62181 57.16478,57.16478 0,31.57953 -25.59212,57.16478 -57.16478,57.16478 -31.55972,0 -57.16478,-25.58525 -57.16478,-57.16478"
style="fill:none;stroke:#df2d38;stroke-width:4.10703278;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:8;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
id="text6484"
@ -198,8 +201,8 @@
dx="0">IPs</tspan></tspan></text>
<path
id="path6516"
d="m 492.02503,49.897737 c 0,-43.7202548 35.47489,-79.209555 79.20956,-79.209555 43.76999,0 79.20957,35.4893002 79.20957,79.209555 0,43.773705 -35.43958,79.209563 -79.20957,79.209563 -43.73467,0 -79.20956,-35.435858 -79.20956,-79.209563"
style="fill:none;stroke:#df2d38;stroke-width:4.10057354;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:8;stroke-dasharray:none;stroke-opacity:1"
d="m 498.08845,45.307376 c 0,-41.7427537 37.2462,-75.626844 83.16461,-75.626844 45.95549,0 83.16463,33.8840903 83.16463,75.626844 0,41.793784 -37.20914,75.626844 -83.16463,75.626844 -45.91841,0 -83.16461,-33.83306 -83.16461,-75.626844"
style="fill:none;stroke:#df2d38;stroke-width:4.10557795;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:8;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
id="text6522"
@ -259,8 +262,8 @@
dx="0">data</tspan></tspan></text>
<path
id="path6544"
d="m 510.98,207.83848 c 0,-38.47868 31.21495,-69.70208 69.70208,-69.70208 38.51794,0 69.70207,31.2234 69.70207,69.70208 0,38.54344 -31.18413,69.70207 -69.70207,69.70207 -38.48713,0 -69.70208,-31.15863 -69.70208,-69.70207"
style="fill:none;stroke:#df2d38;stroke-width:4.21789455;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:8;stroke-dasharray:none;stroke-opacity:1"
d="m 516.20876,205.81818 c 0,-41.72632 33.84952,-75.585 75.585,-75.585 41.76889,0 75.58498,33.85868 75.58498,75.585 0,41.79653 -33.81609,75.58498 -75.58498,75.58498 -41.73548,0 -75.585,-33.78845 -75.585,-75.58498"
style="fill:none;stroke:#df2d38;stroke-width:4.57388878;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:8;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
id="text6550"
@ -324,7 +327,7 @@
clip-path="url(#clipEmfPath1)"
style="fill:none;stroke:#000000;stroke-width:2.08179665px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:8;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0"
transform="matrix(1,0,0,1.2259378,0,-113.34249)" />
transform="matrix(1,0,0,1.2259378,-11.111678,-112.33234)" />
<path
id="path6574"
d="m 304.74767,18.438674 c 0,-35.189956 28.59864,-63.848134 63.84813,-63.848134 35.27842,0 63.84813,28.658178 63.84813,63.848134 0,35.271601 -28.56971,63.848126 -63.84813,63.848126 -35.24949,0 -63.84813,-28.576525 -63.84813,-63.848126"
@ -371,13 +374,13 @@
id="tspan967">fraud</tspan></tspan></text>
<text
id="text6602"
y="385.28387"
x="212.93796"
y="375.18234"
x="84.648582"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:24px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"><tspan
id="tspan6600"
y="385.28387"
x="212.93796"
y="375.18234"
x="84.648582"
sodipodi:role="line"><tspan
id="tspan6598"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:24px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000"
@ -385,13 +388,13 @@
dx="0 0 0 0 0 0 0 0 0">GDPR is applicable</tspan></tspan></text>
<text
id="text6614"
y="385.28387"
x="494.6792"
y="375.18234"
x="473.466"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:24px;line-height:125%;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"><tspan
id="tspan6612"
y="385.28387"
x="494.6792"
y="375.18234"
x="473.466"
sodipodi:role="line"><tspan
id="tspan6610"
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:24px;font-family:'Helvetica LT Std';-inkscape-font-specification:'Helvetica LT Std, Light';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000"

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

File diff suppressed because it is too large Load Diff

After

Width:  |  Height:  |  Size: 96 KiB

View File

@ -0,0 +1,177 @@
---
title: "MISP as supporting platform for sharing information, following ISO/IEC 27010:2015"
author: [CIRCL Computer Incident Response Center Luxembourg, MISP Project]
date: 2018-06-16
tags: [ISO/IEC 27010, misp, information sharing, information exchange, ISO 27010]
titlepage: true
toc-own-page: true
number-sections: true
titlepage-rule-color: EC2A3F
colorlinks: true
...
# MISP as supporting platform for sharing information, following ISO/IEC 27010:2015
Malicious cyber actors are becoming more organised, growing smarter and becoming more sophisticated, which is rendering traditional defence methods and tools significantly less effective in dealing with the constantly new threats appearing on the horizon.
One solution to this problem is the sharing of threat intelligence in order to raise awareness and sound the alarm about new attacks and data breaches as they happen. This helps to prevent major security incidents from recurring and emerging threats from claiming more victims.
In this context, the evolution of cyber threat intelligence sharing is culminating in the development of platforms and standards that help organisations gather, organise, share and identify sources of threat intelligence. Cyber threat intelligence is also shortening the useful life of attacks and is putting a heavier burden on attackers who want to stay in business. The [Malware Information Sharing and Threat Intelligence Sharing Platform (MISP)](https://www.misp-project.org/) is one of such platforms.
## Alignment with ISO/IEC 27010:2015, why it matters?
Threat intelligence sharing comes with its own caveats and presents a few challenges. For example, organisations may end up with raw, unevaluated data, which adds an extra burden to the security team of the organisations by increasing the number of events and alerts rather than decreasing them. Moreover, some security vendors loath to share information to avoid losing the competitive edge.
Some of these issues are dealt by the ISO/IEC 27000-series (also known as the 'ISMS Family of Standards' or 'ISO27k' for short) of standards. It comprises information security standards published jointly by the International Organisation for Standardisation (ISO) and the International Electro technical Commission (IEC). The ISO/IEC 27000 series of standards provides best practice recommendations on information security management.
The series is deliberately broad in scope, covering more than just privacy, confidentiality and cybersecurity issues. It is applicable to organisations of all shapes and sizes. All organisations are encouraged to assess their information risks, then treat them according to their needs, using the guidance and suggestions where relevant (typically using information security controls).
One of such standards is ISO/IEC 27010:2015, covering Information security management for inter-sector and inter-organisational communications, a supplement to ISO/IEC 27001:2013 and ISO/IEC 27002:2013 for use by information sharing communities.
Standard ISO/IEC 27010 (hereafter, the standard) is particularly relevant for MISP because it provides controls and guidance specifically relating to initiating, implementing, maintaining, and improving information security in inter-organisational and inter-sector communications. Moreover, it provides guidelines and general principles on how the specified requirements can be met using established messaging and other technical methods.
The standard is applicable to all forms of exchange and sharing of sensitive information, both public and private, nationally and internationally, within the same industry or market sector or between sectors. In particular, it may be applicable to information exchanges and sharing relating to the provision, maintenance and protection of an organisation or nation state's critical infrastructures. It is designed to support the creation of trust when exchanging and sharing sensitive information, thereby encouraging the international growth of information sharing communities.
## Is MISP a tool suitable to be used in information sharing community?
MISP is a free and open source platform for sharing, storing and correlating cybersecurity threats and financial fraud indicators, among which SHA1 hashes (a cryptographic function to fingerprint files), threat actor names and Bitcoin addresses. The aim of this platform is to help improving the counter-measures used against targeted attacks and set-up preventive actions and detection. MISP allows organisations to share information about malware and their indicators (i.e. Indicators of Compromise or IOCs), providing its users with collaborative knowledge about existing malware or threats.
### Suitable data model
MISP is a tool specifically made to be used by information sharing communities, even when only some members of an organisation are permitted to access the information shared in MISP. As a tool, MISP includes data model objects such as "organisation" and "user" (of an organisation). The figure below highlights the mechanism to share event with MISP amongst organisation in the same community.
![MISP compliance against ISO/IEC 27010:2015](./images/misp-compliance-iso-concepts.png)
*FIGURE 1: Illustration of MISP organisations and community interactions*
The concept presented in the figure above can be explained and match with key concepts of the ISO/IEC 27010:2015 standard as described in the table below.
|ISO/IEC 27010:2015 key concepts|MISP data model representing the concepts|Related definition in ISO/IEC 27000:2018|
|--- |--- |--- |
|Information sharing community|The concept of community is closely related to the concept of MISP server (also called MISP instance). A MISP server is a specific instance of the MISP software, running on a computer, usually a server. A MISP server can include multiple organisations. A MISP community includes all organisations on a MISP server and organisations running MISP servers that synchronise with this server.|3.34 information sharing community|
|Organization|A MISP organization represent an organisation in the community.|3.50 organization|
|Member of an organisation|MISP users represent organisation members.|Not covered in the standard.|
|Information exchange types (e.g. "alerts and warnings" and "incident handling")|MISP events are the smallest unit that can be shared in MISP. Events can be enrich with "tags", such as tags integrates external and broadly used protocols and standards such as TLD (Traffic Lights Protocol) and MISP galaxies which enable a deeper analysis and categorisation of events. Events are composed of MISP attributes, usually representing indicators of compromise (e.g. IP addresses, domain names etc.). Attributes are defined structure that have a limited set of type and categories. Attributes can be aggregated into MISP objects.|3.21 event|
|Supporting entities|The centralized supporting entity in a MISP community can be interpreted as being the entity (or organisation) operating the MISP instance (also called MISP server). The entity operating the MISP instance decides who will join the community and can attribute rights to organisation on the MISP instance (e.g. right to synchronise a MISP server)|3.76 trusted information communication entity|
|Source|In MISP, the source of the event is indicated in the event detail in the field "Orgc". The source of an event stay the same even if the event is transferred to other communities.|Not covered in the standard.|
|Originator|In MISP, the originator of an event is indicated in the event detail in the field "Org". If the source is in the same MISP community than a recipient, the source (Orgc) and the originator (Org) of an event will be the same for this recipient. If the source of an event (Orgc) is not in the same community than a recipient (e.g. the event has been pushed to another MISP community because its sharing model is "All communities" or "Connected communities"), then the source (Orgc) and the originator will differ. In that case, the originator (Org) would appear as the organisation synchronising the MISP instances (for an illustration, refer to event e' in the "FIGURE 1" above).|Not covered in the standard.|
|Recipient|In MISP, the recipients of an event depends on the sharing model the originator choose for the event. MISP sharing model is flexible and include five sharing models allowing, for example, to only share an event with one organisation, one community or a couple of chosen organisations in a community.|Not covered in the standard.|
### Suitable flexibility and accessibility
MISP can be accessed from different interfaces like a REST API (for systems pushing and pulling IOCs and for automatizing export, import or analysis of IOCs) or via a web interface. This is the result of the inherent goal of MISP: to be a robust platform that ensures a smooth operation for sharing and storing cybersecurity related information in an intelligent way.
MISP is freely available on [GitHub](https://github.com/MISP/MISP), licensed under [GNU Affero General Public License version 3](http://www.gnu.org/licenses/agpl-3.0.html). Everyone can set up its own MISP instance and start a community. MISP is currently used by CSIRTs communities and Banks. However, MISP usages is not limited to those entities and new use cases can be developed.
## Does MISP enable an easy implementation of ISO/IEC 27010:2015 controls?
### Scope
ISO/IEC 27010:2015 complements ISO/IEC 27001:2005 by providing additional or augmented controls in cases where the information exchanged by sharing communities is sensitive and cannot be made publicly available. In this article, only new controls or augmented controls from ISO/IEC 27002:2005 by ISO/IEC 27010:2015 will be covered.
MISP is a tool, a piece of software, not an Information Security and Management System by itself. As such, not all the new controls or augmented controls in ISO/IEC 27010:2015 can be applicable to MISP. For this article, the controls that can, partially can or cannot apply to MISP are presented in the table below.
|New controls of controls augmented by ISO/IEC 27010:2015|Applicable to MISP|References to relevant MISP features|
|--- |--- |--- |
|5.1.1 Policies for information security|Partially|(5) Information security policies|
|5.1.2 Review of the policies for information security|No|N/A|
|7.1.1 Screening|No|N/A|
|8.1.3 Acceptable use of assets|Partially|(8) Asset management|
|8.2.1 Classification of information|Yes|(8) Asset management|
|8.4.1 Information dissemination|Yes|(8) Asset management|
|8.4.2 Information disclaimers|Yes|(8) Asset management|
|8.4.3 Information credibility|Yes|(8) Asset management|
|8.4.4 Information sensitivity reduction|Yes|(8) Asset management|
|8.4.5 Anonymous source protection|Yes|(8) Asset management|
|8.4.6 Anonymous recipient protection|Yes|(8) Asset management|
|8.4.7 Onwards release authority|Yes|(8) Asset management|
|10.1.1 Policy on the use of cryptographic controls|Yes|(10) Cryptography|
|12.2.1 Controls against malware|No|N/A|
|12.4.1 Event logging|Yes|(12) Operations security|
|12.7.2 Community audit rights|No|N/A|
|13.2.2 Agreements on information transfer|Partially|(13) Information transfer|
|13.2.3 Electronic messaging|Yes|Alternative methods to electronic messaging are part of the MISP synchronisation protocol (e.g. air-gap exchange protocol)|
|15.1.2 Addressing security within supplier agreements|No|N/A|
|16.1.2 Reporting information security events|Partially|(16) Information security incident management|
|16.1.6 Learning from information security incidents|Yes|(16) Information security incident management|
|16.1.8 Early warning system|Yes|(16) Information security incident management|
|17.1.1 Planning information security continuity|No|N/A|
|18.1.1 Identification of applicable legislation and contractual requirements|Partially|(18) Compliance|
|18.1.6 Liability to the information sharing community|No|N/A|
The below section highlights clarifications on which MISP features enables an easy implementation of ISO/IEC 27010:2015 controls applicable to MISP.
### <a name="(5)"></a>(5) Information security policies
The standard recommends having policies for information security. This implies that sharing communities have a policy that defines how the community members will work together to set security management policies and direction for the information sharing communities.
As a tool that can be used in different ways by different entities, MISP does not actually have a specific “policy” as such. However, MISP does include a Terms & Conditions feature that entities setting up a MISP instance can customized for their needs. For example, entities having a MISP instance be can customized in the text inside those Terms and Conditions (or can be left empty) and it can be opted to force users to accept it before having access to MISP. [Sharing guidelines](https://github.com/MISP/MISP/wiki/Sharing-guidelines) for using MISP are available.
### <a name="(8)"></a>(8) Asset management
Regarding the implementation of acceptable use of assets, dissemination rules are a core concept and it is the originator, which decides of the dissemination rules for individual events (c.f. [MISP sharing model](ttps://github.com/MISP/misp-book/tree/master/using-the-system)). It is the role of the supporting entity, operating the MISP instance to not bypass these rules but to respect them. When specific tags are applied to an event, indicating how the information received can be used (e.g. [Permissible Actions Protocol taxonomy](https://www.misp-project.org/taxonomies.html#_pap)), these rules need to be respected by all organisations in the community.
The standard suggests that information should be classified in terms of legal requirements, value, credibility, priority, criticality and sensitivity to unauthorized disclosure or modification and that the dissemination of such information should be done accordingly to this classification. Moreover, each information exchange should indicate the originators degree of confidence in the transmitted informations credibility and accuracy and the sensitivity of the information.
MISP has asset management tools build into it. For example, taxonomies can be used in MISP in order to classify events, indicators and threats. For example, one of the taxonomies included in MISP is the Admiralty Scale (also called the NATO System), that ranks the reliability of a source and the credibility of an information. Examples of taxonomies that can be used to classified events in MISP can be found below:
|ISO/IEC 27010:2015 classification requirements|Examples of taxonomies and/or features integrated in MISP (non-exhaustive)|
|--- |--- |
|Legal requirements (8.2.1)|No taxonomies are yet integrated. It is however possible to add custom taxonomy in MISP.|
|Value (8.2.1)|In some cases, the value of threat intelligence depends on the quality of the classification. A wide range of classifications is available for an event in MISP, for example, incident classification or topic taxonomies.
Value of the information can also be determined by the CSSA agreed sharing taxonomy, for example, the 'sharing-class' indicates whether the shared information has been validated by a human prior to sharing.|
|Credibility (8.2.1) and (8.4.3)|The Admiralty Scale taxonomy can be used to measure the credibility of an event. The analyst experience taxonomy can be used to assess the credibility of an analysis of an event. The likelihood-probability taxonomy can also be used to measure the credibility of an event. The correlation feature and sightings can also help assessing the credibility of an event. Whitelist and Warning lists improve false positive detection.|
|Priority (8.2.1)|MISP integrates six levels of priority aligned with NCCIC, DHS, and the CISS.|
|Criticality (8.2.1)|"Threat Level" of a MISP event indicates the level of criticality. The impact overall rating taxonomy. The victims employee count taxonomy.|
|Sensitivity (8.2.1)|NATO classification.|
|Dissemination markings (8.4.1)|Traffic Light Protocol (TLP) taxonomy. Different level of sharing model can be used, restricting the propagation of events.|
|Information disclaimer (8.4.2)|There is no specific field or free text available at the event level in MISP to add a custom disclaimer to list any special requirements to follow by the recipients in addition to the normal information marking. However, it is possible to add custom taxonomies in MISP. Moreover, as explained in the two following points, it is possible to contact the reporter or ask for clarification.
In MISP it is possible to contact the reporter of an event to ask for clarification. For each event, an 'Event Discussion Thread' can also be used to ask for clarification.|
|Sensitivity reduction (8.4.4)|Sightings in MISP can be used to evaluate the value of an attribute over time. Especially sightings of type "Expiration" can be added to an attribute to indicate that the attribute has lost value (e.g. URLs which have been cleaned after some time). The MISP infrastructure-state taxonomy can also indicate if the adversary infrastructure at the event or attribute level is still active or is down.|
MISP also includes a feature to protect the anonymity of the source and the recipient of the information in the community (controls 8.4.5 and 8.4.6). With the MISP [delegation](https://www.circl.lu/doc/misp/delegation/) feature, an organisation can ask another organisation in the same community to publish its own event in order to remain anonymous. In a MISP instance, it is normally possible to consult the list of all organisations in the community. However, the operator of the MISP instance (in other words, the supporting entity) has the possibility to hide this list (enabled by the option “MISP.showorg”) ensuring anonymity of all recipients (i.e. organisations) in a community.
### <a name="(10)"></a>(10) Cryptography
The standard puts forward cryptography is a tool for sharing communities. Indeed, cryptographic techniques can be used to implement the dissemination rules of information sharing, e.g. through information rights management. MISP follows this recommendation because it has built-in the possibility to add SLL certificates for HTTPS and PGP Keys.
### <a name="(12)"></a>(12) Operations security
When required by their communities, members should log the internal dissemination of shared information. In relation to the existence of an event logging system built-in into the platform, MISP has such a system.
### <a name="(13)"></a>(13) Information transfer
MISP includes a Terms & Conditions feature that entities setting up a MISP instance can customized for their needs. For more details refer to <a href="#(5)">(5) Information security policies</a>.
### <a name="(16)"></a>(16) Information security incident management
In relation to Information security incident management, members of information sharing communities should consider whether detected events should be reported to other members of the communities. Likewise, investigations based on information distributed by the information sharing communities should be performed to reduce the risks of similar incidents and develop a better understanding of the risks facing the communities. Moreover, the standard recommends that an early warning system should be deployed within the communities to effectively communicate priority information as soon as it is available.
In this regard, MISP includes advanced data models created by its community. Indeed, MISP includes a simple and practical information-sharing format expressed in JSON through attributes that can be used by MISP or any other software. Moreover, the taxonomies allow for the classification of the incidents. However, at least part of this control cannot apply to MISP because it is out of the functionality of the platform. For example, the standard suggests that each member should ensure that reported incident responses are assessed. This cannot be managed through MISP because it needs to be implemented by its users.
### <a name="(18)"></a>(18) Compliance
Compliance is a category to have in mind as well. Liability issues and remediation should be clarified, understood and approved by all members of the information sharing communities, to address situations in which information is unintentionally or intentionally disclosed. In this regard, the standard specifies that remediation should include, at a minimum, notification of any unauthorised disclosure back to the originator, and potentially also to the source, with sufficient detail to identify the information disclosed. Unauthorised disclosure consequences could directly affect the responsible parties and might involve eliminating or restricting access to certain members for some period of time to re-establish community trust.
As a sharing information platform based in Europe, and processing personal data from EU citizens, MISP needs to comply with the GDPR. However, compliance needs to be seen at the user level in MISP, as explained in a [recent article](https://github.com/MISP/misp-compliance/blob/master/GDPR/information_sharing_and_cooperation_gdpr.md), which analyse the relation between the GDPR and MISP. Nevertheless, it is worth to mention that MISP as a platform has built-in mechanisms that promote privacy by design and by default, helping the compliance with the GDPR of their users. For example, the users are guided by the platform in relation to the data that needs to be included when reporting vulnerabilities. Users can only fill event attributes according to a specific [data model](http://www.misp-project.org/datamodels/#misp-core-format). This means that MISP minimizes the data that is published on the platform to the minimum necessary (a strategy called "data minimization").
## Conclusion
MISP is a promising free and open source software platform that could help many stakeholders to be organised in order to improve their cyber-defence capabilities. Indeed, the MISP threat-sharing platform is a tool to help information sharing of threat intelligence including cybersecurity Indicators of Compromise (IOC), financial fraud or counter-terrorism information.
As demonstrated in this article, MISP is a flexible platform that thanks to an extensible tagging and well-structured sharing mechanisms can be used as a platform to support information sharing implementing the ISO/IEC 27010 standard. However, one must not forget that MISP is only a tool, and that it does not replace an information security management system (ISMS) by itself.
## References
1. [ISO/IEC 27010:2015 on "Information technology — Security techniques — Information security management for inter-sector and inter-organisational communications", 2015](https://www.iso.org/standard/68427.html)
2. [MISP User Manual](https://github.com/MISP/misp-book)
3. [MISP GitHub, "Information sharing and cooperation enabled by GDPR", 2018](https://github.com/MISP/misp-compliance/blob/master/GDPR/information_sharing_and_cooperation_gdpr.md)
## Acknowledgment
This document was partially funded by CEF (Connecting Europe Facility) funding under CEF-TC-2016-3 - Cyber Security ***Improving MISP as building blocks for next-generation information sharing***.
![](https://www.misp-project.org/assets/images/en_cef.png)
## Contact and Collaboration
If you have any question or suggestion about this topic, feel free to [contact us](https://www.circl.lu/contact/). This document is a collaborative effort where external [contributors can propose changes and improvement](https://github.com/MISP/misp-compliance/tree/master/GDPR) the document.

View File

@ -0,0 +1,236 @@
---
title: "How MISP enables stakeholders identified by the NISD to perform key activities"
author: [CIRCL Computer Incident Response Center Luxembourg, MISP Project]
date: 2018-06-16
tags: [NIS, NISD, misp, information sharing, information exchange, NIS Directive]
titlepage: true
toc-own-page: true
number-sections: true
titlepage-rule-color: EC2A3F
colorlinks: false
...
# How MISP enables stakeholders identified by the NISD to perform key activities
Network and Information Security (NIS) means the ability of a network or an information system to resist accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of data and the related services . The Directive on security of network and information systems (NISD) lays down specific obligations for Member States of the EU to adopt a national NIS strategy, to designate National Competent Authorities (NCA), Single Points of Contact (SPoC) and specific NIS tasks to Computer Security Incident Response Teams (CSIRTs). In addition, the NIS Directive establishes security and incident notification requirements for Operators of Essential Services (OES) such as banking, energy, financial market infrastructure, digital infrastructure; and Digital Service Providers (DSP), including online marketplaces, online search engines and cloud services. Furthermore, it creates a cooperation group in order to develop trust amongst MSs and facilitate strategic cybersecurity information sharing. In parallel, it creates a CSIRTs network to build confidence amongst MSs to boost operational cybersecurity cooperation.
The [Malware Information Sharing and Threat Intelligence Sharing Platform (MISP)](https://www.misp-project.org/) is an open source tool which primary purpose is to share cyber threat intelligence. It is broadly used in the CSIRTs community in the EU and beyond. It can be used for many other activities in addition to share cyber threat intelligence. Therefore, this article takes a closer look at how MISP can support stakeholders mentioned in the NISD to better perform the tasks identified therein. Especially CSIRTs, OESs and DSPs are the stakeholders that could benefit the most from using MISP in the scope of the NISD. Member States and Single Point of Contacts could also use MISP for the performance of their tasks, especially as a tool to receive and share NIS events and notify NIS incidents.
## How MISP can support CSIRTs participating in the CSIRTs network
As mentioned before, the CSIRTs Network aims to facilitate operational cooperation between Member States in managing NIS incidents. The CSIRTs network is responsible for multiple tasks, including supporting MSs in addressing cross-border incidents, exchanging best practices on the exchange of information related to incident notification, and assisting MSs in building capacity in NIS. We summarise below the tasks where MISP can be directly or indirectly of support for the individual CSIRTs participating in the CSIRTs Network. Note that the tools used by the individual CSIRTs is a choice made by each one of them. The table below demonstrates how CIRCL understands that MISP could support without implying that all CSIRTs use or will use MISP.
|CSIRTs network task as described in Article 12 of the NISD|Can MISP support?|
|--- |--- |
|(a) exchanging information on CSIRTs' services, operations and cooperation capabilities;|Not applicable|
|(b) at the request of a representative of a CSIRT from a Member State potentially affected by an incident, exchanging and discussing non-commercially sensitive information related to that incident and associated risks; however, any Member State's CSIRT may refuse to contribute to that discussion if there is a risk of prejudice to the investigation of the incident|Yes|
|(c)exchanging and making available on a voluntary basis non-confidential information concerning individual incidents;|Yes|
|(d)at the request of a representative of a Member State's CSIRT, discussing and, where possible, identifying a coordinated response to an incident that has been identified within the jurisdiction of that same Member State;|Not applicable|
|(e)providing Member States with support in addressing cross-border incidents on the basis of their voluntary mutual assistance;|Yes|
|(f)discussing, exploring and identifying further forms of operational cooperation, including in relation to: (i) categories of risks and incidents; (ii) early warnings; (iii) mutual assistance; (iv) principles and modalities for coordination, when Member States respond to cross-border risks and incidents;|Yes|
|(g)informing the Cooperation Group of its activities and of the further forms of operational cooperation discussed pursuant to point (f), and requesting guidance in that regard;|Not applicable|
|(h)discussing lessons learnt from exercises relating to the security of network and information systems, including from those organised by ENISA;|Not applicable|
|(i)at the request of an individual CSIRT, discussing the capabilities and preparedness of that CSIRT;|Not applicable|
|(j)issuing guidelines in order to facilitate the convergence of operational practices with regard to the application of the provisions of this Article concerning operational cooperation.|Not applicable|
### How MISP can support Article 12 (b) exchanging and discussing information related to incidents and associated risks
MISP initial purpose was to exchange information about events. Events can be of different types but one of the most common type of events is incident. With MISP, it is possible to build communities to exchange specific [data structures](https://www.circl.lu/doc/misp/categories-and-types/) about an incident such as operational description in term of payload delivery, network activity and attribution. Therefore, MISP can be used by CSIRTs to exchange operational information about an incident in support of Article 12 (b).
In addition, MISP taxonomies and galaxies allow to indicate the risk of an incident, e.g. using the MISP threat-level taxonomy (other taxonomies related to criticality and priority can be found [here](https://github.com/MISP/misp-compliance/blob/master/ISO_IEC_27010/misp-sharing-information-following-ISO-IEC-27010.md#8-asset-management)). Therefore, MISP can be used by CSIRTs participating in the CSIRTs network to exchange and discuss information related to risks associated to incidents.
There are different ways in MISP to initiate discussions.
* **Forums** can be used to discuss non-event related topics while discussions can be accessed on the top "Global Actions - List Discussions". This is the least relevant way to communicate for the purpose of Article 12 (b) as these discussions do not concern incidents. Note that forums and discussions are not synchronized between MISP instances.
* There a possibility to add **comments to events** in which case various CSIRTs can add further comments to an event (which can represent an incident). Note that the CSIRTs network meets physically and tools are not used to discuss during such meetings. However, topics put forward during CSIRTs network meetings can be prepared or further discussed by individual CSIRTs before or after CSIRTs network meetings. Therefore, the comments function in MISP is in support of Article 12 (b). Note however that comments are not synchronized between MISP instances.
* The last option is to **contact a reporter** (e.g. a CSIRT) which can be used to contact by e-mail the person in the organisation that created the event. All E-Mails can be enforced to be encrypted. This allows for contacting a reporter without having any contact details and in a more confidential one-to-one manner which can be useful to discuss commercially sensitive information related to an incident. Note however that if the reporter would chose to reply, his or her contact details will be revealed. Therefore, this function in MISP could also be in support of Article 12 (b)
### How MISP can support Article 12 (c) exchanging and making available on a voluntary basis non-confidential information concerning individual incidents
MISP supports five distribution settings: your organisation only (the most restrictive), community only, connected community, all communities, sharing group. In MISP the distribution settings can be set at the level of individual events representing individual incidents. Therefore, MISP can support exchanging individual incidents. This means that sharing can be done in a fully voluntary fashion even when not having any synchronisation functionality enabled.
MISP also allows to differentiate non-confidential from confidential information. Specifically, the confidentiality of events representing incidents in MISP can be indicated using various taxonomies such as the NATO classification. On top of that, it is possible to limit the synchronisation between other MISP instances by tags (i.e. taxonomies). It is for example possible to filter out (in other words not to share) all events with the tags nato:classification="CTS" (NATO COSMIC TOP SECRET). Therefore, MISP is in support of Article 12 (c) for whichever CSIRTs participating in the CSIRTs network using MISP outside of the CSIRTs network meetings. Note that the MISP GUI allows for easily printing information using in any browser about individual events which could allow CSIRTs to bring handouts to CSIRTs network meetings. Moreover, the MISP-Darwin project will enable to automatically generate natural language reports out of MISP events.
### How MISP can support Article 12 (e) in addressing cross-border incidents on the basis of voluntary mutual assistance
According to the 2013 Cybersecurity Strategy a particularly serious cyber incident or attack could constitute sufficient ground for a Member State to invoke the EU Solidarity Clause (Article 222 of the Treaty on the Functioning of the European Union (TFEU)). Therefore, for the purpose of this article, we consider mutual assistance in the context of cyber crises. However, mutual assistance is triggered by a CSIRT (either voluntary or obligatory depending on the context) and does not relate to the use of any tools.
Addressing cross-border incidents can be here interpreted as cross-border incident response. MISP can help in the incident response process to (non-exhaustive):
* Analysing observables and malware collected during an incident (e.g. domain name, IP addresses etc.). For example assessing whether observables are indicators of compromise or false positives (e.g. thanks to the correlation graph and expansion modules). On top of that, MISP can also be combined with Security Incident Response Platforms such as [TheHive](https://blog.thehive-project.org/2017/06/19/thehive-cortex-and-misp-how-they-all-fit-together/) to (1) analyse observables during an incident, (2) import and (3) export events from MISP to TheHive and vice-versa.
* Sharing the real-time analysis of an incident with the MISP organisations (in this case CSIRTs participating in the CSIRTs network). MISP events representing an incidents are not static once created, and it is possible for the MISP organisation that has created the event to modify or add attributes to the event after the event creation. Additionally, it is also possible for another MISP organisation than the one which created the event to propose a modification to an attribute, or to propose some additional attributes to the creating organisation. This feature is called proposal. The creating MISP organisation of the event will be able to see any proposals and discard or accept the changes. This feature is **particularly interesting in incidents involving multiple parties, such as during cross-border incidents**. Therefore, this function in MISP could also be in support of Article 12 (e)
### How MISP can support Article 12 (f) exploring and identifying further forms of operational cooperation in relation to four areas.
#### (i) categories of risks and incidents
More than being a tool, MISP also became a [standard for threat intelligence and security related events and incidents](https://github.com/MISP/misp-rfc). Specifically, MISP taxonomies and galaxies enable risks and incidents categorisation (e.g. [Europol incident taxonomy](https://www.misp-project.org/taxonomies.html#_europol_incident)). Being an open source software developed on GitHub, MISP allows and encourages CSIRTs to contribute on the features and development of the MISP software. CSIRTs can therefore contribute by proposing new taxonomies to categorize risks and incidents. Those new taxonomies will then be available to them, to further explore and identify the most relevant ones.
#### (ii) early warnings
First lets take a look at the definition of early warning. Early warning is indeed not explicitly defined in the NISD. From the ENISA Report on Cyber Crisis Cooperation and Management, an early warning is a system that **enables preventative measure due to detailed diagnosis** for decision-making in order to intervene, plan and implement a response to a crisis or incident. By sharing IoCs and by providing means to automate import and export of IoCs, MISP gives support to CSIRTs but also to any other entities that desire to detect and block threats in their network and information system. Indeed, [one of the main goals of MISP is to feed protective or detection tools](https://circl.lu/assets/files/misp-training/luxembourg2017/integration.pdf) with data such as Security Information and Event Management (SIEM), Intrusion Detection System (IDS) and Intrusion Prevention System (IPS).
Another definition is available from the [European commission, defining early warning](http://ec.europa.eu/information_society/newsroom/cf/dae/document.cfm?doc_id=4438) as If an organisation comes across a cyber threat (regardless of whether this threat has succeeded in its objectives of attacking the organisation), **valuable information might be gained on the attackers tools, techniques, protocols** (amongst other indicators). Sharing this information with other parties can **aid them in protecting themselves from potential attacks in the future**. It is this type of information that the study refers to as “early warnings”.
As a threat intelligence platform, MISP enable data sharing as well as data analysis. As an example, MISP provide a correlation graph to link events and attributes with each other and modules to quickly analyse and gain more information on an attribute. In MISP and specifically with the galaxies functionality, events can be linked to Advanced Persistent Threat (APT) groups, and APT groups can be then analysed more globally, taking into account a large set of events. All this functionality enables valuable information to be gained on the attackers tools, techniques, protocols. As this information will then be shared to other parties, MISP can therefore be seen as part of an early warning based on the definition of the European commission.
#### (iii) mutual assistance
MISP allows [collaboration](https://www.circl.lu/doc/misp/sharing/#collaboration) between users of organisations in the same MISP instance. Specifically, mutual assistance is enhanced in MISP through forums, discussion threads and the possibility to contact the reporter of an event.
#### (iv) principles and modalities for coordination
MISP includes a Terms & Conditions feature that organisations operating a MISP instance can customize for their needs. For example, MISP organisations be can customize the text inside those Terms and Conditions and it can be opted to force users to accept it before having access to MISP. Moreover, an example of sharing guidelines for MISP is available. In each community, such sharing guidelines can be created and distributed to the organisation members.
While performing activities in the above mentioned four areas, CSIRTs can use MISP to explore and identify further forms of operational cooperation in relation to mutual assistance.
## How MISP can further enable CSIRTs performing their tasks
MISP enables CSIRTs to perform all tasks mentioned in the NIS Directive. The next table summarises these tasks and the sections below further explain how MISP supports these tasks.
|CSIRTs network task from Annex I (2)|Supported by MISP?|
|--- |--- |
|(a) (i)monitoring incidents at a national level;|Yes|
|(a) (ii)providing early warning, alerts, announcements and dissemination of information to relevant stakeholders about risks and incidents;|Yes|
|(a) (iii)responding to incidents;|Yes|
|(a) (iv)providing dynamic risk and incident analysis and situational awareness;|Yes|
|(a) (v)participating in the CSIRTs network.|Yes|
|(b) CSIRTs shall establish cooperation relationships with the private sector.|Yes|
|(c) promote the adoption and use of common or standardised practices for incident and risk-handling procedures; incident, risk and information classification schemes.|Yes|
### (a) (i) monitoring incidents at a national level
For the purpose of this article, monitoring means observing and checking the progress or quality of something over a period of time; keep under systematic review. In case of incidents, CSIRTs can monitor incidents happening at **national level** in term of **resolution steps** and **impact over time** and take appropriate measures if needed.
In MISP it is possible to indicate what EU Member States are affected for each event representing an incident thanks to the [veris country](https://www.misp-project.org/taxonomies.html#_country) taxonomy. Therefore, CSIRTs can filter incidents relevant to their own Member State. In addition, various taxonomies are available in MISP to indicate the steps in the incident resolution such as the [status of events used in Request Tracker](https://www.misp-project.org/taxonomies.html#_rt_event_status) and the analysis levels. In terms of impact, the NISD states that to determine the impact of an incident, the following parameter shall be taken into account:
- the number of users affected by the disruption of the essential service;
- the duration of the incident;
- the geographical spread with regard to the area affected by the incident.
MISP provides taxonomies which could partially support describing NISD impact criteria e.g. for (a) the number of users affected the veris victim employee count taxonomy can be used, for (b) the duration of the incident, veris timeline taxonomy could be considered and for (c) the geographical spread, the taxonomy veris country can be used.
As previously highlighted, MISP events representing incidents can be modified even after their creation. Regular modification of the event will therefore enable monitoring over time.
Therefore, MISP can support the monitoring of incidents at national level by CSIRTs.
### (a) (ii) providing early warning, alerts and dissemination of information to relevant stakeholders about risks and incidents
As previously highlighted, MISP can be used as part of an early warning. MISP is a tool to share information but it also has an alert feature that enables a user to receive emails when events are created in the system or major changes occurs in the events.
The MISP data structure includes information about risks and incidents. MISP can also be used by CSIRTs for dissemination of such information to relevant stakeholders, for example to the private sector, OESs, DSPs or other CSIRTs on the condition that those stakeholders have (1) an organisation in the CSIRTs MISP instances and (2) a minimum of understanding on how to use MISP.
### (a) (iii) responding to incidents
As previously highlighted, MISP can be use in the scope of incident response.
### (a) (iv) providing dynamic risk and incident analysis and situational awareness
As implied in the ENISA CSIRT baseline capability report, dynamic risk analysis can be understood, for CSIRTs, as being a similar concept as the concept of situational awareness. As previously highlighted, MISP can be used to support incident analysis and provide taxonomies about risk which can be modified over time, and can therefore be seen as dynamic.
The NISD does not provide a definition of situational awareness. However, in its Report on Cyber Crisis Cooperation and Management Comparative study, ENISA defines situational awareness as the knowledge and understanding of the current operational status, risk posture, and threats to the cyber environment gained through instrumentation, reporting, assessments, research, investigation, and analysis, which are used to enable well-informed decisions and timely actions to pre-empt, deter, defend, defeat, or otherwise mitigate against those threats and vulnerabilities.
A MISP server or instance can have a significant database of events representing incidents. Thanks to a classification mechanism enabled by taxonomies and galaxies, statistics can be made from a MISP instance to deduce from all the incidents the current operational status, risk posture, and threats to the cyber environment. Such analytics could for example be computed via a custom script, by using the MISP API, supporting many programing languages such as python with [PyMISP](https://github.com/MISP/PyMISP).
### (a) (v) participating in the CSIRTs network
As explained in the above chapter, MISP can be used by individual CSIRTs participating in the CSIRTs Network. In addition, information about events and incidents residing in MISP can be discussed during meetings of the CSIRTs network.
### (b) CSIRTs shall establish cooperation relationships with the private sector
Giving access to the private sector on their MISP instance, is one way for CSIRTs to establish cooperation relationships with them.
### (c) promote the adoption and use of common or standardised practices for:
#### (i) incident and risk-handling procedures
Not applicable as MISP does not include any documentation on procedures.
#### (ii) incident, risk and information classification schemes
As described in the above chapter, MISP is also a [standard for threat intelligence and security related events and incidents](https://github.com/MISP/misp-rfc). Specifically the MISP standard includes information classification schemes in the form of taxonomies to describe incidents and risks.
## How MISP can support OESs and DSPs
### How MISP can support OESs and DSPs with their security requirements
OESs and DSPs should take appropriate and proportionate technical and organisations measures to manage the risk posed to the security of networks and information systems. For mature organisations, in term of security, MISP can enhance security by providing an early warning system as described in above chapter.
### How MISP can support OESs and DSPs with their incident notification requirements
|CSIRTs network task from Annex I (2)|Supported by MISP?|
|--- |--- |
|Notify any incident having a “significant” or “substantial” impact to the NCA or to the CSIRT without undue delay.|Yes|
|Notify impact of incident if OESs relies on a third-party DSP.|Yes|
|Inform the public about individual incidents if required by the notified competent authority or CSIRT.|Not applicable|
### Notify any incident having a “significant” or “substantial” impact to the NCA or to the CSIRT without undue delay.
Additionally to security requirements, OESs and DSPs have specific incident notification requirements under the NISD. OESs and DSPs should notify the National Competent Authority (NCA) or the relevant CSIRT of any incident of "significant impact" (Art. 14 (3)) for the OESs and "substantial impact on the provision of a service as referred to in Annex III" (Art. 16 (3)) for the DSPs. The NCA and CSIRT can then share the incident to other Member States, other CSIRTs or to the public depending on the context.
The distribution mechanism of MISP could facilitate such notification activities. However, the initial use case in MISP was to share to all organisations within a community or wider. Nevertheless, with the sharing group functionality in MISP, it is possible to better control to what extent information is shared and to which community members. This can be beneficial, especially regarding sensitive or confidential events. As highlighted, MISP provides taxonomies which could partially support NISD impact criteria. Additionally to OESs criteria to measure whether an incident has a significant impact, DSPs need to take into account the following criteria:
- the extent of the disruption of the functioning of the service;
- the extent of the impact on economic and societal activities.
However, these criteria for the moment are not directly supported by MISP.
As a concrete example of how OESs and DSPs could use MISP as a notification mechanism in practice, please refer to the [Annex](#annex).
### Notify impact of incident if OESs relies on a third-party DSP.
OESs can notify that they rely on a DSPs thanks to the [eu-nis-sector-and-subsectors](https://www.misp-project.org/taxonomies.html#_eu_nis_sector_and_subsectors) taxonomy and the [eu-market-and-public-admin](https://www.misp-project.org/taxonomies.html#_eu_marketop_and_publicadmin) taxonomy.
## Conclusion
MISP can support CSIRTs participating in the CSIRTs network mainly with the tasks related to information sharing and cooperation in the context of incident handling. In addition, MISP can further enable CSIRTs performing their tasks set out in Annex I of the NISD. Finally, MISP can support OESs and DSPs with complying with their security requirements as well as with their incident notification requirements. Indeed, MISP is already broadly used by CSIRTs and some OESs and DSPs. Some of the CSIRTs in the EU already have their own MISP instance connected to their constituency.
## Acknowledgment
This document was partially funded by CEF (Connecting Europe Facility) funding under CEF-TC-2016-3 - Cyber Security ***Improving MISP as building blocks for next-generation information sharing***.
![](https://www.misp-project.org/assets/images/en_cef.png)
## Contact and Collaboration
If you have any question or suggestion about this topic, feel free to [contact us](https://www.circl.lu/contact/). This document is a collaborative effort where external [contributors can propose changes and improvement](https://github.com/MISP/misp-compliance/tree/master/NISD) the document.
## Annex
As an example on how MISP can be used as an incident notification tool in the context of the NISD. In this example, OESs and DSPs of country A must notify first the National Competent Authority (NCA) of country A. In this example, the NCA also acts as a Single Point of Contact (SPoC).
![Examples of notification configuration](./images/misp-nisd-notification.svg.png)
*FIGURE 1: Examples of notification configuration*
In the above figure, the MISP synchronisation (represented by each and every arrow) can be either one way or two ways depending on how MISP instances are connected between each other. In any case, the synchronisation between MISP instances of OESs and DSPs should at least allow the OESs and DSPs to push events to the NCA/SPoC MISP instance. Moreover, as clarified in Art. 14 (5), CSIRTs should provide follow-up information on the incident notified by the OESs and DSPs. In this case, a two ways synchronisation is preferable. The following section details the main steps of incident notification depicted in the above figure.
### Step 1
The OES or DSP notifies the NCAs in case of an incident having a significant impact. OESs or DSPs have several possibilities to report the MISP event representing the NIS incident:
- Use their own MISP instance synchronised with the NCA MISP instance to create the MISP event representing the NIS incident (if the OES or DSP has one) and synchronise it with the MISP instance of the NCA.
- Use the NCA MISP instance to create a MISP event representing the incident.
- If the OES or DSP does not want to use MISP, it can send the MISP event representing the NIS incident details by another communication channel and the NCA can add the MISP event in its MISP instance itself.
The OES or DSP has several possibilities in terms of [distribution settings](https://github.com/MISP/misp-book/tree/master/using-the-system#creating-an-event) in MISP:
* **Sharing group**: the OES or DSP can use a sharing group only including the NCA for example. This is the most likely approach. The MISP event representing the NIS incident will only be shared to the organisation members of the sharing group.
* **This Community-only**: the MISP event representing the NIS incident will be shared to all other OESs, DSPs, NCA from other countries, National CSIRT and any other organisations in the NCA MISP instance.
* **Connected communities**: the MISP event representing the NIS incident will be shared to the connected communities, for example CSIRTs from other countries
* **All communities**: the MISP event representing the NIS incident will be shared recursively without limit.
If the incident is sensitive, OESs or DSPs would most likely use a restrictive sharing group by default (only including the NCA for example).
### Step 2
The NCA in step 2 will decide to whom it wants to share the MISP event representing the NIS incident, including:
- Other Member State, e.g. SPoC of other member states. NCA or CSIRTs shall inform the other affected Member State(s) if the incident has a significant impact on the continuity of essential services in that Member State (Art. 14 (5)).
- The national CSIRT(s).
If the event was previously created by the OES or DSP within a restricted sharing group, the NCA would need to edit the event representing the incident in MISP to change its distribution setting. This action is only available to an "admin" user in MISP, therefore the NCA should use an admin role to handle the incident distribution. The NCA will be able to choose a sharing group more appropriate than the currently existing one, also including any other Member States which could be significantly impacted by the incident. The OES or DSP would be able to see the resulting sharing group ensuring transparency on the entities the NCA transfer the event to.
If the incident was communicated to the NCA by the OES or DSP by other means than MISP, the NCA can choose the appropriate sharing group when creating the event in MISP based on the information received by those means.
### Step 3
The National CSIRT can also decide to share the event to other CSIRTs. In this case, the National or sectoral CSIRT can either:
* Modify the event sharing group to add other EU CSIRTs (only possible if they have an ["extend" role](https://www.circl.lu/doc/misp/using-the-system/#create-and-manage-sharing-groups))
* Change the Distribution setting of the event to another sharing group.

File diff suppressed because it is too large Load Diff

After

Width:  |  Height:  |  Size: 79 KiB

View File

@ -1,2 +1,69 @@
# misp-compliance
Legal, procedural and policies document templates for operating MISP and information sharing communities
Legal, procedural and policies document templates for operating MISP and information sharing communities following existing regulations, laws or policies.
This repository is a collaborative effort to improve the state of information sharing and exchange within and outside the MISP Project.
## Information sharing and cooperation enabled by GDPR
The General Data Protection Regulation (GDPR) aims to reduce legal uncertainty and limits the interpretations by setting out clear rules and conditions for the processing and sharing of personal data as well as the protection of natural persons with regard to the processing of personal data. Organisations must ensure that they process only the minimum amount of personal data necessary to achieve their lawful processing purposes. To this end, the GDPR distinguishes the roles and obligations of data processors and data controllers, provides precise definitions of personal data and establishes the conditions under which information can be shared.
National and governmental Computer Security Incident Response Team (n/g CSIRTs) are teams that serve the government of a country by helping with Critical Information Infrastructure Protection (CIIP). They coordinate incident management with the relevant stakeholders at national level, and cooperate with the national and governmental teams in other countries.
The [Malware Information Sharing and Threat Intelligence Sharing Platform (MISP)](https://www.misp-project.org/) is a software for sharing, storing and correlating indicators of compromise of targeted attacks, cybersecurity threats and financial fraud indicators, among which SHA1 hashes (a cryptographic function to fingerprint files), threat actor names and Bitcoin addresses. The MISP data model is composed of "events", which usually represent threats or incidents, which in turn are composed of a list of "attributes" (e.g. IP addresses, domain names etc..). Other data models exist in MISP such as "objects", which allow advanced combinations of attributes and "galaxies" which enable a deeper analysis and categorisation of events.
Information sharing communities are enabled using tools like MISP. As a Computer Security Incident Response Team for the private sector communes and non-governmental entities in Luxembourg, [CIRCL](https://www.circl.lu/) has created and operates several communities to automate information sharing at national, European and international levels.
- [Document in Markdown format](./GDPR/information_sharing_and_cooperation_gdpr.md) | [PDF](./GDPR/information_sharing_and_cooperation_gdpr.pdf)
## Information sharing enabled by DORA
The Digital Operational Resilience Act (DORA) is a new EU legislation aiming at improving the operational and cyber resilience of the Union's financial sector. Set to enter into application in early 2025, DORA will apply to a very wide range of entities, which will benefit from new provisions on information sharing. Those provisions will reinforce the legal grounds for information sharing arrangements on cyber threat information and intelligence.
- [Document in Markdown format](./DORA/information_sharing_dora.md)
## MISP as supporting platform for sharing information, following ISO/IEC 27010:2015
Threat intelligence sharing comes with its own caveats and presents a few challenges. For example, organisations may end up with raw, unevaluated data, which adds an extra burden to the security team of the organisations by increasing the number of events and alerts rather than decreasing them. Moreover, some security vendors loath to share information to avoid losing the competitive edge.
Some of these issues are dealt by the ISO/IEC 27000-series (also known as the 'ISMS Family of Standards' or 'ISO27k' for short) of standards. It comprises information security standards published jointly by the International Organisation for Standardisation (ISO) and the International Electro technical Commission (IEC). The ISO/IEC 27000 series of standards provides best practice recommendations on information security management.
The series is deliberately broad in scope, covering more than just privacy, confidentiality and cybersecurity issues. It is applicable to organisations of all shapes and sizes. All organisations are encouraged to assess their information risks, then treat them according to their needs, using the guidance and suggestions where relevant (typically using information security controls).
One of such standards is ISO/IEC 27010:2015, covering Information security management for inter-sector and inter-organisational communications, a supplement to ISO/IEC 27001:2013 and ISO/IEC 27002:2013 for use by information sharing communities.
Standard ISO/IEC 27010 (hereafter, the standard) is particularly relevant for MISP because it provides controls and guidance specifically relating to initiating, implementing, maintaining, and improving information security in inter-organisational and inter-sector communications. Moreover, it provides guidelines and general principles on how the specified requirements can be met using established messaging and other technical methods.
The standard is applicable to all forms of exchange and sharing of sensitive information, both public and private, nationally and internationally, within the same industry or market sector or between sectors. In particular, it may be applicable to information exchanges and sharing relating to the provision, maintenance and protection of an organisation or nation state's critical infrastructures. It is designed to support the creation of trust when exchanging and sharing sensitive information, thereby encouraging the international growth of information sharing communities.
- [Document in Markdown format](./ISO_IEC_27010/misp-sharing-information-following-ISO-IEC-27010.md) | [PDF](./ISO_IEC_27010/misp-sharing-information-following-ISO-IEC-27010.pdf)
## How MISP enables stakeholders identified by the NISD to perform key activities
Network and Information Security (NIS) means the ability of a network or an information system to resist accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of data and the related services . The Directive on security of network and information systems (NISD) lays down specific obligations for Member States of the EU to adopt a national NIS strategy, to designate National Competent Authorities (NCA), Single Points of Contact (SPoC) and specific NIS tasks to Computer Security Incident Response Teams (CSIRTs). In addition, the NIS Directive establish
es security and incident notification requirements for Operators of Essential Services (OES) such as banking, energy, financial market infrastructure, digital infrastructure; and Digital Service Providers (DSP),
including online marketplaces, online search engines and cloud services. Furthermore, it creates a cooperation group in order to develop trust amongst MSs and facilitate strategic cybersecurity information sharing. In parallel, it creates a CSIRTs network to build confidence amongst MSs to boost operational cybersecurity cooperation.
The [Malware Information Sharing and Threat Intelligence Sharing Platform (MISP)](https://www.misp-project.org/) is an open source tool which primary purpose is to share cyber threat intelligence. It is broadly used in the CSIRTs community in the EU and beyond. It can be used for many other activities in addition to share cyber threat intelligence. Therefore, this article takes a closer look at how MISP can support stakeholders mentioned in the NISD to better perform the tasks identified therein. Especially CSIRTs, OESs and DSPs are the stakeholders that could benefit the most from using MISP in the scope of the NISD. Member States and Single Point of Contacts could also use MISP for the performance of their tasks, especially as a tool to receive and share NIS events and notify NIS incidents.
- [Document in Markdown format](./NISD/how-misp-enables-NISD-stakeholders-perform-key-activities.md) | [PDF](./NISD/how-misp-enables-NISD-stakeholders-perform-key-activities.pdf)
# Guidelines to setting up an information sharing community such as an ISAC or ISAO
The objective of this guideline (this document) is to **describe the practical aspects of setting up a new information sharing community**, such as an Information Sharing and Analysis Centre (ISAC) or an Information Sharing and Analysis Organisation (ISAO). In this guideline, we will refer to individuals or organisations that intend to set up a sharing community as "you" or the "operator".
Relevant research has already been conducted and published by organisations such as the European Union Agency for Network and Information Security (ENISA) and the ISAO Standards Organisation. Our guideline provides **practical best practices** to set up an information sharing community based on feedback and experience from existing information sharing communities.
This guideline is focused around the [Open Source Threat Intelligence Sharing platform (MISP)](https://www.misp-project.org/) used in support on information sharing activities.
- [Document in Markdown format](https://github.com/MISP/misp-compliance/blob/master/setting-up-ISACs/guidelines_to_set-up_an_ISAC.md) | [PDF](https://www.x-isac.org/assets/images/guidelines_to_set-up_an_ISAC.pdf)
# Contributing
If you see any errors in the documents or if you would like to propose changes or updates, feel free to open an issue.
You can also directly update the documents by forking the project and then update the documents and finally do a pull-request.
# Contributors and Funding
These documents were partially funded by CEF (Connecting Europe Facility) funding under CEF-TC-2016-3 - Cyber Security ***Improving MISP as building blocks for next-generation information sharing***.
Complementary funding was from the CIRCL Computer Incident Response Center Luxembourg CSIRT activities.

View File

@ -0,0 +1,524 @@
---
title: "Guidelines to setting up an information sharing community such as an ISAC or ISAO"
author: [CIRCL Computer Incident Response Center Luxembourg, MISP Project and X-ISAC.org]
date: 2019-03-11
tags: [misp, information sharing, information exchange, ISAC, threat intelligence, ISAO]
titlepage: true
toc-own-page: true
number-sections: true
colorlinks: true
titlepage-color: "77a5ef"
titlepage-text-color: "FFFFFF"
titlepage-rule-color: "FFFFFF"
titlepage-rule-height: 1
...
# Guidelines to setting up an information sharing community such as an ISAC or ISAO
The objective of this guideline (this document) is to **describe the practical aspects of setting up a new information sharing community**, such as an Information Sharing and Analysis Centre (ISAC) or an Information Sharing and Analysis Organisation (ISAO). In this guideline, we will refer to individuals or organisations that intend to set up a sharing community as "you" or the "operator".
Relevant research has already been conducted and published by organisations such as the European Union Agency for Network and Information Security (ENISA) and the ISAO Standards Organisation. Our guideline provides **practical best practices** to set up an information sharing community based on feedback and experience from existing information sharing communities.
This guideline is focused around the [Open Source Threat Intelligence Sharing platform (MISP)](https://www.misp-project.org/) used in support on information sharing activities.
## Introduction: ISACs, ISAOs and PPPs
Malicious cyber actors are becoming more organised, smarter and more sophisticated, which is rendering traditional defence methods and tools less effective in dealing with new threats appearing. One solution to this problem is the sharing of information about cyber threats and incidents. This helps to prevent major security incidents from recurring and emerging threats from claim.
This chapter aims at defining the types of sharing organisations and clarifying their differences. Specifically, the paragraphs below will focus on the differences between ISACs, ISAOs and Private Public Partnership (PPPs). Additionally, X-ISAC (pronounced Cross-ISAC) will also be introduced.
### Resources and legal context around ISACs and ISAOs
The most relevant publications on ISACs and PPPs in the EU are the [ENISA Cooperative Models for Effective Public Private Partnerships Good Practice Guide](https://www.enisa.europa.eu/publications/good-practice-guide-on-cooperatve-models-for-effective-ppps) and the [ENISA study on Information Sharing and Analysis Center (ISACs) - Cooperative models](https://www.enisa.europa.eu/publications/information-sharing-and-analysis-center-isacs-cooperative-models).
In addition, the US based ISAO Standards Organisation published a number of resources on how to set-up ISAOs. The ISAO Standards Organisation has been established by the 2015 [Executive Order 13691](https://obamawhitehouse.archives.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari), and is defined as a “non-governmental organisation [..] to improve the USs cybersecurity posture by identifying standards and guidelines for robust and effective information sharing and analysis related to cybersecurity risks, incidents, and best practices”.
Similar to the EU NIS Directive, the US has a legal framework fostering information sharing. Information sharing and ISAO have been promoted by Executive Order 13691, the [Presidential Policy Directive 21](https://obamawhitehouse.archives.gov/the-press-office/2013/02/12/presidential-policy-directive-critical-infrastructure-security-and-resil) and the [Cybersecurity Information Sharing Act](https://www.congress.gov/bill/113th-congress/senate-bill/2588/text) and the Cybersecurity Information Sharing Act. The latter, signed into law on December 2015, promoting information sharing in the context of cybersecurity threats, especially between the private sector and the government.
### What is the difference between an ISAC, PPP and ISAO?
According to [ENISA](https://www.enisa.europa.eu/publications/public-private-partnerships-ppp-cooperative-models/at_download/fullReport), a **public private partnership** (PPP) is a “long term agreement/cooperation/collaboration between two or more public and private sectors and has developed through history in many areas”. ISACs are more formal than PPPs and they can be a form of PPPs, according to an [ENISA study](https://www.enisa.europa.eu/publications/information-sharing-and-analysis-center-isacs-cooperative-models/at_download/fullReport).
While PPPs and ISACs are concepts defined by ENISA, the concept of ISAO seems to be formulated in the US as a “group created to gather, analyse, and disseminate cyber threat information”, which is a concept similar to the ENISA definition of ISACs. According to the [Homeland security FAQ](https://www.dhs.gov/isao-faq) the main difference between ISACs and ISAOs is that “ISAOs are not directly tied to critical infrastructure sectors”. Instead, ISAOs offer a more flexible approach to self-organised information sharing activities amongst communities of interest such as small businesses across sectors.
What can be understood is that unlike the US definition, the EU definition of ISACs is not specifically tied to critical infrastructure sectors (similar to Operators of Essential Services in the EU), therefore aligning itself to the US definitions of both ISACs and ISAOs. The differences between ISACs, ISAOs and PPPs can be summarised in the table below:
|Features|ISAC|ISAO (US)|PPP|
|--- |--- |--- |--- |
|Geographical scope of applicability|Concept used internationally|Concept mainly used in the US|Concept used internationally|
|Formalisation & flexibility|More formal than PPPs|More flexible than US definition of ISAC|Less formal than ISAC|
|Ties to critical infrastructure sectors|EU: Broad scope, all critical infrastructure sectors and more, US: Tied to critical infrastructure sectors|Broad scope, all critical infrastructure sectors and more|Broad scope, all critical infrastructure sectors and more|
|Sector|EU: Cross sectors or sector-specific, cross countries or country-focus, US: Sector-specific and country-focused|Cross sectors or sector-specific, cross-country or country-focus|Cross sectors or sector-specific, cross countries or country-focus|
### Cooperation between information sharing communities, ISACs and X-ISAC
Cooperation not only takes place within an ISAC, but can also take place between ISACs. For example, the Finnish National Cyber Security Center (NCSC-FI) facilitates communication between multiple ISACs. The NCSC in the Netherlands and the Centre for Cybersecurity in Belgium have a similar setup.
In the context of cooperation between ISACs, the X-ISAC platform was created. The aim of X-ISAC is not only to assist communities in creating their own ISAC but also in encouraging ISACs to interconnect. X-ISAC is operated and maintained by the Computer Incident Response Center Luxembourg (CIRCL) and the MISP Project. It uses the MISP standard formats and technologies to enable information sharing communities to benefit from different sharing models. More information can be found on the [X-ISAC website](https://www.x-isac.org).
## Steps and guidelines to set up an information sharing community such as an ISAC
Information sharing communities facilitate digital interaction supported by tools as well as physical interaction, for example by attending meetings. In other words, an information sharing community is a community of entities or people interacting physically and virtually. The human factor is particularly important to build trust amongst the members of the community, as highlighted by ENISA, as described in their article [Tools and Methodologies to Support Cooperation between CSIRTs and Law Enforcement](https://www.enisa.europa.eu/publications/tools-and-methodologies-to-support-cooperation-between-csirts-and-law-enforcement).
For that to happen in an organised and scalable way, a minimum level of elaboration, formalisation and definition of rules can be implemented, the choice of which may vary depending on the information sharing community size and type.
The following chapters will suggest an approach to tackle the challenge of creating an information sharing community. Specifically, description of the steps to set-up information sharing communities will be provided along with resulting documents. The analysis laid down in the following chapter is based on questions and challenges that have been faced and experienced by organisations that have created information sharing communities.
### Level of the documentation
In many organisations, documents may be distinguished on three levels: policy level, standard level and procedural level as described below. Note that the documents mentioned throughout this guideline are non-exhaustive, but instead aim to provide a subset which could be considered as the most important ones for setting up an information sharing community.
* **Policies**: Formally documented management expectations and intentions. Policies are used to drive decisions and to ensure a consistent and appropriate development and implementation of processes, standards, roles, activities, IT infrastructure etc. A policy is usually technology or solution independent.
* **Standards/Guidelines**: Standards refer to mandatory activities, actions, or rules. Standards can give a policy support and reinforcement in terms of direction. They provide the means to ensure that specific technologies, applications, parameters, and procedures are implemented in a uniform (standardised) manner across the organisation. Guidelines are recommended actions and operational guides for when a specific standard does not apply.
* **Procedures**: Procedures are detailed step-by-step tasks that should be performed to achieve a certain goal. Procedures spell out how the policy, standards, and guidelines will actually be implemented in an operating environment.
### High-level steps to set up an information sharing community
The following infographic describes six suggested steps to set up an information sharing community, including eight recommended documents to be drafted. Each step will be further described and expanded on in the following chapters.
![High level steps to set up an information sharing community](./images/high-level-steps-ISAC-setup.svg)
## 1. Define your goals and foundation
### 1.1. Define your governance
#### 1.1.1. Define your vision, mission and purpose
Defining the vision, mission and purpose is key to keep the efforts of the information sharing community in the right direction and to communicate with third parties and potential new members. Answering the questions such as: “What do you want to accomplish with the creation of the information sharing community?” and “Are the information sharing community objectives clear?” can be of help for this step.
For example, REN-ISAC has defined [its mission](https://www.ren-isac.net/what-we-do/Mission.html).
#### 1.1.2. Create a legal structure if necessary
#### 1.1.3. <a name="1.1.3"></a> Choose the type(s) of agreements on information sharing
Information sharing is intrinsically about communication between parties, and communication usually involves some kind of agreement(s) to enable the involved parties to understand each other. In existing information sharing communities and specifically ISACs, different options may be considered to formalise those information sharing agreements. A non-exhaustive list of those options are discussed below.
“**Subscriber agreement**”, [as featured for example by A-ISAC](https://www.icao.int/cybersecurity/SiteAssets/A-ISAC/12_05_14_A-ISAC_Sub_Agmt_12_5_14_Final.pdf) is a **legally binding** type of agreement. It is more suitable for regulating the relationship between private entities (companies). It is also a solid option in case there are any **commercial activities** foreseen as part of the information sharing community. Subscriber agreements allow for the establishment of various types of memberships specifying the types of accessible information, the method of receiving it, the number of user IDs or the level of participation in the work groups. This type of agreement often describes **sanctions** in case of failure to comply with the requirements (e.g. termination of the agreement without a possibility to regain membership in the following X years).
“**Confidentiality/NDA agreement**” can be a separate document or can be integrated in a “subscriber agreement”, “operational rules” or “policy” as a “confidentiality/NDA clause”. It can be included in a contractual framework imposed on the parties (service providers or the organisations requesting their services). Such an agreement or clause establishes **what (type of) information can be considered as confidential**. In doing so, it might refer to confidential (“TLP Amber” or up) classification under the Traffic Light Protocol (TLP). It can also set obligations for the recipient of the confidential information, such as:
* to not disclose any confidential information to any third parties,
* not to use it except as needed in order to provide specific services or as required by law,
* limit the dissemination to those with the need to know, as well as
* notify immediately in case of misuse of this information, etc.
It is possible to include the definition of the “personal data” and “processing of personal data” in line with the data protection regulations such as the GDPR. Additionally, this type of agreement may provide the conditions under which the parties may be asked to disclose confidential information to law enforcement agencies, governmental authorities or other third parties.
“**Code of Conduct**” represents a non-legally binding document which provides straightforward instructions on the standard practices and provides guidance on the behaviour of the members of the organisation. It can include the values and the scope of the information sharing community, liability in case of misconduct and standard of practices, as well as actions (exclusively disciplinary). Additionally, a Code of Conduct is close to a gentlemen's agreement (see below), but has a written form and may be signed by all members (respectively candidates). An example can be found on the [E-ISAC web page](https://www.eisac.com/Documents/E-ISAC_Code_of_Conduct.pdf) or for a shorter version on the [CERT.LU web page](https://www.cert.lu/#about).
“**Memorandum of understanding**” (MoU). Unlike the “Code of Conduct”, the MoU is a bilateral agreement, which means it is usually signed by the information sharing community and an entity willing to establish a mutual framework for cooperation. This type of agreement is common for formalising information sharing initiatives with governmental agencies, law enforcement agencies, public entities or other information sharing communities/ISACs. It is usually provided under the MoU that information cannot be forwarded to other parties. Since the agreement is not legally enforceable, it does not create binding obligations to its parties. Yet, a violation of it may result in a warning or termination of membership (see an example [here](https://www.europol.europa.eu/publications-documents/public-redacted-ec3-memorandum-of-understanding-between-europol-and-f-secure-edoc-837500-v2)).
“**Gentlemens agreement**” is an informal agreement that is based on trust of the members of the organisation. It does not require any formalisation and is usually communicated orally. It is important to highlight the difference of the gentlemens agreement and a common verbal agreement (contract) that has a legally binding effect. Indeed, a contract can be established either verbally or in writing. However, in civil law countries (Luxembourg, France, Germany, etc.) a contract requires the following essential elements: it has to “offer” the terms which must be sufficiently clear and “acceptance” indicating the intention to be bound by the agreement [18] meaning that the parties shall explicitly make an agreement enforceable in law.
The table below summarises the different types of agreements:
|Agreements on information sharing|Use|Type|
|--- |--- |--- |
|Subscriber agreement|Is a solid option in case there are any commercial activities foreseen as part of the information sharing community|Legally binding|
|NDA |Usually bi-lateral, often used with law enforcement or government bodies|
|Code of conduct|Usually multi-lateral, provides straightforward instructions on the standard practices and guide the behaviour of the members of the organisation|Usually not legally binding but in written form|
|MoU|Usually bi-lateral, often used with law enforcement or government bodies|Usually not legally binding but in written form|
|Gentlemens agreement|Based on trust of the members of the organisation. It does not require any formalisation and usually takes oral form|Usually in oral form|
However, based on experience with information sharing communities, not every information sharing community has formal agreements drafted. Many communities are built on trust and informal communication. Thus, the decision of whether to implement a formal information sharing agreement may also depend on the size and purpose of the information sharing community.
#### 1.1.4. Define what would be the consequences for non-compliance with the information sharing community rules
Consequences for non-compliance are commonly described in agreements on information sharing.
#### 1.1.5. Define what would happen if an entity decides to leave the sharing community (exit/termination clause) or changes its status
Exit clauses are commonly described in agreements on information sharing. For example, members leaving the information sharing community may be required to destroy all information received.
Beyond exit clauses, a sharing community may agree on the consequences of two or more members merging. For example, whether to create one entity or keep entities separated in an information sharing platform such as MISP. Member A merging with member B may not be given the access to information previously restricted to member B for example.
More generally, questions can be raised on what to do when a member changes its (legal) status. For example, entities based in the UK might leave the EU and may no longer have the right to share information within sharing communities located in the EU.
#### 1.1.6. Define the organisation of your sharing community
Information sharing communities' governance may vary from formally defined structures with a chairman, management board and secretariat to less defined ones with volunteers and work load distribution between information sharing community members. For example, every member of the information sharing community can participate in meeting organisation, e.g. by hosting the meeting themselves, ensuring that each time the host changes.
Information sharing communities seeking profit can also have different membership models depending on the level of service offered by the community. For example, FS-ISAC has [different types of membership](https://www.fsisac.com/sites/default/files/FS-ISAC_OperatingRules_June2016.pdf), from “critical modification only” to “platinum member”, depending on the type of information shared.
Membership models can also depend on the status of the members. For example, Global System for Mobile Communications Association (commonly referred as "GSMA") has [different types of memberships](https://www.gsma.com/membership/membership-types/) ("full", "associate" and "rapporteur") whether the member is a GSM licensed operator or involved in the mobile ecosystem.
#### 1.1.7. Choose the acceptance criteria of new members and plan future growth
Criteria for joining the information sharing community should be defined. Below are some examples of criteria and/or acceptance processes:
* All current members of the community need to vote for a new membership acceptance
* A current member of the community needs to guarantee that the future member can be trusted
* The future member should match a specific sector or localisation requirement (e.g. country)
* The future member should have had a direct face-to-face meeting or communication with a current member
* The future member should share common goals and/or objectives with the operator of the information sharing community
#### 1.1.8. Create a marketing and communication strategy
An information sharing community may define its communication strategy. For example, the information sharing community may want its number of members to remain limited in size. On the other hand, an information sharing community may want to grow and attract new members. The latter can be done for example by going to conferences and meetings about cybersecurity to invite organisations to join the community or having a website and publishing information.
## 2. Get organised
### 2.1. Define your service offering
Information sharing communities often have a couple of common capabilities such as information sharing, information analysis, trust building and capacity building. Information shared can be cyber threats, vulnerabilities, incidents, physical threats, mitigating measures, situational awareness, strategic analyses, best practices and tools.
#### 2.1.1. Decide what services you want the information sharing community to offer additionally to sharing
Examples of specific services or capabilities an information sharing community may offer in addition to the ones mentioned above are listed hereafter:
* Supporting forensic analysts
* Collaboration with law enforcement
* Vulnerability information sharing
* Security Operation Center (SOC) services
* Vulnerability management services
* Provide qualification services of the information shared
* Mutualisation of data collection and mining
### 2.2 Define your operating model
#### 2.2.1. Define the type of ISAC/information sharing community
Information sharing communities can be categorised according to two main axes: (1) whether the information sharing community is limited to one sector or it is crossing sectors, and (2) its geographical scope (e.g. country focused, EU, international scope).
#### <a name="2.2.2"></a> 2.2.2. Understand the benefit of cross-sectorial sharing
Cross-sectorial sharing may happen:
1. Inside a cross-sectorial information sharing community/ISAC.
2. Across information sharing communities e.g. in inter-ISACs collaboration. Cross-sectorial sharing may take place between two sector-specific ISACs of different sectors. Refer to chapter (3.2.1) for inter-ISACs cooperation.
A cross-sectorial information sharing community can bring the following benefits compared to a sector-specific sharing community:
* The reuse of TTPs and information across sectors, leading to **better threat detection and prevention** while being hit by a **threat another sector has previously faced**.
* An increase in **analysis capabilities** by broadening the correlation scope. It has been experienced that seemingly unrelated data may be interesting to correlate. Broadening the correlation scope is specifically interesting in analysing hybrid threats.
* By sharing with other sectors, members of a sharing community will be better prepared to share with a large audience, therefore increasing their **readiness** for **possible mandatory sharing obligations** and for **reaching out to CSIRTs** when needed.
Being a CSIRT, the more sectors you involve in your information sharing community, the more entities you can help increase their information sharing practices, and therefore, increasing the sharing maturity across sectors. Indeed, CSIRTs are generally speaking ahead when it comes to information sharing maturity.
### 2.3. Elaborate on your business model
#### 2.3.1. Choose your funding model
Examples of funding models can be:
* **Membership**, where members pay a fee to the information sharing community operator.
* **Subscription**, where members pay to subscribe to a service provided by the information sharing community.
* **Public fund**. In this model, an information sharing community can receive funding from public bodies and/or public grants.
* **Donation**. In some cases, organisations support the sharing community/ISAC without being a member while giving a donation to ensure the continued operation of the sharing community.
The funding models of sharing communities/ISACs can be mixed and evolving over time.
#### 2.3.2. Choose your funding mechanisms
A sharing community may seek profit or be a non-profit organisation. An information sharing community seeking profit may for example offer paid services to the community members or provide them for free but monetise them afterwards by using information collected along with the feedback received from members of the sharing community to improve their business.
## 3. Set up sharing rules
### 3.1. Draft your information exchange policy
An information exchange policy can include, according to [FIRST Information Exchanged Policy framework](https://www.first.org/iep/FIRST_IEP_framework_1_0.pdf) four parts:
* **Handling** policy statements define any obligations or controls on information received to ensure the confidentiality of information that is shared.
* **Action** policy statements define the permitted actions or uses of the information received that can be carried out by a recipient.
* **Sharing** policy statements define any permitted redistribution of information that is received. For example enforcing dissemination marking such as TLP. Also the sharing policy can define in which case information sharing is mandatory or voluntary.
* **Licensing** policy statements define any applicable agreements, licenses, or terms of use that governs the information being shared.
The following chapters provide guidelines to create the information exchange policy.
#### 3.1.1. Define obligations or controls on information received (Handling)
Refer to chapter 5. “Ensure security and compliance”.
#### 3.1.2. Define for what purpose the information shared can be used (Action)
#### 3.1.3. Define the license of the information shared (Licensing)
#### 3.1.4. Choose your dissemination marking and disclosure (Sharing)
Members may share information following the Traffic Light Protocol (TLP) and/or the Chatham House Rules. A policy may also help clarify the definition of TLP for the community.
REN ISAC has defined a [sensitivity marking including restriction in dissemination](https://www.ren-isac.net/membership/MembershipDocs/REN-ISAC_Info_Sharing_Policy.pdf), which also includes disclosure standards and breach reactions. E-ISAC has drafted those markings as well in their [information sharing policy](https://www.eisac.com/cartella/Asset/00006344/TLP_WHITE_E_ISAC_Guidance_4_2017.pdf?parent=64210).
Additionally, transposing other, existing information marking schemes (such as national classification levels), as required by the given sharing community are encouraged as long as a common understanding by the community members is expected and communicated.
#### 3.1.4. Identify whether a part of information shared is mandatory (e.g. regulatory) and/or voluntary sharing
In the EU, mandatory information sharing requirements may come from the NIS Directive requirements as well as Telecom, GDPR, PSD2 and national or local regulatory requirements. An information sharing community can share uniformly mandatory and voluntary information as long as the information is properly contextualised.
#### 3.1.5. Decide whether anonymity of member sharing is acceptable
An example of an anonymity clause can be found in the REN ISAC [non-attribution policy](https://www.ren-isac.net/membership/MembershipDocs/REN-ISAC_Info_Sharing_Policy.pdf).
For example, a member of the information sharing community can ask the information sharing community operator to publish its information in their stead. This feature is called ["delegation" in MISP](https://www.circl.lu/doc/misp/delegation/).
Another possibility to ensure members' anonymity when sharing is to provide the member intending to share information anonymous access. Usually the user receiving the delegation belongs to the entity operating the sharing community such as a CSIRT.
#### 3.1.6. Decide whether you allow for the existence of sub-communities and how you manage it
Based on the experience gained with information sharing communities, smaller subsets of members often form individual information sharing communities. For example within a national private-sector sharing community, specific communities related to financial institutions can form.
The operator of the information sharing community should decide whether the community allows a sub-set of members to share only amongst themselves. A subset of members may have separate contractual agreement(s) to share information only amongst the subset members. It is important for the community operator to use their best judgement to decide which communities should be separated from one another and whether compartmentalisation is the right approach for growing sub-communities.
The MISP software has different channels detailed below to enable sub-communities or subsets of members with the same interest to filter what information to share and receive:
* MISP allows the import and export of flat files, therefore enabling sub-communities to perform manual data transfers, outside of any network, in an air-gapped fashion.
* The MISP “[feeds](https://www.circl.lu/doc/misp/managing-feeds/)” can help compartmentalise information depending on specific interests of sub-communities.
* The [sharing groups feature](https://www.circl.lu/doc/misp/sharing/#sharing-groups) allows members of a sub-community to share exclusively between each other.
If you are a CSIRT running a national community, consider bootstrapping these sub-communities in order to assist them when they are starting out. Organisations can of course self-organise, but CSIRTs or the operator(s) of the sharing community are the ones with the expertise to get a sub-community started, for example by creating guidelines on what should be shared inside or outside of the given sub-community.
When bootstrapping sub-communities on behalf of a given sub-community as a CSIRT or an operator of the broader sharing community, ensure that the maintenance of the lifecycle for the created community is ensured, especially for changes in organisational membership. This can either be achieved by implementing policies on enrollment and disenrollment or by promoting trusted members of the sub-community to be able to self-organise.
### 3.2. Establish partnership and support
#### <a name="3.2.1"></a> 3.2.1. Choose whether and how inter-ISACs collaboration should happen
Refer to chapter <a href="#2.2.2">(2.2.2)</a> to understand the benefits of cross-sectorial sharing.
#### 3.2.2. Decide to have partnership with LEA/public entities and how
See part <a href="#1.1.3">(1.1.3) Choose the type(s) of agreements on information sharing </a> on how you may manage agreements with public entities.
## 4. Choose your mechanisms and tools
### 4.1. Define your information collection and dissemination standard and best practices
#### 4.1.1. Identify the relevant sources of data for sharing inside your information sharing community
For example, information exchanged can come from:
* Open Source INTelligence (OSINT)
* Aggregation of automated collection (sandboxing, honeypots, spamtraps, sensors)
* Situational awareness tools to monitor trends and adversary TTPs within my sector/geographical region
* Collection of information collected within incident response and analysis
* Forwarding of shared/procured intelligence, as long as redistribution to the community is authorised
#### 4.1.2. Encourage your members to start sharing
**Lead by example** is the first recommendation when it comes to encouraging members to share. Leading by example will naturally answer the following questions:
* What should the information look like?
* How should it be contextualised?
* What do you consider as useful information?
* What tools did you use to reach your conclusions?
* How can members make use of the shared information?
In order to convert passive members of your information sharing community into active ones, the following key points have proved to be useful:
* Keep mandatory quality controls to a minimum. Instead **lead by example** by following what you consider to be good practices.
* **Be patient** and rely on organic growth of the security practices of your members.
* Help your members increase their capabilities, for example by means of advice, training and workshops. **Organising sharing exercises** can motivate people to share.
* Increase and **maximise the value** of the shared information by activities such as validation, enriching the information shared and correlations. If the members perceive the information received as useful, they will be more inclined to share back.
* **Give credit** where credit is due, never steal the accolades of your community.
#### 4.1.3. Choose if you want to apply sharing requirements
Criteria required in order to remain in the information sharing community may also be defined (and may be documented in the membership agreement(s), refer to <a href="#agreement_types">(1.1) Choose the type(s) of agreements on information sharing</a>). Those criteria may include:
* meeting at least twice per year (hosted by members, in different European cities for example);
* physically attending meetings;
* sharing relevant information continuously.
From experience, only about 30% of the organisations within sharing communities actively share data. However, imposing too stringent sharing requirements to stay in the information sharing community may not be beneficial because of the following reasons:
* Organisations who would possibly benefit the most from it will lose protection.
* Organisations that want to stay above the threshold will start sharing junk and/or fake data.
* You lose organisations that might turn into valuable contributors in the future.
#### 4.1.4. Define the type of data to be shared
Information sharing communities may exchange the following types of information (non-exhaustive):
* Results and reports (historically, the most common case);
* Enhancements to existing data or information;
* Data validation (such as the level of usefulness or acknowledging true positives) and ageing false positives;
* Best practices and support from the community.
#### 4.1.5. Include context to increase value
Sharing raw technical information is a good start. However, to create more value for your community, always consider adding the **context** to the information shared:
* Context is for the most part of no benefit when dealing with an Intrusion Detection System (IDS). However, understanding the context of the information shared **helps analysts in understanding the threat landscape** and the "big picture".
* Adding context through classification is important for other members of the community so they can **evaluate the relevance for their own puroses when it comes to the shared data**. Have that in mind when classifying data.
* Adding context through classifying data becomes even more important in helping members **filter the most critical subsets of information** for their own defence once they have reached a certain maturity level.
#### 4.1.6. Choose your data model, vocabulary and taxonomies
A significant number of successful information sharing communities decided on common vocabularies from day one. This step is critical and allows members to filter information depending of their capabilities, willingness to process contextual information or just ingest indicators for detection or defensive matters. Having common vocabularies helps members to clarify the scope of the information shared and limit off-the-record discussions. For example, Cyber Security Sharing & Analytics (CSSA) in Germany did a [CSSA MISP taxonomy](https://www.misp-project.org/taxonomies.html#_cssa) which helps members to set the scope and especially the level of vetting about the information exchanged.
##### Taxonomy
**Deciding early on common vocabularies is key when it comes to planning for future growth**. For example, MISP has a versatile system of **taxonomies** for classifying and marking data. Taxonomies are hosted in an [independent repository](https://github.com/MISP/misp-taxonomies).
MISP taxonomies include different vocabularies with overlaps. To compensate, MISP allows restricting **individual vocabularies** and enforcing the restrictions in a MISP community, something that is recommended and can conveniently be achieved through the user interface of MISP, more details [here](https://www.circl.lu/doc/misp/taxonomy/). A first choice of taxonomies may be based on ISO 27010 requirements including classifying the information in terms of value, credibility, priority, criticality etc. [MISP supports most of those classification requirements.](https://www.misp-project.org/compliance/ISO-IEC-27010/).
If you do not find the vocabulary you're looking for, you can **create your own taxonomies** in JSON format, no coding skills are therefore required. If it is relevant, share it back to the community via a [pull request](https://help.github.com/articles/about-pull-requests/) in the [Taxonomies' Github repository](https://github.com/MISP/misp-taxonomies).
##### Galaxy
In addition to taxonomies, another classification system exists in MISP called **galaxies**. Galaxies are similar to taxonomies with the exception that they are more descriptive and enable the analyst to attach more complex and human friendly structures to the data. Galaxies are often used to describe attribution for example. The MISP project provides a curated list of [galaxy information](https://www.circl.lu/doc/misp/galaxy/). Galaxies can include different types of additional context and description that can be attached to the information shared, for example:
* Threat actor information;
* Specialised information such as ransomware and exploit kits;
* Methodology information such as preventive actions;
* Classification systems for methodologies used by adversaries, for example with the ATT&CK framework.
Consider improving the default galaxies or taxonomies libraries or contributing your own. Contribution to galaxies is simplified thanks to the use, as with taxonomies, of a simple JSON format. If you create a new set of Galaxies, you can share it back to the community by creating a pull request on the [MISP galaxy Github](https://github.com/MISP/misp-galaxy) and/or [MISP taxonomy Github](https://github.com/MISP/misp-taxonomies).
Galaxies can also be used to **share specific information to a limited set of members**. This can be achieved in multiple ways:
* By creating private galaxies and share the galaxys JSON file only with those members. That way, the members that do not have access to the galaxy definitions will not be able to link the information shared with the private galaxy. It is often the case when sharing information on attribution for example.
* By creating ad-hoc galaxy clusters within MISP directly and relying on MISP's sharing model to distribute it to the desired communties or sub-communities.
* Creating alternate perspectives on existing galaxy clusters by forking them and offering counter-perspectives to shared galaxies.
#### 4.1.8. Handle false-positives
You might often fall into the trap of discarding seemingly "junk" data. Besides volume limitations, which are a valid reason, the fear of false-positives is the most common reason for discarding data. Our recommendation is to be lenient when considering what to keep but to be strict when feeding detection or protection tools. MISP allows for the filtering of relevant data when on information retrieval, when for example feeding protective tools. For example, you can use the IDS toggle, by clicking ["For Intrusion Detection System" when creating an attribute](https://www.circl.lu/doc/misp/using-the-system/#add-attribute). You can also use different sets of taxonomies to indicate relevance of the data regarding protection and/or detection of threats. The combination of all of these datya-points can also be used to generate scoring for the information that can be used to automate the decision process. It is therefore recommended to **use MISP's features to eliminate obvious false-positives instead of limiting the data-set** to the most relevant sets.
The reason behind this is that seemingly junk data, as perceived by some entities, proved to be **critical to other** entities. Analysts will also often be interested in the modus operandi of threat actors over long periods of time and even cleaned up infected hosts might **become interesting again** (embedded in code, recurring reuse).
#### 4.1.9. Describe the objective of the indicator/IoC when sharing
Based on experience with information sharing communities, it is very helpful to include the **objective of the indicators** shared. For example, objectives of an IoC can include:
* The detection of the related malware or threat in an information system. In this case, the objective of the indicators is to help answer the following question: 'Do I have infected systems in my infrastructure or the ones I operate?'
* Sharing indicators to block. In this case, the objective of the indicators is to help answer the following question: 'Should I use these attributes to block, sinkhole or divert traffic?'
* Sharing indicators to perform intelligence, for example gathering information about campaigns and attacks. In this case, the objective of the indicators is to help answer the following question: Are attacks related? Who is targeting me? Who are the adversaries?'
One needs however to be careful because those objectives, specifically those used for blocking actions, may lead to an operational impact. For example blocking on false-positive indicators can have significant operational impacts.
### 4.2. Establish your sharing model and mechanisms
#### 4.2.1. Define your collaboration mechanisms
Collaboration mechanisms include regular meetings (i.e. “circles of trust”), working groups, ad hoc investigative working groups, conferences, side events, web portals and platforms. Tools and methods such as MISP, encrypted emails and teleconferences software can be used to support those mechanisms.
For example, REN-ISAC [sharing channels](https://www.ren-isac.net/membership/MembershipDocs/REN-ISAC_Info_Sharing_Policy.pdf) includes mailing lists, IRC, webcasts, conference calls, in-person meetings, wiki, data feeds, and person-to-person.
#### 4.2.2. Determine your MISP setup (if applicable)
Having an estimation of the requirements for your infrastructure is key to plan for future growth.
Your information sharing community can share information either through a MISP instance owned and hosted by you, or through other parties MISP instances. If your information sharing community aims at being based on MISP as a platform for automated information sharing, the following possibilities may be taken into account, especially if you want to share information with a CSIRTs MISP instance:
* Using a MISP instance hosted by a CSIRT. Small information sharing communities may ask a CSIRT to create a sharing group on the CISRTs instance for example if they want to avoid the burden of creating and hosting a MISP instance themselves.
* Hosting your own instance and connecting to a CSIRT's MISP instance. This allows a flexible scheme especially if your information sharing communities provide additional services.
* It is also common to mix and match the above options, with some members electing to use a hosted instance, whilst others run their own, connected instances.
#### 4.2.3. Setup Face-to-face meetings to foster trust
Sharing difficulties are not only technical issues but often a matter of social interactions i.e. trust. You can play a role here: organising regular workshops, conferences and having face-to-face meetings to foster trust.
Additionally, informal breaks, lunches or dinners can be organised so that members can get to know each other. Specific trainings or workshops can be organised with specific goals such as:
* Improving the information shared by showing practical sessions on how information is contextualised and structured.
* How integration can be performed with the members' tools in order to improve automation and ingestion of the information shared.
## 5. Ensure security and compliance
### 5.1 Secure data and systems
#### 5.1.1. Define your security requirements
Security requirements can be applied to:
* data in transit, i.e. while sharing;
* data at rest, e.g. data in the information sharing community's centralised database (e.g. MISP database) and in each members storage facilities.
Information sharing communities can for example enforce PGP communication when emails are used, encryption of traffic and other security controls.
Additionally, MISP communities can choose to restrict sharing of more critical information with additional cryptographic signing requirements, to tamper-proof the data in broader communities.
Some sharing communities may also **require their members to have their own MISP instance** synchronised with the one of the sharing community. This increases privacy as the operator of the MISP instance of the sharing community does not have access to each member's queries and searches. Doing so also improves the performance of the central MISP instance of the community.
Resources to manage information security in sharing communities exists such as the ISO/IEC 27010 standard. ISO/IEC 27010:2015, covers Information security management for inter-sector and inter-organisational communications.
More details on how MISP can be used as a supporting platform for sharing information, following ISO/IEC 27010:2015 can be found [here](https://www.misp-project.org/compliance/ISO-IEC-27010/).
### 5.2 Ensure compliance
#### 5.2.1. Explain how to pseudonymise the information to be shared
In some cases, pseudonymised information will be shared among information sharing communities. A trade-off must be ensured between the usefulness of information shared versus the compliance aspects. Pseudonymised information such as indicators (IP addresses) can often lead to information which cannot be automated or further processed to protect or mitigate a threat. When pseudonymisation is applied, describing the algorithms or techniques used is highly recommended to help the recipient of information about the level of pseudonymisation. MISP comes with [a set of object templates](https://www.misp-project.org/objects.html#_anonymisation) to create a relationship between the pseudonymisation techniques with the information shared.
#### 5.2.2. Create data protection clauses in agreements or policies
#### 5.2.3. Create a privacy notice toward data subject for ISAC website and ISAC services
The following are an example of ISAC websites privacy notices: [Government of India ISACs website](https://www.isac.io/privacy-policy/). Provide a way to reach out your ISAC or sharing communities if a data subject has any question or specific request regarding privacy matters.
Depending of your use-cases, public processing activities can be published in order to provide transparency towards potential data subject where information could be processed in your sharing community. CIRCL provides a schema which describes processing activities which can serve as a basis for outlining the sharing of your processing activities.
## 6. Follow-up and improve
### 6.1 Measure, evaluate and improve your ISAC
#### 6.1.1. Measure effectiveness of sharing
In order to maintain a level of effectiveness in the information sharing and exchange process, the ISACs/sharing community has to provide practical measurements on the exchanged information. Different measurements can be performed such as:
- Sighting on the information exchanged which provides a way to members to acknowledge the usefulness or uselessness of information;
- Allowing members to contribute the exchanged information back by correcting or enhancing them, in order to avoid unidirectional communication;
- Building statistics of access and also on collaboration practices within the ISAC/sharing community.
MISP provides a set of features to help with providing sightings, collaborating via proposals and gathering global statistics of the sharing community.
#### 6.1.2. Evaluate members needs for the development of new services
Information sharing is a dynamic process, which depends on external factors such as:
- Change of techniques in fraud practices, threats and TTPs used by the adversaries;
- Updates in regulation and legal context;
- Organisational changes in the members network;
Information sharing communities and ISACs need to accommodate with such changes. Ensuring flexibility in the information sharing process is then critical. MISP provides a flexible way called [MISP objects](https://www.misp-project.org/objects.html) to easily update the format of the exchanged information. This offers an independence to the ISACs regarding the standard format and a rapid response time to ensure the distribution of new techniques and threats encountered by the members of the sharing community.
## References
1. ENISA, Information Sharing and Analysis Centres (ISACs) Cooperating model, 2017
2. ENISA, European Financial Institutes Information Sharing and Analysis Centre, A Public-Private Partnership
3. CIRCL, [Information sharing and cooperation enabled by GDPR](https://www.misp-project.org/compliance/gdpr/), 2018
4. The office of National Coordinator for Health Information Technology, ISAO Initiative Update, 2016.10.05
5. ENISA, Cooperative Models for Effective Public Private Partnerships Good Practice Guide, 2011
6. ISO/IEC - 27010:2015 Information security management for inter-sector and inter-organizational communications, 2015
7. ISAO Standards Organization, Information Sharing and Analysis Organization (ISAO) Standards Organization (SO), 2017.03.28
8. ISAO Standards Organization, 300.1 Introduction to Information Sharing, 2016
9. ISAO Standards Organization, 100.2 Guidelines for Establishing an ISAO, 2016
10. ISAO Standards Organization, 700-1 Introduction to Analysis, 2018
11. ISAO Standards Organization, 600-1 A Framework for State-Level Information Sharing and Analysis Organizations, 2018
12. ISAO Standards Organization, ISAO Product Outline, 2016
13. ISAO Standards Organization, ISAO Startup Topics, 2016
14. ISAO Standards Organization, Cybersecurity-Related Information Sharing Guidelines, 2016
15. FS-ISAC, Operating rules, 2016
16. REN-ISAC, Information Sharing Policy, 2018
17. CIRCL, [Introduction into Information Sharing using MISP for CSIRTs](www.circl.lu/assets/files/misp-training/latest/16-infosharing-communities.pdf), 2018
18. [Pilar Perales Viscasillas, M. “The Formation of Contact and the Principles of European Contact law” Pace International Law Review, Volume 13, Issue 2 Fal 2001. P.7.](https://digitalcommons.pace.edu/cgi/viewcontent.cgi?article=1215&context=pilr)
## Acknowledgement
This document was partially funded by CEF (Connecting Europe Facility) funding under CEF-TC-2016-3 - Cyber Security ***Improving MISP as building blocks for next-generation information sharing***.
![](https://www.misp-project.org/assets/images/en_cef.png)
## Contact and collaboration
If you have any question or suggestion about this topic, feel free to [contact us](https://www.circl.lu/contact/). This document is a collaborative effort where external [contributors can propose changes and improvement](https://github.com/MISP/misp-compliance/tree/master/setting-up-ISACs) the document.
![](./images/x-isac.pdf)
![](./images/misp.pdf)
![](./images/logo-circl.pdf)
~~~~
CIRCL - Computer Incident Response Center Luxembourg
c/o "security made in Lëtzebuerg" (SMILE) g.i.e.
16, bd d'Avranches
L-1160 Luxembourg
Grand-Duchy of Luxembourg
~~~~

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 653 KiB

Binary file not shown.

Binary file not shown.

View File

@ -0,0 +1,183 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 21.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
viewBox="0 0 398.7 176.5" style="enable-background:new 0 0 398.7 176.5;" xml:space="preserve">
<style type="text/css">
.st0{fill:none;stroke:#4E4E50;stroke-width:8;stroke-miterlimit:10;}
.st1{opacity:0.26;fill:#4E4E50;}
.st2{fill:#C7C9CA;}
.st3{fill:#4E4E50;}
.st4{fill:#2A8ED1;}
.st5{fill:#1960AE;}
.st6{fill:#E7191C;}
.st7{fill:#97999C;}
.st8{fill:#FFFFFF;}
.st9{fill:#D3D4D3;}
.st10{fill:#515151;}
.st11{fill:#A3A2A2;}
.st12{fill:#7C7C7C;}
.st13{fill:#A9A9A8;}
.st14{fill:#A9AAA9;}
</style>
<path class="st2" d="M86.6,165.5c-13.8-0.4-27.5-4.1-39.4-10.9c-2.9-1.9-5.9-3.5-8.5-5.7l-4-3.2l-3.7-3.5l-1.9-1.8l-1.7-1.9
l-3.4-3.8l-3-4.1c-1-1.4-2-2.8-2.8-4.3l-2.5-4.4c-0.8-1.5-1.4-3.1-2.2-4.6c-1.5-3-2.5-6.3-3.6-9.5c-0.6-1.6-0.8-3.3-1.3-4.9
c-0.3-1.7-0.9-3.3-1-4.9c-0.4-3.3-1-6.7-1-10C6.2,74.6,8.9,61,14.9,49.2C26.5,25.1,51,8.4,77,5.9c12.9-1.5,26.2,0.6,38,5.6
c11.9,4.9,22.4,13.1,30.3,23c-8.4-9.6-19-17.2-30.9-21.5c-11.8-4.4-24.7-5.8-37-3.9c-24.8,3.5-46.9,20.3-56.6,42.8
c-5.1,11.1-7,23.5-6,35.5c0.1,3,0.8,6,1.3,8.9c0.2,1.5,0.8,2.9,1.1,4.4c0.4,1.4,0.7,2.9,1.3,4.3c1.1,2.8,2,5.6,3.5,8.3
c0.7,1.3,1.3,2.7,2.1,4l2.4,3.8c0.8,1.3,1.7,2.5,2.6,3.6l2.8,3.5l3.1,3.2l1.5,1.6l1.7,1.5l3.4,2.9l3.6,2.6c2.3,1.8,5,3.1,7.5,4.6
c10.5,5.4,22.3,8.1,33.9,7.9V165.5z"/>
<g>
<path class="st3" d="M195.6,57.4v72.3h-16.4V57.4H195.6z"/>
<path class="st3" d="M210.3,112.8c4.4,2.3,11.2,4.5,18.1,4.5c7.5,0,11.5-3.1,11.5-7.8c0-4.5-3.4-7.1-12.1-10.2
C215.8,95.1,208,88.5,208,78c0-12.3,10.3-21.8,27.4-21.8c8.2,0,14.2,1.7,18.5,3.6L250.1,73c-2.9-1.4-8-3.4-15.1-3.4
c-7.1,0-10.5,3.2-10.5,7c0,4.6,4.1,6.7,13.4,10.2c12.8,4.7,18.8,11.4,18.8,21.6c0,12.1-9.3,22.4-29.2,22.4
c-8.3,0-16.4-2.1-20.5-4.4L210.3,112.8z"/>
<path class="st3" d="M284.6,111.1l-5.2,18.6h-17l22.1-72.3H306l22.4,72.3h-17.6l-5.6-18.6H284.6z M302.9,98.9l-4.5-15.3
c-1.3-4.3-2.6-9.7-3.6-14h-0.2c-1.1,4.3-2.1,9.8-3.3,14l-4.3,15.3H302.9z"/>
<path class="st3" d="M388.6,127.7c-3,1.5-9.8,3.1-18.6,3.1c-25,0-37.9-15.6-37.9-36.2c0-24.7,17.6-38.4,39.5-38.4
c8.5,0,14.9,1.7,17.8,3.2l-3.3,13c-3.3-1.4-7.9-2.7-13.7-2.7c-13,0-23.1,7.8-23.1,23.9c0,14.5,8.6,23.6,23.2,23.6
c4.9,0,10.4-1.1,13.6-2.4L388.6,127.7z"/>
</g>
<g>
<polygon class="st4" points="57.6,94.8 114.2,38.2 134.6,58.6 98.4,94.8 134.6,131 114.2,151.4 "/>
</g>
<polyline class="st5" points="78,74.4 81.4,71 101.8,91.4 98.3,94.9 "/>
<polyline class="st5" points="98.4,94.7 101.8,98.2 81.4,118.6 77.9,115.1 "/>
<g>
<path class="st6" d="M98.4,94.8L42,151.2c0,0-5.6-3.7-11.8-9.8c-6.2-6.2-8.7-10.5-8.7-10.5l36.2-36.2L21.4,58.6l20.4-20.4
L98.4,94.8z"/>
</g>
<rect x="99.4" y="92.4" transform="matrix(0.7071 0.7071 -0.7071 0.7071 96.8464 -44.219)" class="st7" width="4.8" height="4.8"/>
<rect x="137.6" y="91" class="st7" width="26" height="7.9"/>
<g>
<path class="st3" d="M179.8,141.1c0.5-0.1,1.4-0.2,2.3-0.2c1.2,0,2.1,0.2,2.7,0.7c0.5,0.4,0.8,0.9,0.8,1.7c0,0.9-0.6,1.7-1.6,2.1v0
c0.9,0.2,2,1,2,2.4c0,0.8-0.3,1.5-0.8,1.9c-0.7,0.6-1.8,0.9-3.3,0.9c-0.9,0-1.5-0.1-1.9-0.1V141.1z M181.1,145h1.1
c1.3,0,2.1-0.7,2.1-1.6c0-1.1-0.9-1.6-2.1-1.6c-0.6,0-0.9,0-1.1,0.1V145z M181.1,149.7c0.2,0,0.6,0.1,1,0.1c1.3,0,2.5-0.5,2.5-1.9
c0-1.3-1.1-1.9-2.5-1.9h-1V149.7z"/>
<path class="st3" d="M187.5,145.9c0-0.8,0-1.5-0.1-2.2h1.1l0,1.4h0.1c0.3-0.9,1.1-1.5,1.9-1.5c0.1,0,0.2,0,0.4,0v1.2
c-0.1,0-0.3,0-0.4,0c-0.9,0-1.5,0.7-1.7,1.6c0,0.2-0.1,0.4-0.1,0.6v3.7h-1.2V145.9z"/>
<path class="st3" d="M193.7,141.7c0,0.4-0.3,0.8-0.8,0.8c-0.4,0-0.8-0.3-0.8-0.8c0-0.4,0.3-0.8,0.8-0.8
C193.4,140.9,193.7,141.3,193.7,141.7z M192.3,150.6v-6.9h1.3v6.9H192.3z"/>
<path class="st3" d="M201.6,140.4v8.4c0,0.6,0,1.3,0.1,1.8h-1.1l-0.1-1.2h0c-0.4,0.8-1.2,1.4-2.4,1.4c-1.7,0-3-1.4-3-3.5
c0-2.3,1.4-3.7,3.1-3.7c1.1,0,1.8,0.5,2.1,1.1h0v-4.1H201.6z M200.4,146.5c0-0.2,0-0.4-0.1-0.5c-0.2-0.8-0.9-1.5-1.8-1.5
c-1.3,0-2.1,1.1-2.1,2.7c0,1.4,0.7,2.6,2.1,2.6c0.8,0,1.6-0.6,1.9-1.5c0-0.2,0.1-0.3,0.1-0.5V146.5z"/>
<path class="st3" d="M209.7,143.7c0,0.5-0.1,1.1-0.1,1.9v4c0,1.6-0.3,2.6-1,3.2c-0.7,0.6-1.7,0.8-2.5,0.8c-0.8,0-1.7-0.2-2.3-0.6
l0.3-1c0.5,0.3,1.2,0.5,2,0.5c1.3,0,2.2-0.7,2.2-2.4v-0.8h0c-0.4,0.6-1.1,1.2-2.2,1.2c-1.7,0-3-1.5-3-3.4c0-2.4,1.5-3.7,3.1-3.7
c1.2,0,1.9,0.6,2.2,1.2h0l0.1-1H209.7z M208.4,146.4c0-0.2,0-0.4-0.1-0.6c-0.2-0.7-0.8-1.3-1.8-1.3c-1.2,0-2.1,1-2.1,2.6
c0,1.4,0.7,2.5,2.1,2.5c0.8,0,1.5-0.5,1.7-1.3c0.1-0.2,0.1-0.5,0.1-0.7V146.4z"/>
<path class="st3" d="M213.1,141.7c0,0.4-0.3,0.8-0.8,0.8c-0.4,0-0.8-0.3-0.8-0.8c0-0.4,0.3-0.8,0.8-0.8
C212.8,140.9,213.1,141.3,213.1,141.7z M211.7,150.6v-6.9h1.3v6.9H211.7z"/>
<path class="st3" d="M215,145.6c0-0.7,0-1.3-0.1-1.9h1.1l0.1,1.1h0c0.3-0.7,1.1-1.3,2.3-1.3c1,0,2.5,0.6,2.5,3v4.1h-1.3v-4
c0-1.1-0.4-2.1-1.6-2.1c-0.8,0-1.5,0.6-1.7,1.3c-0.1,0.2-0.1,0.4-0.1,0.6v4.2H215V145.6z"/>
<path class="st3" d="M229,143.7c0,0.5-0.1,1.1-0.1,1.9v4c0,1.6-0.3,2.6-1,3.2c-0.7,0.6-1.7,0.8-2.5,0.8c-0.8,0-1.7-0.2-2.3-0.6
l0.3-1c0.5,0.3,1.2,0.5,2,0.5c1.3,0,2.2-0.7,2.2-2.4v-0.8h0c-0.4,0.6-1.1,1.2-2.2,1.2c-1.7,0-3-1.5-3-3.4c0-2.4,1.5-3.7,3.1-3.7
c1.2,0,1.9,0.6,2.2,1.2h0l0.1-1H229z M227.7,146.4c0-0.2,0-0.4-0.1-0.6c-0.2-0.7-0.8-1.3-1.8-1.3c-1.2,0-2.1,1-2.1,2.6
c0,1.4,0.7,2.5,2.1,2.5c0.8,0,1.5-0.5,1.7-1.3c0.1-0.2,0.1-0.5,0.1-0.7V146.4z"/>
<path class="st3" d="M239,150.4c-0.3,0.2-1.1,0.4-2,0.4c-2.1,0-3.5-1.4-3.5-3.5c0-2.1,1.5-3.7,3.7-3.7c0.7,0,1.4,0.2,1.7,0.4
l-0.3,1c-0.3-0.2-0.8-0.3-1.5-0.3c-1.6,0-2.5,1.2-2.5,2.6c0,1.6,1,2.6,2.4,2.6c0.7,0,1.2-0.2,1.5-0.3L239,150.4z"/>
<path class="st3" d="M246.7,147.1c0,2.6-1.8,3.7-3.5,3.7c-1.9,0-3.3-1.4-3.3-3.6c0-2.3,1.5-3.7,3.4-3.7
C245.3,143.5,246.7,145,246.7,147.1z M241.2,147.2c0,1.5,0.9,2.7,2.1,2.7c1.2,0,2.1-1.1,2.1-2.7c0-1.2-0.6-2.7-2.1-2.7
C241.8,144.5,241.2,145.9,241.2,147.2z"/>
<path class="st3" d="M248.3,145.6c0-0.7,0-1.3-0.1-1.9h1.1l0.1,1.1h0c0.4-0.7,1-1.3,2.2-1.3c0.9,0,1.7,0.6,2,1.4h0
c0.2-0.4,0.5-0.7,0.8-0.9c0.4-0.3,0.9-0.5,1.5-0.5c0.9,0,2.3,0.6,2.3,3v4.1h-1.2v-3.9c0-1.3-0.5-2.1-1.5-2.1
c-0.7,0-1.3,0.5-1.5,1.1c-0.1,0.2-0.1,0.4-0.1,0.6v4.3h-1.2v-4.2c0-1.1-0.5-1.9-1.4-1.9c-0.8,0-1.4,0.6-1.6,1.3
c-0.1,0.2-0.1,0.4-0.1,0.6v4.2h-1.2V145.6z"/>
<path class="st3" d="M260.2,145.6c0-0.7,0-1.3-0.1-1.9h1.1l0.1,1.1h0c0.4-0.7,1-1.3,2.2-1.3c0.9,0,1.7,0.6,2,1.4h0
c0.2-0.4,0.5-0.7,0.8-0.9c0.4-0.3,0.9-0.5,1.5-0.5c0.9,0,2.3,0.6,2.3,3v4.1h-1.2v-3.9c0-1.3-0.5-2.1-1.5-2.1
c-0.7,0-1.3,0.5-1.5,1.1c-0.1,0.2-0.1,0.4-0.1,0.6v4.3h-1.2v-4.2c0-1.1-0.5-1.9-1.4-1.9c-0.8,0-1.4,0.6-1.6,1.3
c-0.1,0.2-0.1,0.4-0.1,0.6v4.2h-1.2V145.6z"/>
<path class="st3" d="M278,148.7c0,0.7,0,1.3,0.1,1.9h-1.1l-0.1-1.1h0c-0.3,0.6-1.1,1.3-2.3,1.3c-1.1,0-2.4-0.6-2.4-3v-4.1h1.3v3.8
c0,1.3,0.4,2.2,1.5,2.2c0.8,0,1.4-0.6,1.7-1.1c0.1-0.2,0.1-0.4,0.1-0.6v-4.3h1.3V148.7z"/>
<path class="st3" d="M280.1,145.6c0-0.7,0-1.3-0.1-1.9h1.1l0.1,1.1h0c0.3-0.7,1.1-1.3,2.3-1.3c1,0,2.5,0.6,2.5,3v4.1h-1.3v-4
c0-1.1-0.4-2.1-1.6-2.1c-0.8,0-1.5,0.6-1.7,1.3c-0.1,0.2-0.1,0.4-0.1,0.6v4.2h-1.3V145.6z"/>
<path class="st3" d="M289.5,141.7c0,0.4-0.3,0.8-0.8,0.8c-0.4,0-0.8-0.3-0.8-0.8c0-0.4,0.3-0.8,0.8-0.8
C289.2,140.9,289.5,141.3,289.5,141.7z M288.1,150.6v-6.9h1.3v6.9H288.1z"/>
<path class="st3" d="M292.9,141.7v2h1.8v1h-1.8v3.7c0,0.9,0.2,1.3,0.9,1.3c0.3,0,0.6,0,0.7-0.1l0.1,0.9c-0.2,0.1-0.6,0.2-1.1,0.2
c-0.6,0-1.1-0.2-1.4-0.5c-0.4-0.4-0.5-1-0.5-1.8v-3.8h-1.1v-1h1.1V142L292.9,141.7z"/>
<path class="st3" d="M297.6,141.7c0,0.4-0.3,0.8-0.8,0.8c-0.4,0-0.8-0.3-0.8-0.8c0-0.4,0.3-0.8,0.8-0.8
C297.3,140.9,297.6,141.3,297.6,141.7z M296.2,150.6v-6.9h1.3v6.9H296.2z"/>
<path class="st3" d="M300.2,147.4c0,1.7,1.1,2.4,2.4,2.4c0.9,0,1.4-0.2,1.9-0.4l0.2,0.9c-0.4,0.2-1.2,0.4-2.3,0.4
c-2.1,0-3.4-1.4-3.4-3.5c0-2.1,1.2-3.7,3.3-3.7c2.3,0,2.9,2,2.9,3.3c0,0.3,0,0.5,0,0.6H300.2z M303.9,146.5c0-0.8-0.3-2.1-1.7-2.1
c-1.3,0-1.8,1.2-1.9,2.1H303.9z"/>
<path class="st3" d="M306.5,149.3c0.4,0.2,1,0.5,1.7,0.5c0.9,0,1.3-0.5,1.3-1c0-0.6-0.4-0.9-1.3-1.3c-1.2-0.4-1.8-1.1-1.8-2
c0-1.1,0.9-2,2.4-2c0.7,0,1.3,0.2,1.7,0.4l-0.3,0.9c-0.3-0.2-0.8-0.4-1.4-0.4c-0.7,0-1.2,0.4-1.2,0.9c0,0.6,0.4,0.8,1.3,1.2
c1.2,0.5,1.8,1.1,1.8,2.1c0,1.2-0.9,2.1-2.6,2.1c-0.8,0-1.5-0.2-1.9-0.5L306.5,149.3z"/>
<path class="st3" d="M315.5,150.6v-6h-1v-1h1v-0.3c0-1,0.2-1.9,0.8-2.4c0.5-0.5,1.1-0.6,1.7-0.6c0.4,0,0.8,0.1,1.1,0.2l-0.2,1
c-0.2-0.1-0.4-0.2-0.8-0.2c-1.1,0-1.3,0.9-1.3,2v0.4h1.7v1h-1.7v6H315.5z"/>
<path class="st3" d="M325.7,147.1c0,2.6-1.8,3.7-3.5,3.7c-1.9,0-3.3-1.4-3.3-3.6c0-2.3,1.5-3.7,3.4-3.7
C324.4,143.5,325.7,145,325.7,147.1z M320.2,147.2c0,1.5,0.9,2.7,2.1,2.7c1.2,0,2.1-1.1,2.1-2.7c0-1.2-0.6-2.7-2.1-2.7
C320.8,144.5,320.2,145.9,320.2,147.2z"/>
<path class="st3" d="M327.3,145.9c0-0.8,0-1.5-0.1-2.2h1.1l0,1.4h0.1c0.3-0.9,1.1-1.5,1.9-1.5c0.1,0,0.2,0,0.4,0v1.2
c-0.1,0-0.3,0-0.4,0c-0.9,0-1.5,0.7-1.7,1.6c0,0.2-0.1,0.4-0.1,0.6v3.7h-1.2V145.9z"/>
<path class="st3" d="M181.9,158.2v9.7h-2.2v-9.7H181.9z"/>
<path class="st3" d="M183.7,163.1c0-0.9,0-1.6-0.1-2.2h1.9l0.1,1h0c0.3-0.4,1-1.1,2.2-1.1c1.4,0,2.5,0.9,2.5,3v4.2h-2.2V164
c0-0.9-0.3-1.5-1.1-1.5c-0.6,0-1,0.4-1.1,0.8c-0.1,0.1-0.1,0.3-0.1,0.5v4h-2.2V163.1z"/>
<path class="st3" d="M192.4,167.8v-5.4h-0.9v-1.6h0.9v-0.3c0-0.8,0.3-1.8,0.9-2.4c0.5-0.5,1.3-0.7,1.9-0.7c0.5,0,0.9,0.1,1.2,0.1
l-0.1,1.7c-0.2-0.1-0.4-0.1-0.7-0.1c-0.7,0-1,0.6-1,1.2v0.4h1.4v1.6h-1.4v5.4H192.4z"/>
<path class="st3" d="M203.8,164.3c0,2.6-1.8,3.7-3.7,3.7c-2.1,0-3.6-1.3-3.6-3.6c0-2.3,1.5-3.7,3.7-3.7
C202.4,160.7,203.8,162.1,203.8,164.3z M198.7,164.3c0,1.2,0.5,2.1,1.4,2.1c0.8,0,1.4-0.8,1.4-2.1c0-1-0.4-2.1-1.4-2.1
C199.1,162.2,198.7,163.3,198.7,164.3z"/>
<path class="st3" d="M205.2,163.1c0-1,0-1.7-0.1-2.3h1.9l0.1,1.3h0.1c0.4-1,1.2-1.4,1.9-1.4c0.2,0,0.3,0,0.5,0v2.1
c-0.2,0-0.3-0.1-0.6-0.1c-0.8,0-1.3,0.4-1.5,1.1c0,0.1,0,0.3,0,0.5v3.6h-2.2V163.1z"/>
<path class="st3" d="M210.6,163.1c0-0.9,0-1.6-0.1-2.2h1.8l0.1,0.9h0c0.3-0.4,0.9-1.1,2.1-1.1c0.9,0,1.6,0.5,1.9,1.2h0
c0.3-0.4,0.6-0.6,0.9-0.8c0.4-0.2,0.8-0.3,1.3-0.3c1.3,0,2.4,0.9,2.4,3v4.1h-2.1V164c0-1-0.3-1.6-1-1.6c-0.5,0-0.9,0.3-1,0.8
c-0.1,0.2-0.1,0.4-0.1,0.6v4.1h-2.1v-3.9c0-0.9-0.3-1.5-1-1.5c-0.6,0-0.9,0.4-1,0.8c-0.1,0.2-0.1,0.4-0.1,0.5v4.1h-2.1V163.1z"/>
<path class="st3" d="M226.9,167.8l-0.1-0.7h0c-0.5,0.6-1.2,0.9-2,0.9c-1.4,0-2.3-1-2.3-2.2c0-1.8,1.6-2.7,4.1-2.7v-0.1
c0-0.4-0.2-0.9-1.3-0.9c-0.7,0-1.5,0.2-1.9,0.5l-0.4-1.4c0.5-0.3,1.4-0.6,2.7-0.6c2.3,0,3.1,1.4,3.1,3v2.4c0,0.7,0,1.3,0.1,1.7
H226.9z M226.7,164.5c-1.1,0-2,0.3-2,1.1c0,0.6,0.4,0.8,0.9,0.8c0.5,0,1-0.4,1.1-0.8c0-0.1,0-0.2,0-0.4V164.5z"/>
<path class="st3" d="M232.8,158.8v2h1.6v1.6h-1.6v2.5c0,0.8,0.2,1.2,0.9,1.2c0.3,0,0.5,0,0.6-0.1l0,1.6c-0.3,0.1-0.8,0.2-1.4,0.2
c-0.7,0-1.3-0.2-1.6-0.6c-0.4-0.4-0.6-1.1-0.6-2.1v-2.9h-0.9v-1.6h0.9v-1.5L232.8,158.8z"/>
<path class="st3" d="M237.9,158.9c0,0.6-0.5,1.1-1.2,1.1c-0.7,0-1.1-0.5-1.1-1.1c0-0.6,0.4-1.1,1.1-1.1
C237.5,157.8,237.9,158.2,237.9,158.9z M235.7,167.8v-7h2.2v7H235.7z"/>
<path class="st3" d="M246.5,164.3c0,2.6-1.8,3.7-3.7,3.7c-2.1,0-3.6-1.3-3.6-3.6c0-2.3,1.5-3.7,3.7-3.7
C245.1,160.7,246.5,162.1,246.5,164.3z M241.4,164.3c0,1.2,0.5,2.1,1.4,2.1c0.8,0,1.4-0.8,1.4-2.1c0-1-0.4-2.1-1.4-2.1
C241.8,162.2,241.4,163.3,241.4,164.3z"/>
<path class="st3" d="M247.9,163.1c0-0.9,0-1.6-0.1-2.2h1.9l0.1,1h0c0.3-0.4,1-1.1,2.2-1.1c1.4,0,2.5,0.9,2.5,3v4.2h-2.2V164
c0-0.9-0.3-1.5-1.1-1.5c-0.6,0-1,0.4-1.1,0.8c-0.1,0.1-0.1,0.3-0.1,0.5v4h-2.2V163.1z"/>
<path class="st3" d="M259.3,165.6c0.6,0.3,1.5,0.6,2.4,0.6c1,0,1.5-0.4,1.5-1c0-0.6-0.5-0.9-1.6-1.4c-1.6-0.6-2.7-1.4-2.7-2.9
c0-1.6,1.4-2.9,3.7-2.9c1.1,0,1.9,0.2,2.5,0.5l-0.5,1.8c-0.4-0.2-1.1-0.5-2-0.5s-1.4,0.4-1.4,0.9c0,0.6,0.5,0.9,1.8,1.4
c1.7,0.6,2.5,1.5,2.5,2.9c0,1.6-1.2,3-3.9,3c-1.1,0-2.2-0.3-2.7-0.6L259.3,165.6z"/>
<path class="st3" d="M266.9,157.7h2.2v4h0c0.2-0.3,0.5-0.5,0.9-0.7c0.3-0.2,0.7-0.3,1.1-0.3c1.4,0,2.5,1,2.5,3.1v4.1h-2.2V164
c0-0.9-0.3-1.5-1.1-1.5c-0.6,0-0.9,0.4-1.1,0.8c-0.1,0.1-0.1,0.3-0.1,0.5v4.2h-2.2V157.7z"/>
<path class="st3" d="M279.3,167.8l-0.1-0.7h0c-0.5,0.6-1.2,0.9-2,0.9c-1.4,0-2.3-1-2.3-2.2c0-1.8,1.6-2.7,4.1-2.7v-0.1
c0-0.4-0.2-0.9-1.3-0.9c-0.7,0-1.5,0.2-1.9,0.5l-0.4-1.4c0.5-0.3,1.4-0.6,2.7-0.6c2.3,0,3.1,1.4,3.1,3v2.4c0,0.7,0,1.3,0.1,1.7
H279.3z M279,164.5c-1.1,0-2,0.3-2,1.1c0,0.6,0.4,0.8,0.9,0.8c0.5,0,1-0.4,1.1-0.8c0-0.1,0-0.2,0-0.4V164.5z"/>
<path class="st3" d="M282.8,163.1c0-1,0-1.7-0.1-2.3h1.9l0.1,1.3h0.1c0.4-1,1.2-1.4,1.9-1.4c0.2,0,0.3,0,0.5,0v2.1
c-0.2,0-0.3-0.1-0.6-0.1c-0.8,0-1.3,0.4-1.5,1.1c0,0.1,0,0.3,0,0.5v3.6h-2.2V163.1z"/>
<path class="st3" d="M290.5,158.9c0,0.6-0.5,1.1-1.2,1.1c-0.7,0-1.1-0.5-1.1-1.1c0-0.6,0.4-1.1,1.1-1.1
C290.1,157.8,290.5,158.2,290.5,158.9z M288.3,167.8v-7h2.2v7H288.3z"/>
<path class="st3" d="M292.2,163.1c0-0.9,0-1.6-0.1-2.2h1.9l0.1,1h0c0.3-0.4,1-1.1,2.2-1.1c1.4,0,2.5,0.9,2.5,3v4.2h-2.2V164
c0-0.9-0.3-1.5-1.1-1.5c-0.6,0-1,0.4-1.1,0.8c-0.1,0.1-0.1,0.3-0.1,0.5v4h-2.2V163.1z"/>
<path class="st3" d="M307.3,160.8c0,0.4-0.1,1-0.1,2.1v3.9c0,1.3-0.3,2.5-1.1,3.2c-0.8,0.7-1.8,0.9-2.9,0.9c-0.9,0-1.9-0.2-2.5-0.5
l0.4-1.6c0.4,0.3,1.2,0.5,2,0.5c1,0,1.8-0.6,1.8-1.8v-0.5h0c-0.4,0.6-1.1,0.9-1.9,0.9c-1.7,0-3-1.4-3-3.4c0-2.3,1.5-3.7,3.2-3.7
c1,0,1.6,0.4,1.9,1h0l0.1-0.8H307.3z M305.1,163.7c0-0.1,0-0.3,0-0.4c-0.2-0.6-0.6-1-1.2-1c-0.8,0-1.4,0.7-1.4,2
c0,1,0.5,1.9,1.4,1.9c0.6,0,1-0.4,1.1-0.9c0.1-0.2,0.1-0.4,0.1-0.6V163.7z"/>
<path class="st3" d="M315.9,167.8l-0.1-0.7h0c-0.5,0.6-1.2,0.9-2,0.9c-1.4,0-2.3-1-2.3-2.2c0-1.8,1.6-2.7,4.1-2.7v-0.1
c0-0.4-0.2-0.9-1.3-0.9c-0.7,0-1.5,0.2-1.9,0.5l-0.4-1.4c0.5-0.3,1.4-0.6,2.7-0.6c2.3,0,3.1,1.4,3.1,3v2.4c0,0.7,0,1.3,0.1,1.7
H315.9z M315.6,164.5c-1.1,0-2,0.3-2,1.1c0,0.6,0.4,0.8,0.9,0.8c0.5,0,1-0.4,1.1-0.8c0-0.1,0-0.2,0-0.4V164.5z"/>
<path class="st3" d="M319.5,163.1c0-0.9,0-1.6-0.1-2.2h1.9l0.1,1h0c0.3-0.4,1-1.1,2.2-1.1c1.4,0,2.5,0.9,2.5,3v4.2H324V164
c0-0.9-0.3-1.5-1.1-1.5c-0.6,0-1,0.4-1.1,0.8c-0.1,0.1-0.1,0.3-0.1,0.5v4h-2.2V163.1z"/>
<path class="st3" d="M334.7,157.7v8.1c0,0.8,0,1.6,0.1,2.1h-1.9l-0.1-1h0c-0.4,0.8-1.3,1.2-2.2,1.2c-1.7,0-3-1.4-3-3.6
c0-2.4,1.5-3.7,3.1-3.7c0.9,0,1.5,0.3,1.8,0.8h0v-3.8H334.7z M332.5,163.8c0-0.1,0-0.3,0-0.4c-0.1-0.6-0.6-1.1-1.3-1.1
c-1,0-1.5,0.9-1.5,2c0,1.2,0.6,1.9,1.5,1.9c0.6,0,1.1-0.4,1.3-1c0-0.2,0.1-0.3,0.1-0.5V163.8z"/>
<path class="st3" d="M341.7,165.4l-0.7,2.5h-2.3l3-9.7h2.9l3,9.7h-2.4l-0.7-2.5H341.7z M344.1,163.7l-0.6-2.1
c-0.2-0.6-0.3-1.3-0.5-1.9h0c-0.1,0.6-0.3,1.3-0.4,1.9l-0.6,2.1H344.1z"/>
<path class="st3" d="M348.7,163.1c0-0.9,0-1.6-0.1-2.2h1.9l0.1,1h0c0.3-0.4,1-1.1,2.2-1.1c1.4,0,2.5,0.9,2.5,3v4.2h-2.2V164
c0-0.9-0.3-1.5-1.1-1.5c-0.6,0-1,0.4-1.1,0.8c-0.1,0.1-0.1,0.3-0.1,0.5v4h-2.2V163.1z"/>
<path class="st3" d="M361.1,167.8l-0.1-0.7h0c-0.5,0.6-1.2,0.9-2,0.9c-1.4,0-2.3-1-2.3-2.2c0-1.8,1.6-2.7,4.1-2.7v-0.1
c0-0.4-0.2-0.9-1.3-0.9c-0.7,0-1.5,0.2-1.9,0.5l-0.4-1.4c0.5-0.3,1.4-0.6,2.7-0.6c2.3,0,3.1,1.4,3.1,3v2.4c0,0.7,0,1.3,0.1,1.7
H361.1z M360.8,164.5c-1.1,0-2,0.3-2,1.1c0,0.6,0.4,0.8,0.9,0.8c0.5,0,1-0.4,1.1-0.8c0-0.1,0-0.2,0-0.4V164.5z"/>
<path class="st3" d="M364.6,157.7h2.2v10.2h-2.2V157.7z"/>
<path class="st3" d="M370.2,160.8l1,3.4c0.1,0.4,0.3,0.9,0.3,1.3h0c0.1-0.4,0.2-0.9,0.3-1.3l0.9-3.4h2.3l-1.6,4.6
c-1,2.8-1.7,3.9-2.5,4.6c-0.8,0.7-1.6,0.9-2.1,1l-0.5-1.8c0.3,0,0.6-0.2,0.9-0.4c0.3-0.2,0.7-0.5,0.9-0.9c0.1-0.1,0.1-0.2,0.1-0.3
c0-0.1,0-0.2-0.1-0.4l-2.6-6.4H370.2z"/>
<path class="st3" d="M375.9,165.9c0.4,0.2,1.2,0.5,1.9,0.5c0.7,0,0.9-0.2,0.9-0.6c0-0.4-0.2-0.5-1-0.8c-1.4-0.5-2-1.3-2-2.1
c0-1.3,1.1-2.3,2.9-2.3c0.8,0,1.5,0.2,2,0.4l-0.4,1.5c-0.3-0.2-0.9-0.4-1.5-0.4c-0.5,0-0.8,0.2-0.8,0.6c0,0.3,0.3,0.5,1.1,0.8
c1.3,0.5,1.9,1.1,1.9,2.2c0,1.3-1,2.3-3,2.3c-0.9,0-1.7-0.2-2.3-0.5L375.9,165.9z"/>
<path class="st3" d="M384.3,158.9c0,0.6-0.5,1.1-1.2,1.1c-0.7,0-1.1-0.5-1.1-1.1c0-0.6,0.4-1.1,1.1-1.1
C383.9,157.8,384.3,158.2,384.3,158.9z M382.1,167.8v-7h2.2v7H382.1z"/>
<path class="st3" d="M386,165.9c0.4,0.2,1.2,0.5,1.9,0.5c0.7,0,0.9-0.2,0.9-0.6c0-0.4-0.2-0.5-1-0.8c-1.4-0.5-2-1.3-2-2.1
c0-1.3,1.1-2.3,2.9-2.3c0.8,0,1.5,0.2,2,0.4l-0.4,1.5c-0.3-0.2-0.9-0.4-1.5-0.4c-0.5,0-0.8,0.2-0.8,0.6c0,0.3,0.3,0.5,1.1,0.8
c1.3,0.5,1.9,1.1,1.9,2.2c0,1.3-1,2.3-3,2.3c-0.9,0-1.7-0.2-2.3-0.5L386,165.9z"/>
</g>
</svg>

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.