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

chg: [compliance] migration of compliance documents

pull/56/head
Christophe Vandeplas 2022-01-08 16:47:02 +01:00
parent 83cff0b7cc
commit ea78b7b8d9
10 changed files with 116 additions and 519 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
compliance/gdpr/index.md → content/compliance/GDPR.md
View File

@ -23,9 +23,9 @@ The GDPR clarifies the differences in the roles and responsibilities of data con
The concept of data controller and data processor in a sharing environment is not always trivial, but can be summarized in the below diagram.
<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%;"/>
{{<figure src="/img/compliance/misp-compliance-gdpr-peer-to-peer-pa.svg" class="img-responsive" title="FIGURE 1: PROCESSING ACTIVITIES AND DATA CONTROLLER IN THE GENERAL CASE OF INFORMATION SHARING" >}}
*FIGURE 1: PROCESSING ACTIVITIES AND DATA CONTROLLER IN THE GENERAL CASE OF INFORMATION SHARING*
* **Step 1** Entity A creates or collects a piece of information, “data 1”, as part of the processing activity “Collect and store information”. There is no data processor or recipient.
* **Step 2** Entity A shares “data 1” with entity B. In this case entity A is the data controller and entity B is a recipient, but not a data processor. Entity A holds the responsibility of selecting the entity to share with and ensuring a secure data transfer to entity B.
@ -36,9 +36,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%;"/>
*FIGURE 2: PROCESSING ACTIVITIES AND DATA CONTROLLER IN THE SPECIFIC CASE OF SHARING INFORMATION WITH MISP PLATFORM*
{{<figure src="/img/compliance/misp-compliance-gdpr-misp-pa.svg" class="img-responsive" title="FIGURE 2: PROCESSING ACTIVITIES AND DATA CONTROLLER IN THE SPECIFIC CASE OF SHARING INFORMATION WITH MISP PLATFORM">}}
* **Step 1** A MISP event “e1” is created by entity A. Entity A is the data controller, there is no data processor or recipient.
* **Step 2** The event is shared as “community only” to the remote organisation in the local instance of MISP at entity A (Org B and C). In this case entity A is the data controller of the activity “Share information”.
@ -66,11 +64,7 @@ This statement should however be balanced, as specific attributes can sometimes
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>
*FIGURE 3: EXAMPLE OF MISP ATTRIBUTE CATEGORIES POTENTIALLY INVOLVING PERSONAL DATA (NON-EXHAUSTIVE)*
{{<figure src="/img/compliance/misp-compliance-gdpr-personal-data.svg" class="img-responsive" title="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.
@ -115,11 +109,7 @@ However, in the light of the purpose limitation principle, CSIRTs do not have a
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%;"/>
</p>
*FIGURE 4: LEGAL GROUNDS WHICH CAN ENABLE A DATA CONTROLLER OR PROCESSOR TO PROCESS PERSONAL DATA*
{{<figure src="/img/compliance/misp-compliance-gdpr-grounds.svg" class="img-responsive" title="FIGURE 4: LEGAL GROUNDS WHICH CAN ENABLE A DATA CONTROLLER OR PROCESSOR TO PROCESS PERSONAL DATA">}}
## Conclusion
@ -142,7 +132,7 @@ The GDPR provides a new data protection framework that will allow information sh
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)
![](/img/cef.png)
## Contact and Collaboration

342
compliance/ISO-IEC-27010/index.md → content/compliance/ISO-IEC-27010.md
View File

@ -1,5 +1,4 @@
---
layout: page_notoc
title: MISP as supporting platform for sharing information, following ISO/IEC 27010:2015
---
@ -33,61 +32,23 @@ MISP is a free and open source platform for sharing, storing and correlating cyb
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.
<p align="center">
<img src="./images/misp-compliance-iso-concepts.svg" alt="image" style="width: 70%;"/><br/>
{{< figure src="/img/compliance/misp-compliance-iso-concepts.svg" title="FIGURE 1: Illustration of MISP organisations and community interactions" class="img-responsive">}}
<span><i>FIGURE 1: Illustration of MISP organisations and community interactions</i></span>
</p>
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.
<table style="width:100%">
<tr>
<th>ISO/IEC 27010:2015 key concepts</th>
<th>MISP data model representing the concepts</th>
<th>Related definition in <a href="https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en"> ISO/IEC 27000:2018</a></th>
</tr>
<tr>
<td><b>Information sharing community</b></td>
<td>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 <b>MISP community</b> includes all organisations on a MISP server and organisations running MISP servers that synchronise with this server.</td>
<td>3.34 information sharing community</td>
</tr>
<tr>
<td><b>Organization</b></td>
<td>A <b>MISP organization</b> represent an organisation in the community.</td>
<td>3.50 organization</td>
</tr>
<tr>
<td><b>Member of an organisation</b></td>
<td><b>MISP users</b> represent organisation members.</td>
<td>Not covered in the standard.</td>
</tr>
<tr>
<td><b>Information exchange types (e.g. "alerts and warnings" and "incident handling")</b></td>
<td><b>MISP events</b> 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 <b>MISP attributes</b>, usually representing indicators of compromise (e.g. IP addresses, domain names etc.). Attributes are defined structure that have a limited set of <a href="http://www.misp-project.org/datamodels/#misp-core-format"> type and categories</a>. Attributes can be aggregated into MISP objects.</td>
<td>3.21 event</td>
</tr>
<tr>
<td><b>Supporting entities</b></td>
<td>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)</td>
<td>3.76 trusted information communication entity</td>
</tr>
<tr>
<td><b>Source</b></td>
<td>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.</td>
<td>Not covered in the standard.</td>
</tr>
<tr>
<td><b>Originator</b></td>
<td>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). </td>
<td>Not covered in the standard.</td>
</tr>
<tr>
<td><b>Recipient</b></td>
<td>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 <a href="https://github.com/MISP/misp-book/tree/master/using-the-system"> five sharing models </a> allowing, for example, to only share an event with one organisation, one community or a couple of chosen organisations in a community.</td>
<td>Not covered in the standard.</td>
</tr>
</table>
| ISO/IEC 27010:2015 key concepts | MISP data model representing the concepts | Related definition in [ISO/IEC 27000:2018](https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en) |
| --- | --- | --- |
| **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](/datamodels/#misp-core-format). 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](https://github.com/MISP/misp-book/tree/master/using-the-system) 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
@ -104,149 +65,43 @@ ISO/IEC 27010:2015 complements ISO/IEC 27001:2005 by providing additional or aug
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.
<table style="width:100%">
<tr>
<th>New controls of controls augmented by ISO/IEC 27010:2015</th>
<th>Applicable to MISP</th>
<th>References to relevant MISP features</th>
</tr>
<tr>
<td>5.1.1 Policies for information security</td>
<td>Partially</td>
<td><a href="#(5)">(5) Information security policies</a></td>
</tr>
<tr>
<td>5.1.2 Review of the policies for information security</td>
<td>No</td>
<td>N/A</td>
</tr>
<tr>
<td>7.1.1 Screening</td>
<td>No</td>
<td>N/A</td>
</tr>
<tr>
<td>8.1.3 Acceptable use of assets</td>
<td>Partially</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>8.2.1 Classification of information</td>
<td>Yes</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>8.4.1 Information dissemination</td>
<td>Yes</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>8.4.2 Information disclaimers</td>
<td>Yes</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>8.4.3 Information credibility</td>
<td>Yes</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>8.4.4 Information sensitivity reduction</td>
<td>Yes</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>8.4.5 Anonymous source protection</td>
<td>Yes</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>8.4.6 Anonymous recipient protection</td>
<td>Yes</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>8.4.7 Onwards release authority</td>
<td>Yes</td>
<td><a href="#(8)">(8) Asset management</a></td>
</tr>
<tr>
<td>10.1.1 Policy on the use of cryptographic controls</td>
<td>Yes</td>
<td><a href="#(10)">(10) Cryptography</a></td>
</tr>
<tr>
<td>12.2.1 Controls against malware</td>
<td>No</td>
<td>N/A</td>
</tr>
<tr>
<td>12.4.1 Event logging</td>
<td>Yes</td>
<td><a href="#(12)">(12) Operations security</a></td>
</tr>
<tr>
<td>12.7.2 Community audit rights</td>
<td>No</td>
<td>N/A</td>
</tr>
<tr>
<td>13.2.2 Agreements on information transfer</td>
<td>Partially</td>
<td><a href="#(13)">(13) Information transfer</a></td>
</tr>
<tr>
<td>13.2.3 Electronic messaging</td>
<td>Yes</td>
<td><a href="#suitable-data-model">Alternative methods to electronic messaging are part of the MISP synchronisation protocol (e.g. air-gap exchange protocol)</a></td>
</tr>
<tr>
<td>15.1.2 Addressing security within supplier agreements</td>
<td>No</td>
<td>N/A</td>
</tr>
<tr>
<td>16.1.2 Reporting information security events</td>
<td>Partially</td>
<td><a href="#(16)">(16) Information security incident management</a></td>
</tr>
<tr>
<td>16.1.6 Learning from information security incidents</td>
<td>Yes</td>
<td><a href="#(16)">(16) Information security incident management</a></td>
</tr>
<tr>
<td>16.1.8 Early warning system</td>
<td>Yes</td>
<td><a href="#(16)">(16) Information security incident management</a></td>
</tr>
<tr>
<td>17.1.1 Planning information security continuity</td>
<td>No</td>
<td>N/A</td>
</tr>
<tr>
<td>18.1.1 Identification of applicable legislation and contractual requirements</td>
<td>Partially</td>
<td><a href="#(18)">(18) Compliance</a></td>
</tr>
<tr>
<td>18.1.6 Liability to the information sharing community</td>
<td>No</td>
<td>N/A</td>
</tr>
</table>
| 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-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-asset-management) |
| 8.2.1 Classification of information | Yes | [(8) Asset management](#8-asset-management) |
| 8.4.1 Information dissemination | Yes | [(8) Asset management](#8-asset-management) |
| 8.4.2 Information disclaimers | Yes | [(8) Asset management](#8-asset-management) |
| 8.4.3 Information credibility | Yes | [(8) Asset management](#8-asset-management) |
| 8.4.4 Information sensitivity reduction | Yes | [(8) Asset management](#8-asset-management) |
| 8.4.5 Anonymous source protection | Yes | [(8) Asset management](#8-asset-management) |
| 8.4.6 Anonymous recipient protection | Yes | [(8) Asset management](#8-asset-management) |
| 8.4.7 Onwards release authority | Yes | [(8) Asset management](#8-asset-management) |
| 10.1.1 Policy on the use of cryptographic controls | Yes | [(10) Cryptography](#10-cryptography) |
| 12.2.1 Controls against malware | Yes | [(12) Operations security](#12-operations-security) |
| 12.4.1 Event logging | Yes | [(12) Operations security](#12-operations-security) |
| 12.7.2 Community audit rights | No | N/A |
| 13.2.2 Agreements on information transfer | Partially | [(13) Information transfer](#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)](#suitable-data-model) |
| 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-information-security-incident-management) |
| 16.1.6 Learning from information security incidents | Yes | [(16) Information security incident management](#16-information-security-incident-management) |
| 16.1.8 Early warning system | Yes | [(16) Information security incident management](#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-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
### (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
### (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.
@ -254,117 +109,44 @@ The standard suggests that information should be classified in terms of legal re
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:
<table style="width:100%">
<tr>
<th>ISO/IEC 27010:2015 classification requirements</th>
<th>Examples of taxonomies and/or features integrated in MISP (non-exhaustive)</th>
</tr>
<tr>
<td><b>Legal requirements</b> (8.2.1)</td>
<td>
<ul>
<li>No taxonomies are yet integrated. It is however possible to add custom taxonomy in MISP.</li>
</ul>
</td>
</tr>
<tr>
<td><b>Value</b> (8.2.1)</td>
<td>
<ul>
<li>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, <a href="https://www.misp-project.org/taxonomies.html#_circl">incident classification or topic taxonomies</a>.</li>
<li>Value of the information can also be determined by the <a href="https://www.misp-project.org/taxonomies.html#_cssa"> CSSA agreed sharing taxonomy</a>, for example, the 'sharing-class' indicates whether the shared information has been validated by a human prior to sharing.</li>
</ul>
</td>
</tr>
<tr>
<td><b>Credibility</b> (8.2.1) and (8.4.3)</td>
<td>
<ul>
<li>The <a href="https://www.misp-project.org/taxonomies.html#_admiralty_scale">Admiralty Scale taxonomy</a> can be used to measure the credibility of an event.</li>
<li><a href="https://www.misp-project.org/taxonomies.html#_analyst_assessment"> The analyst experience taxonomy</a> can be used to assess the credibility of an analysis of an event.</li>
<li>The <a href="https://www.misp-project.org/taxonomies.html#_estimative_language">likelihood-probability</a> taxonomy can also be used to measure the credibility of an event.</li>
<li><a href="http://www.misp-project.org/features.html">The correlation feature and sightings</a> can also help assessing the credibility of an event.</li>
<li><a href="https://www.circl.lu/doc/misp/administration/#whitelisting-an-address">Whitelist</a> and <a href="https://github.com/MISP/misp-warninglists">Warning lists</a> improve false positive detection</li>
</ul>
</td>
</tr>
<tr>
<td><b>Priority</b> (8.2.1)</td>
<td>
<ul>
<li>MISP integrates <a href="https://www.misp-project.org/taxonomies.html#_priority_level">six levels of priority aligned with NCCIC, DHS, and the CISS</a>.</li>
</ul>
</td>
</tr>
<tr>
<td><b>Criticality</b> (8.2.1)</td>
<td>
<ul>
<li><a href="https://www.circl.lu/doc/misp/create-event-report/">"Threat Level" of a MISP event</a> indicates the level of criticality.</li>
</ul>
</td>
</tr>
<tr>
<td><b>Sensitivity</b> (8.2.1)</td>
<td>
<ul>
<li><a href="https://www.misp-project.org/taxonomies.html#_nato">NATO classification</a>.</li>
</ul>
</td>
</tr>
<tr>
<td><b>Dissemination markings</b> (8.4.1)</td>
<td>
<ul>
<li><a href="https://www.misp-project.org/taxonomies.html#_tlp">Traffic Light Protocol (TLP) taxonomy</a>.</li>
<li>Different level of <a href="https://github.com/MISP/misp-book/tree/master/using-the-system">sharing model</a> can be used, restricting the propagation of events.</li>
</ul>
</td>
</tr>
<tr>
<td><b>Information disclaimer</b> (8.4.2)</td>
<td>
<ul>
<li>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.</li>
<li>In MISP it is possible to <a href="https://www.circl.lu/doc/misp/sharing/#contact-a-reporter">contact the reporter</a> of an event to ask for clarification.</li>
<li>For each event, an <a href="https://www.circl.lu/doc/misp/using-the-system/#general-event-information">'Event Discussion Thread'</a> can also be used to ask for clarification.</li>
</ul>
</td>
</tr>
<tr>
<td><b>Sensitivity reduction</b> (8.4.4)</td>
<td>
<ul>
<li>In MISP, there is no taxonomy or specific field in the data model regarding sensitivity reduction. However, at any point in time, the originator of the event can change the TLP or the sharing model of an event for example.</li>
</ul>
</td>
</tr>
</table>
| 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](/taxonomies.html#_circl).<br>* Value of the information can also be determined by the [CSSA agreed sharing taxonomy](/taxonomies.html#_cssa), 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](/taxonomies.html#_admiralty_scale) can be used to measure the credibility of an event.<br>* [The analyst experience taxonomy](/taxonomies.html#_analyst_assessment) can be used to assess the credibility of an analysis of an event.<br>* The [likelihood-probability](/taxonomies.html#_estimative_language) taxonomy can also be used to measure the credibility of an event.<br>* [The correlation feature and sightings](http://www.misp-project.org/features.html) can also help assessing the credibility of an event.<br>* [Whitelist](https://www.circl.lu/doc/misp/administration/#whitelisting-an-address) and [Warning lists](https://github.com/MISP/misp-warninglists) improve false positive detection |
| **Priority** (8.2.1) | * MISP integrates [six levels of priority aligned with NCCIC, DHS, and the CISS](/taxonomies.html#_priority_level). |
| **Criticality** (8.2.1) | * ["Threat Level" of a MISP event](https://www.circl.lu/doc/misp/create-event-report/) indicates the level of criticality. |
| **Sensitivity** (8.2.1) | * [NATO classification](/taxonomies.html#_nato). |
| **Dissemination markings** (8.4.1) | * [Traffic Light Protocol (TLP) taxonomy](/taxonomies.html#_tlp).<br>* Different level of [sharing model](https://github.com/MISP/misp-book/tree/master/using-the-system) 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.<br>* In MISP it is possible to [contact the reporter](https://www.circl.lu/doc/misp/sharing/#contact-a-reporter) of an event to ask for clarification.<br>* For each event, an ['Event Discussion Thread'](https://www.circl.lu/doc/misp/using-the-system/#general-event-information) can also be used to ask for clarification. |
| **Sensitivity reduction** (8.4.4) | * In MISP, there is no taxonomy or specific field in the data model regarding sensitivity reduction. However, at any point in time, the originator of the event can change the TLP or the sharing model of an event for example. |
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
### (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
### (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
The `attachment_scan_module` configuration parameter allows automatic anti-virus scanning of uploaded files.
### (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
### (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
### (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").
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](/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
@ -381,7 +163,7 @@ As demonstrated in this article, MISP is a flexible platform that thanks to an e
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)
![](/img/cef.png)
## Contact and Collaboration

269
compliance/NISD/index.md → content/compliance/NISD.md
View File

@ -1,5 +1,4 @@
---
layout: page_notoc
title: How MISP enables stakeholders identified by the NISD to perform key activities
---
@ -14,96 +13,18 @@ The [Malware Information Sharing and Threat Intelligence Sharing Platform (MISP)
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>
| 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
@ -135,7 +56,7 @@ Addressing cross-border incidents can be here interpreted as cross-border incide
### 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.
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](/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).
@ -156,84 +77,25 @@ While performing activities in the above mentioned four areas, CSIRTs can use MI
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>
| 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:
In MISP it is possible to indicate what EU Member States are affected for each event representing an incident thanks to the [veris country](/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](/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>
1. the number of users affected by the disruption of the essential service;
2. the duration of the incident;
3. 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.
@ -285,40 +147,11 @@ OESs and DSPs should take appropriate and proportionate technical and organisati
### 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>
| 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.
@ -326,10 +159,8 @@ Additionally to security requirements, OESs and DSPs have specific incident noti
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>
4. the extent of the disruption of the functioning of the service;
5. the extent of the impact on economic and societal activities.
However, these criteria for the moment are not directly supported by MISP.
@ -337,7 +168,7 @@ As a concrete example of how OESs and DSPs could use MISP as a notification mech
### 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.
OESs can notify that they rely on a DSPs thanks to the [eu-nis-sector-and-subsectors](/taxonomies.html#_eu_nis_sector_and_subsectors) taxonomy and the [eu-market-and-public-admin](/taxonomies.html#_eu_marketop_and_publicadmin) taxonomy.
## Conclusion
@ -347,7 +178,7 @@ MISP can support CSIRTs participating in the CSIRTs network mainly with the task
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)
![](/assets/images/cef.png)
## Contact and Collaboration
@ -357,23 +188,15 @@ If you have any question or suggestion about this topic, feel free to [contact u
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>
{{<figure src="/img/compliance/misp-nisd-notification.svg" title="FIGURE 1: Examples of notification configuration" class="img-responsive" >}}
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
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 maincident having a significant impact. OESs or DSPs have several possibilities to report the MISP event representing the NIS incident:
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>
1. 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.
2. Use the NCA MISP instance to create a MISP event representing the incident.
3. 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.
@ -386,10 +209,8 @@ If the incident is sensitive, OESs or DSPs would most likely use a restrictive s
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>
1. 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)).
2. 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.
@ -400,4 +221,8 @@ If the incident was communicated to the NCA by the OES or DSP by other means tha
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.
* Change the Distribution setting of the event to another sharing group. steps of incident notification depicted in the above figure.
### Step 1
The OES or DSP notifies the NCAs in case of an in

2
content/compliance.md → content/compliance/index.md
View File

@ -13,7 +13,7 @@ As the MISP project is used in different geographical regions (Europe, North Ame
## GDPR - General Data Protection Regulation
- [Information sharing and cooperation enabled by GDPR](/compliance/gdpr/information_sharing_and_cooperation_gdpr.html) latest version 1.1 published on Tuesday, 30 January 2018. [PDF](/compliance/gdpr/information_sharing_and_cooperation_gdpr.pdf)
- [Information sharing and cooperation enabled by GDPR](/compliance/GDPR/) latest version 1.1 published on Tuesday, 30 January 2018. [PDF](/img/compliance/information_sharing_and_cooperation_gdpr.pdf)
## ISO/IEC 27010:2015 - Information security management for inter-sector and inter-organizational communications

0
compliance/gdpr/misp-compliance-gdpr-grounds.svg → static/img/compliance/misp-compliance-gdpr-grounds.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

0
compliance/gdpr/misp-compliance-gdpr-misp-pa.svg → static/img/compliance/misp-compliance-gdpr-misp-pa.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 122 KiB

After

Width:  |  Height:  |  Size: 122 KiB

0
compliance/gdpr/misp-compliance-gdpr-peer-to-peer-pa.svg → static/img/compliance/misp-compliance-gdpr-peer-to-peer-pa.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 63 KiB

After

Width:  |  Height:  |  Size: 63 KiB

0
compliance/gdpr/misp-compliance-gdpr-personal-data.svg → static/img/compliance/misp-compliance-gdpr-personal-data.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 36 KiB

0
compliance/ISO-IEC-27010/images/misp-compliance-iso-concepts.svg → static/img/compliance/misp-compliance-iso-concepts.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 96 KiB

After

Width:  |  Height:  |  Size: 96 KiB

0
compliance/NISD/images/misp-nisd-notification.svg → static/img/compliance/misp-nisd-notification.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 79 KiB

After

Width:  |  Height:  |  Size: 79 KiB