mirror of https://github.com/MISP/misp-training
46 lines
1.8 KiB
Plaintext
46 lines
1.8 KiB
Plaintext
|
|
||
|
Model of governance
|
||
|
- Dictatorship instead of democracy
|
||
|
- Gathering ideas, issues, use-cases, code from the community is key, listen to them but reserve the right to veto
|
||
|
- Prevents malevolent community members from blocking the process / imposing tunnel-visioned ideas
|
||
|
- Don't wait for the perfect implementation, start small extend it later
|
||
|
- If the idea doesn't seem suitable for the above, shelf it as soon as possible
|
||
|
|
||
|
Development process based on failures
|
||
|
- Any idea needs real-world validation
|
||
|
- Be willing to throw away features that "sure seemed like a good idea at the time"
|
||
|
- Failures can often be used to pinpoint better alternatives
|
||
|
- Format follows the implementation (code is law)
|
||
|
|
||
|
PMF model
|
||
|
|
||
|
On the flip-side, the dangers of sticking to theoretical format development for too long
|
||
|
- The same mistakes will be made anyway
|
||
|
- Piling mistakes on shaky foundation will be more difficult to undo later
|
||
|
- technical reasons
|
||
|
- sunk cost fallacy
|
||
|
|
||
|
Designing a standard with sharing in mind (how not to do it)
|
||
|
- Originally the sharing aspects were quite limited (private flag)
|
||
|
- If I want to keep it within my organisation, simply set the flag
|
||
|
- If not set any organisation can see it on the instance
|
||
|
- Utterly simplistic, only worked on communities using a hosted MISP
|
||
|
|
||
|
Designing a standard with sharing in mind (how to be a minimalist)
|
||
|
- Needed to be extended once communities started self-hosting MISP to be able to control the distance of the data-flow
|
||
|
- Distirbution levels
|
||
|
- Organisation only (private)
|
||
|
- Community
|
||
|
- Connected community
|
||
|
- All
|
||
|
|
||
|
Designing a standard with sharing in mind (going all out)
|
||
|
- Still not covering all use cases, certain types of users wanting more granularity
|
||
|
- Sharing groups (distribution lists)
|
||
|
- Complex system for persistent and special ad-hoc use-cases
|
||
|
- Next step: Multiple sharing groups/nested sharing groups
|
||
|
|
||
|
|
||
|
|
||
|
|