-
- | ISO/IEC 27010:2015 key concepts |
- MISP data model representing the concepts |
- Related definition in ISO/IEC 27000:2018 |
-
-
- | Information sharing community |
- The concept of community is closely related to the concept of MISP server (also called MISP instance). A MISP server is a specific instance of the MISP software, running on a computer, usually a server. A MISP server can include multiple organisations. A MISP community includes all organisations on a MISP server and organisations running MISP servers that synchronise with this server. |
- 3.34 information sharing community |
-
-
- | Organization |
- A MISP organization represent an organisation in the community. |
- 3.50 organization |
-
-
- | Member of an organisation |
- MISP users represent organisation members. |
- Not covered in the standard. |
-
-
- | Information exchange types (e.g. "alerts and warnings" and "incident handling") |
- MISP events are the smallest unit that can be shared in MISP. Events can be enrich with "tags", such as tags integrates external and broadly used protocols and standards such as TLD (Traffic Lights Protocol) and MISP galaxies which enable a deeper analysis and categorisation of events. Events are composed of MISP attributes, usually representing indicators of compromise (e.g. IP addresses, domain names etc.). Attributes are defined structure that have a limited set of type and categories. Attributes can be aggregated into MISP objects. |
- 3.21 event |
-
-
- | Supporting entities |
- The centralized supporting entity in a MISP community can be interpreted as being the entity (or organisation) operating the MISP instance (also called MISP server). The entity operating the MISP instance decides who will join the community and can attribute rights to organisation on the MISP instance (e.g. right to synchronise a MISP server) |
- 3.76 trusted information communication entity |
-
-
- | Source |
- In MISP, the source of the event is indicated in the event detail in the field "Orgc". The source of an event stay the same even if the event is transferred to other communities. |
- Not covered in the standard. |
-
-
- | Originator |
- In MISP, the originator of an event is indicated in the event detail in the field "Org". If the source is in the same MISP community than a recipient, the source (Orgc) and the originator (Org) of an event will be the same for this recipient. If the source of an event (Orgc) is not in the same community than a recipient (e.g. the event has been pushed to another MISP community because its sharing model is "All communities" or "Connected communities"), then the source (Orgc) and the originator will differ. In that case, the originator (Org) would appear as the organisation synchronising the MISP instances (for an illustration, refer to event e' in the "FIGURE 1" above). |
- Not covered in the standard. |
-
-
- | Recipient |
- In MISP, the recipients of an event depends on the sharing model the originator choose for the event. MISP sharing model is flexible and include five sharing models allowing, for example, to only share an event with one organisation, one community or a couple of chosen organisations in a community. |
- Not covered in the standard. |
-
-
+|ISO/IEC 27010:2015 key concepts|MISP data model representing the concepts|Related definition in ISO/IEC 27000:2018|
+|--- |--- |--- |
+|Information sharing community|The concept of community is closely related to the concept of MISP server (also called MISP instance). A MISP server is a specific instance of the MISP software, running on a computer, usually a server. A MISP server can include multiple organisations. A MISP community includes all organisations on a MISP server and organisations running MISP servers that synchronise with this server.|3.34 information sharing community|
+|Organization|A MISP organization represent an organisation in the community.|3.50 organization|
+|Member of an organisation|MISP users represent organisation members.|Not covered in the standard.|
+|Information exchange types (e.g. "alerts and warnings" and "incident handling")|MISP events are the smallest unit that can be shared in MISP. Events can be enrich with "tags", such as tags integrates external and broadly used protocols and standards such as TLD (Traffic Lights Protocol) and MISP galaxies which enable a deeper analysis and categorisation of events. Events are composed of MISP attributes, usually representing indicators of compromise (e.g. IP addresses, domain names etc.). Attributes are defined structure that have a limited set of type and categories. Attributes can be aggregated into MISP objects.|3.21 event|
+|Supporting entities|The centralized supporting entity in a MISP community can be interpreted as being the entity (or organisation) operating the MISP instance (also called MISP server). The entity operating the MISP instance decides who will join the community and can attribute rights to organisation on the MISP instance (e.g. right to synchronise a MISP server)|3.76 trusted information communication entity|
+|Source|In MISP, the source of the event is indicated in the event detail in the field "Orgc". The source of an event stay the same even if the event is transferred to other communities.|Not covered in the standard.|
+|Originator|In MISP, the originator of an event is indicated in the event detail in the field "Org". If the source is in the same MISP community than a recipient, the source (Orgc) and the originator (Org) of an event will be the same for this recipient. If the source of an event (Orgc) is not in the same community than a recipient (e.g. the event has been pushed to another MISP community because its sharing model is "All communities" or "Connected communities"), then the source (Orgc) and the originator will differ. In that case, the originator (Org) would appear as the organisation synchronising the MISP instances (for an illustration, refer to event e' in the "FIGURE 1" above).|Not covered in the standard.|
+|Recipient|In MISP, the recipients of an event depends on the sharing model the originator choose for the event. MISP sharing model is flexible and include five sharing models allowing, for example, to only share an event with one organisation, one community or a couple of chosen organisations in a community.|Not covered in the standard.|
### Suitable flexibility and accessibility
@@ -99,139 +71,33 @@ 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.
-
-
+|New controls of controls augmented by ISO/IEC 27010:2015|Applicable to MISP|References to relevant MISP features|
+|--- |--- |--- |
+|5.1.1 Policies for information security|Partially|(5) Information security policies|
+|5.1.2 Review of the policies for information security|No|N/A|
+|7.1.1 Screening|No|N/A|
+|8.1.3 Acceptable use of assets|Partially|(8) Asset management|
+|8.2.1 Classification of information|Yes|(8) Asset management|
+|8.4.1 Information dissemination|Yes|(8) Asset management|
+|8.4.2 Information disclaimers|Yes|(8) Asset management|
+|8.4.3 Information credibility|Yes|(8) Asset management|
+|8.4.4 Information sensitivity reduction|Yes|(8) Asset management|
+|8.4.5 Anonymous source protection|Yes|(8) Asset management|
+|8.4.6 Anonymous recipient protection|Yes|(8) Asset management|
+|8.4.7 Onwards release authority|Yes|(8) Asset management|
+|10.1.1 Policy on the use of cryptographic controls|Yes|(10) Cryptography|
+|12.2.1 Controls against malware|No|N/A|
+|12.4.1 Event logging|Yes|(12) Operations security|
+|12.7.2 Community audit rights|No|N/A|
+|13.2.2 Agreements on information transfer|Partially|(13) Information transfer|
+|13.2.3 Electronic messaging|Yes|Alternative methods to electronic messaging are part of the MISP synchronisation protocol (e.g. air-gap exchange protocol)|
+|15.1.2 Addressing security within supplier agreements|No|N/A|
+|16.1.2 Reporting information security events|Partially|(16) Information security incident management|
+|16.1.6 Learning from information security incidents|Yes|(16) Information security incident management|
+|16.1.8 Early warning system|Yes|(16) Information security incident management|
+|17.1.1 Planning information security continuity|No|N/A|
+|18.1.1 Identification of applicable legislation and contractual requirements|Partially|(18) Compliance|
+|18.1.6 Liability to the information sharing community|No|N/A|
The below section highlights clarifications on which MISP features enables an easy implementation of ISO/IEC 27010:2015 controls applicable to MISP.
@@ -249,95 +115,20 @@ 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:
-
-
- | ISO/IEC 27010:2015 classification requirements |
- Examples of taxonomies and/or features integrated in MISP (non-exhaustive) |
-
-
- | Legal requirements (8.2.1) |
-
-
- - No taxonomies are yet integrated. It is however possible to add custom taxonomy in MISP.
-
- |
-
-
- | Value (8.2.1) |
-
-
- - In some cases, the value of threat intelligence depends on the quality of the classification. A wide range of classifications is available for an event in MISP, for example, incident classification or topic taxonomies.
- - Value of the information can also be determined by the CSSA agreed sharing taxonomy, for example, the 'sharing-class' indicates whether the shared information has been validated by a human prior to sharing.
-
- |
-
-
- | Credibility (8.2.1) and (8.4.3) |
-
-
- |
-
-
- | Priority (8.2.1) |
-
-
- |
-
-
- | Criticality (8.2.1) |
-
-
- |
-
-
- | Sensitivity (8.2.1) |
-
-
- |
-
-
- | Dissemination markings (8.4.1) |
-
-
- |
-
-
- | Information disclaimer (8.4.2) |
-
-
- - There is no specific field or free text available at the event level in MISP to add a custom disclaimer to list any special requirements to follow by the recipients in addition to the normal information marking. However, it is possible to add custom taxonomies in MISP. Moreover, as explained in the two following points, it is possible to contact the reporter or ask for clarification.
- - In MISP it is possible to contact the reporter of an event to ask for clarification.
- - For each event, an 'Event Discussion Thread' can also be used to ask for clarification.
-
- |
-
-
- | Sensitivity reduction (8.4.4) |
-
-
- - Sightings in MISP can be used to evaluate the value of an attribute over time. Especially sightings of type "Expiration" can be added to an attribute to indicate that the attribute has lost value (e.g. URLs which have been cleaned after some time).
- - The MISP infrastructure-state taxonomy can also indicate if the adversary infrastructure at the event or attribute level is still active or is down.
-
- |
-
-
+|ISO/IEC 27010:2015 classification requirements|Examples of taxonomies and/or features integrated in MISP (non-exhaustive)|
+|--- |--- |
+|Legal requirements (8.2.1)|No taxonomies are yet integrated. It is however possible to add custom taxonomy in MISP.|
+|Value (8.2.1)|In some cases, the value of threat intelligence depends on the quality of the classification. A wide range of classifications is available for an event in MISP, for example, incident classification or topic taxonomies.
+ Value of the information can also be determined by the CSSA agreed sharing taxonomy, for example, the 'sharing-class' indicates whether the shared information has been validated by a human prior to sharing.|
+|Credibility (8.2.1) and (8.4.3)|The Admiralty Scale taxonomy can be used to measure the credibility of an event. The analyst experience taxonomy can be used to assess the credibility of an analysis of an event. The likelihood-probability taxonomy can also be used to measure the credibility of an event. The correlation feature and sightings can also help assessing the credibility of an event. Whitelist and Warning lists improve false positive detection.|
+|Priority (8.2.1)|MISP integrates six levels of priority aligned with NCCIC, DHS, and the CISS.|
+|Criticality (8.2.1)|"Threat Level" of a MISP event indicates the level of criticality. The impact overall rating taxonomy. The victims employee count taxonomy.|
+|Sensitivity (8.2.1)|NATO classification.|
+|Dissemination markings (8.4.1)|Traffic Light Protocol (TLP) taxonomy. Different level of sharing model can be used, restricting the propagation of events.|
+|Information disclaimer (8.4.2)|There is no specific field or free text available at the event level in MISP to add a custom disclaimer to list any special requirements to follow by the recipients in addition to the normal information marking. However, it is possible to add custom taxonomies in MISP. Moreover, as explained in the two following points, it is possible to contact the reporter or ask for clarification.
+ In MISP it is possible to contact the reporter of an event to ask for clarification. For each event, an 'Event Discussion Thread' can also be used to ask for clarification.|
+|Sensitivity reduction (8.4.4)|Sightings in MISP can be used to evaluate the value of an attribute over time. Especially sightings of type "Expiration" can be added to an attribute to indicate that the attribute has lost value (e.g. URLs which have been cleaned after some time). The MISP infrastructure-state taxonomy can also indicate if the adversary infrastructure at the event or attribute level is still active or is down.|
+
MISP also includes a feature to protect the anonymity of the source and the recipient of the information in the community (controls 8.4.5 and 8.4.6). With the MISP [delegation](https://www.circl.lu/doc/misp/delegation/) feature, an organisation can ask another organisation in the same community to publish its own event in order to remain anonymous. In a MISP instance, it is normally possible to consult the list of all organisations in the community. However, the operator of the MISP instance (in other words, the supporting entity) has the possibility to hide this list (enabled by the option “MISP.showorg”) ensuring anonymity of all recipients (i.e. organisations) in a community.
