Information sharing practises
Information sharing is an evolving matter where there is no fixed guidelines. Attacks, actors and threats evolve over time which require a continuous evolution in the response which includes information and threat sharing actions.
An event or attribute can be useless in one case and key in an other, or even become useful later on. When gathering information to share, original information and reference should be kept to ensure future correlation or usage. MISP can hide partially the information (ref to add for new misp internal taxonomy) if not directly required.
Sharing inside and/or outside your organization?
Sharing outside your organization usually implies that you have a certain level of responsibilities concerning the information shared. Within your organization, other responsibilities might be applicable (e.g. applicable data processing laws). As MISP supports a flexible sharing model where you can share within your organization only, with other organizations or using a mixed model. The below check-list is to ensure a consistent approach within each organization and especially when they expect to share at a more larger scale. The decision of sharing is usually a specific policy within an organization. The four models of sharing included in MISP supports different the whole set of sharing models but the model can be safely extended with the MISP sharing groups.
What's not to share
MUST NOT
- Copyrighted materials where (re)distribution is not allowed.
If you have setup a set of MISP within the organization, the restriction might be not applicable as you stay within the same organizaton. The owner of the information should review the license agreement to ensure that the distribution policies are compatible.
- Personal identifiable information or private information which are out of the scope from the sharing practices.
Privacy and its legal regulation is a complex topic. We highly recommend to define an [information exchange policy](ref to IEP taxonomy) to ensure an appropriate balance between the benefit of information sharing and your legal practices.
Events not to share
- false positives: events have to be cross-checked to avoid polluting the database
- private informations from other organisations received under NDA
- too generic information (such as clients infected by a common malware) it they are not doing anything else
- OSINT information if it has already been encoded
Events to share
- everything as long as you find it in your consistuency
- Security events (successful or not) happening in your infrastructure, if they are targeted
- OSINT information if it has not already been encoded
Most relevant attributes
The more attributes, the better.
Still, we would sort the network attributes by importance this way:
- remote IPs
- domains
- email addresses (faked of not)
- URLs
- user agent
And for the malwares:
- samples (sample itself or md5, sha1 and sha256 hashes)
- filenames and filesystem paths
- mutexes, all uniq identifiers
Attributes not to share
- information that identify an individual (except is they are relevant to the case)
- too generic information: is the malware is using 8.8.8.8 as a dns resolver, it is probably irrelevant