MISP
/
misp-website
mirror of https://github.com/MISP/misp-website
2
0
Fork 0
Code Issues Releases Wiki Activity

update: GDPR document updated to the latest version

pull/3/head
Alexandre Dulaunoy 2018-01-30 08:49:00 +01:00
parent 3e0d7dc3e0
commit e7149ebf66
No known key found for this signature in database
GPG Key ID: 09E2CD4944E6CBCD
1 changed files with 9 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
compliance/gdpr/information_sharing_and_cooperation_gdpr.md
View File

@ -5,6 +5,8 @@ title: Information sharing and cooperation enabled by GDPR
# Information sharing and cooperation enabled by GDPR
Version: 1.1 - Tuesday, 30 January 2017
## 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.
@ -59,7 +61,7 @@ It is particularly important to note that **IP addresses can be considered as pe
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**.
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.
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 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 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.
@ -92,6 +94,8 @@ A processing activity should comply with the six principles in Art. 5, which cou
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, in most cases personal data has 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 publically 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).
The **retention period** might be very different depending on the use-case of a sharing community. The GDPR states that personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed". In the case of MISP, as seen in the precedent chapter, personal data are in some cases already pseudonymised. Moreover, "personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes". MISP use cases also include research on threat actors and attacks and may need to keep data for long retention periods, longer after the last occurrence of specific attacks, in order for example to discover attack patterns and produce statistics.
@ -99,7 +103,7 @@ 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).
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).
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.
@ -109,7 +113,7 @@ In addition, Recital 49 explicitly refers to CSIRTs’ right to process personal
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.
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".
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, 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 [..].”
<p align="center">
<img src="./misp-compliance-gdpr-grounds.svg" alt="GDPR grounds to process personal data" style="width: 70%;"/>
@ -132,7 +136,7 @@ The GDPR provides a new data protection framework that will allow information sh
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](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