Merge pull request #13 from circlsupportuser/master
Initial commit of the NISD article and re-factoring of the GDPR articlepull/15/head
GitHub
commit
d5c59a6397
|
|
@ -3,19 +3,19 @@
|
|||
|
||||
## 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](https://www.circl.lu/) 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%;"/>
|
||||
|
||||
|
|
@ -47,18 +47,14 @@ 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**.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
<p align="center">
|
||||
<img src="./misp-compliance-gdpr-personal-data.svg" alt="GDPR information sharing personal data in MISP per categories" style="width: 70%;"/>
|
||||
|
|
@ -66,29 +62,19 @@ The figure below illustrates the MISP categories of data that could be exchanged
|
|||
|
||||
*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, 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).
|
||||
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).
|
||||
|
||||
|
|
@ -97,27 +83,59 @@ 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.
|
||||
|
||||
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.
|
||||
|
||||
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, 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 [..].”
|
||||
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”.
|
||||
|
||||
<p align="center">
|
||||
<img src="./misp-compliance-gdpr-grounds.svg" alt="GDPR grounds to process personal data" style="width: 70%;"/>
|
||||
</p>
|
||||
|
||||
*FIGURE 4: LEGAL GROUNDS WHICH CAN ENABLE A DATA CONTROLLER OR PROCESSOR TO PROCESS PERSONAL DATA*
|
||||
*FIGURE 4: LEGAL GROUNDS FOR CSIRTs WHICH CAN ENABLE A DATA CONTROLLER OR PROCESSOR TO PROCESS PERSONAL DATA*
|
||||
|
||||
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.
|
||||
|
||||
#### Art. 6(1)(a) - Consent
|
||||
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,398 @@
|
|||
# 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.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
CSIRTs network task as described in Article 12 of the NISD
|
||||
</th>
|
||||
<th>
|
||||
Can MISP support?
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(a) exchanging information on CSIRTs' services, operations and cooperation capabilities;
|
||||
</td>
|
||||
<td>
|
||||
Not applicable
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(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
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(c) exchanging and making available on a voluntary basis non-confidential information concerning individual incidents;
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(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;
|
||||
</td>
|
||||
<td>
|
||||
Not applicable
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(e) providing Member States with support in addressing cross-border incidents on the basis of their voluntary mutual assistance;
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(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;
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(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;
|
||||
</td>
|
||||
<td>
|
||||
Not applicable
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(h) discussing lessons learnt from exercises relating to the security of network and information systems, including from those organised by ENISA;
|
||||
</td>
|
||||
<td>
|
||||
Not applicable
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(i) at the request of an individual CSIRT, discussing the capabilities and preparedness of that CSIRT;
|
||||
</td>
|
||||
<td>
|
||||
Not applicable
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(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.
|
||||
</td>
|
||||
<td>
|
||||
Not applicable
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### 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 let’s 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 attacker’s 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 attacker’s 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.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
CSIRTs network task from Annex I (2)
|
||||
</th>
|
||||
<th>
|
||||
Supported by MISP?
|
||||
<th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(a) (i) monitoring incidents at a national level;
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
<td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(a) (ii) providing early warning, alerts, announcements and dissemination of information to relevant stakeholders about risks and incidents;
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
<td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(a) (iii) responding to incidents;
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
<td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(a) (iv) providing dynamic risk and incident analysis and situational awareness;
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
<td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(a) (v) participating in the CSIRTs network.
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
<td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(b) CSIRTs shall establish cooperation relationships with the private sector.
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
<td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
(c) promote the adoption and use of common or standardised practices for incident and risk-handling procedures; incident, risk and information classification schemes.
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
<td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### (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:
|
||||
|
||||
<ol type="a">
|
||||
<li>the number of users affected by the disruption of the essential service;</li>
|
||||
<li>the duration of the incident;</li>
|
||||
<li>the geographical spread with regard to the area affected by the incident.</li>
|
||||
</ol>
|
||||
|
||||
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
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
CSIRTs network task from Annex I (2)
|
||||
</th>
|
||||
<th>
|
||||
Supported by MISP?
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
Notify any incident having a “significant” or “substantial” impact to the NCA or to the CSIRT without undue delay.
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
</td>
|
||||
<tr>
|
||||
<tr>
|
||||
<td>
|
||||
Notify impact of incident if OESs relies on a third-party DSP.
|
||||
</td>
|
||||
<td>
|
||||
<b>Yes</b>
|
||||
</td>
|
||||
<tr>
|
||||
<tr>
|
||||
<td>
|
||||
Inform the public about individual incidents if required by the notified competent authority or CSIRT.
|
||||
</td>
|
||||
<td>
|
||||
Not applicable
|
||||
</td>
|
||||
<tr>
|
||||
</table>
|
||||
|
||||
### 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:
|
||||
|
||||
<ol type="a" start="4">
|
||||
<li>the extent of the disruption of the functioning of the service;</li>
|
||||
<li>the extent of the impact on economic and societal activities.</li>
|
||||
</ol>
|
||||
|
||||
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***.
|
||||
|
||||
|
||||
|
||||
## 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).
|
||||
|
||||
<p align="center">
|
||||
<img src="./images/misp-nisd-notification.svg" alt="image" style="width: 100%;"/><br/>
|
||||
|
||||
<span><i>FIGURE 1: Examples of notification configuration</i></span>
|
||||
</p>
|
||||
|
||||
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:
|
||||
|
||||
<ol type="a">
|
||||
<li>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.</li>
|
||||
<li>Use the NCA MISP instance to create a MISP event representing the incident.</li>
|
||||
<li>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.</li>
|
||||
</ol>
|
||||
|
||||
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:
|
||||
|
||||
<ol type="a">
|
||||
<li>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)).</li>
|
||||
<li>The national CSIRT(s).</li>
|
||||
</ol>
|
||||
|
||||
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 |
Loading…
Reference in New Issue