Community contribution: joining forces or multiply solutions?

Published: 2018-11-11. Last Updated: 2018-11-11 14:29:44 UTC
by Pasquale Stirparo (Version: 2)
1 comment(s)

Today’s diary will be less technical than usual, and more “philosophical” let’s say (because, why not, we need those too :)) Last week I shared a thought on twitter, saying that sometimes I wish in our community we would stop “reinventing the wheel” by developing yet another FOSS tool that solves the same problem, instead of joining forces and build fewer but better and longer term solutions. This generated few interesting conversations both online and offline.

Please keep in mind that, for me, there is no right and wrong side on this, I think both have valid arguments, but nevertheless I felt I would like to hear more you about this, since it’s a topic that I hear in more and more often into, and of course the “dream” of one day seeing this happen. There are several ways to contribute in our community:

  1. Write a full fledged tool/framework that solves one or more problems (e.g. Metasploit [1], plaso [2], MISP [3], Viper [4], TheHive [5], YETI [6], Volatility [7], etc.). This is something you definitely need be capable of to do, and not everybody is able to (I’m certainly one of those who is not).
  2. Write scripts / smaller solutions that solve one specific problem (yours or someone else’s). These is extremely useful because you solved a specific problem, and even if this is yet another command someone may need to run, maybe someone else will pick it up and integrate that functionality into a bigger framework.
  3. Use and test tools written by other, and report bugs as thoroughly documented as possible. Now, this and the next point are largely underestimated. Submitting bugs to the author(s) of a tool is super useful and super important for the continuous improvement of such tool. Also, the author(s) could never run into all possible use cases, therefore some bugs will show up and be fixed only if you all report them. Please, do it!
  4. So many ways to contribute without the need to know/wanting to code, some examples:
    • Write/update documentations for tools you use.There is an extreme lack of (updated) documentation, and I cannot stress enough how important such contribution would be. Tools author(s) are often (and understandably so) very busy keeping up fixing bug and implementing new features, and documentation is not the obvious priority. So one way to give back would be by doing so. And we all would be extremely thankful to you.
    • Contribute to projects where there is actually no code to write, but rather collect, centralize and organize information such as ForensicArtifacts [8] or mac4n6 Artifacts Project [9][10] (shameless plug, I know, but I think it’s a good use case for this). All you need to do for the two above examples is to share artifacts location you have found across your investigations.
    • Etc.
  5. You name it… so many ways (no more excuses not to contribute).

The focus of my original thought is mostly on the first of the above points. There are not too many people (compared to the overall size of the community) able to code at such level, and sometimes seeing the fragmentation of big good projects which overlap 80-90% in functionalities makes me wonder of the potential those developers could reach if joining forces on the same project.

I totally agree, it’s not easy, and motivations to do so are as valid on both sides. The most common initial reason I hear is “well, none of the tools out there covered all my needs, so I (we) decided to write it from scratch.”. Fair point. However, is it really worthy to do so instead of bringing in those 10-20% new features you need into the existing project?

Some people feel like writing it in a different language would boost performance and longer term maintenance/development, or simply are good at a different language, and this would go against the author(s) of the original tool. Some other want to have the control of the long term development, and you definitely have if you own the tool. Still others advocate for more diversity, I definitely do agree that diversity (as always and in every context) is good. Having multiple solutions which can help you double check your findings is great (never blindly trust one source only). But is too much diversity in tooling still good?

As I wrote on twitter, this is a dream, I’m aware of it. But whether you are one of those gifted who can Code or not, I would love to hear your opinion.

One final message: clearly, you do not need to know how to code to contribute to FOSS projects. Pick one and start contributing today!

Happy Hunting,
Pasquale

References:
[1] - Metasploit, https://github.com/rapid7/metasploit-framework
[2] - plaso, https://github.com/log2timeline/plaso
[3] - MISP, https://github.com/MISP/MISP
[4] - Viper, https://github.com/viper-framework/viper
[5] - TheHive, https://github.com/TheHive-Project/TheHive
[6] - YETI, https://github.com/yeti-platform/yeti
[7] - Volatility, https://github.com/volatilityfoundation/volatility
[8] - ForensicArtifacts, https://github.com/ForensicArtifacts/artifacts
[9] - mac4n6 Artifacts Project, https://github.com/pstirparo/mac4n6
[10] - mac4n6 Artifacts Project, https://docs.google.com/spreadsheets/d/1X2Hu0NE2ptdRj023OVWIGp5dqZOw-CfxHLOW_GNGpX8/edit#gid=1317205466

---

Pasquale Stirparo, @pstirparo

1 comment(s)

Comments

Lets not say “philosophical”, lets say managerial or PM.

1-utilize and build within a framework. That provides several benefits, like reduciing training and documentation. Modularity allows user to play with whatever they want to play with.

Improvement of documentation should be a major effort. It is a challenge even for commercial products. Again, this is where buildilng in a common framework helps.

Both of these suggest that there is an organization coordinating this efforts. Someone needs to build the frameworks and to establish specifications for it. If none of the frameworks works, build a better framework. But yet another ping tool might not be much of an advancement.

Another big effort that must be addressed is Continuous Monitoring (ConMon). The tools must provide common reporting and coordinated output. Network and host tools must be able to provide common output format as does the Audit tracking (as does the neaarly dozen other technologies noted in NIST SP 800-137. Network, host or audit monitoring are not ConMon. But all these must be able to commonly contribute to ConMon without much translation, reformatting, conversion, etc. The (technical) tools must be able to correlate to controls (FISMA, PCI, HIPAA, as appropriate) so that ConMon can be performed. For example, Network/Router/Firewall tools must correlate to the requirements in SC-5 and/or SC-7 (these 2 must be on your ConMon List).

Diary Archives