add: a small clarification regarding the "soft-delete" functionality in
MISP along with the optional sanitisation of content at MISP instance level.pull/8/head
parent
8ce00a9374
commit
06a088db9f
|
@ -91,7 +91,7 @@ For the processing activities for which CSIRTs act as data controllers, the lawf
|
|||
In most cases, data input in MISP directly relate to an attack, and are already specifically selected from the large amount of data analysed during an incident, for being useful to detect and/or mitigate the attack. In those cases, MISP usage satisfies the **data minimisation principle and the purpose limitation principle**. MISP also includes features to assess the usefulness of IOCs for threat detection and/or mitigation. For example, the field "IDS" in the "attribute" data model allows attributes to be exported directly to the intrusion detection system of one's network. It is easily understandable that attributes marked as "IDS" are necessary to detect and/or mitigate the threat. Other fields can be mentioned such as "Sightings", allowing other organisations to react on the relevance of the specific attribute, and "Related Events" showing which event(s) also include the same attribute (if an attribute is included in several events, it is most likely not a false positive, and therefore relevant to mitigate the related threat).
|
||||
|
||||
The **retention period** might be very different depending on the use-case of a sharing community. The GDPR states that personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed". In the case of MISP, as seen in the precedent chapter, personal data are in some cases already pseudonymised. Moreover, "personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes". MISP use cases also include research on threat actors and attacks and may need to keep data for long retention periods, longer after the last occurrence of specific attacks, in order for example to discover attack patterns and produce statistics.
|
||||
In the case where an entity no longer needs specific attributes in MISP, the entity has the possibility to delete the attributes (and events) on its local MISP instance. The creator of specific events or attributes can modify them, and other entities can amend events and attributes with information and corrections or propose the deletion of specific attributes, by creating a "Proposal Notification". These features could also be used in the scope of the **accuracy principle**.
|
||||
In the case where an entity no longer needs specific attributes in MISP, the entity has the possibility to delete the attributes (and events) on its local MISP instance. The creator of specific events or attributes can modify them, and other entities can amend events and attributes with information and corrections or propose the deletion of specific attributes, by creating a "Proposal Notification". These features could also be used in the scope of the **accuracy principle**. MISP includes a functionality to make a first "soft-delete" on a attribute level to keep a trace of the delete. An additional functionality, at MISP instance level, can be enabled to sanitise the contents of an attribute when a soft delete is done. The combination of these functionalities can support different levels of retention policy required by specific sharing communities.
|
||||
|
||||
## What are the grounds for processing information for the purpose of information sharing?
|
||||
|
||||
|
|
Loading…
Reference in New Issue