What If CrowdSec Had Been Open Source From Day One?
Time flies! It has already been 5 years since I joined CrowdSec. The recent events about the leakage of our codebase led me to realize: what if we had been totally open source in the first place? Would we have done the work differently?
Perhaps a bit in the formatting, I could have removed some stray comments in the Git history, but not much in the core work. The core responsibilities remain the same: accurately assessing network size, implementing safeguards against data poisoning, and training models to classify IP addresses based on behavior.
The Internet never forgets
But let’s be honest, the Internet never forgets, and the Internet likes gossip. There are already several curious souls trying to dissect our codebase to find the shammy commit where we take all the user data and sell it to Big Corp.
Don’t waste your sweat (and your LLM tokens); you won’t find anything, not even close. If it were the case, the codebase would not have been published for free 4 months after the extraction. Instead, what you will learn about us:
Our KPIs reflect real network growth
KPIs are not emphasized; they are built methodically to reflect our network growth. Let’s be honest: every company has marketing claims, and most of the time figures are inflated by 10x (if not 1000x). However, I can confidently say that that is not our case. In the data science team, our goal is to explain why it makes no sense to claim 10 million installations (what is a Docker pull nowadays?) but to care about how many active watchers (Security Engines) report on a daily basis.
Yes, there are canaries in our Blocklists
We did put some canaries in our blocklists (and will continue to). Companies out there are indeed stealing our work by redistributing our IP reputation, hence violating our Terms of Service, and even taking profit out of it sometimes.
Yes, we run honeypots (all 30 of them)
We do run a network of honeypots. A whopping network of 30 machines, actually. It was necessary at the beginning to build a reputation system on signals we could trust. It then proved useful to test the load of our Console Organization and try alpha features in CrowdSec. It was never our intention to make it a cornerstone of our business model – and looking at some competitors turning back from this idea led me to believe it was the right decision. Now they are still up and running, yet they only represent a drop in the ocean. They produce 10,000 signals a day; that’s not even 0.001% of the total network traffic.
Why we call malicious IPs “pokemons”
We do call a “malicious-IP-reported-by-a-user” a “pokemon”. There are even around 1000 occurrences, according to GitHub. That’s shorter, and it makes the day-to-day work much more fun when you have to catch them all. We even built a Pokedex for that, but that’s only internal, of course.
Our marketing is backed by real data
We did produce marketing articles backed by genuine data analysis. When we released the article “With or Without CrowdSec: a tale of two servers”, a kind of A/B experiment between 2 servers–one with CrowdSec, one without– it was based on authentic data. We don’t make numbers up when we say we have 250k machines live protected by CrowdSec. That’s not even accounting for log centralization: large organizations usually run one CrowdSec on top of 10 or 100 services.
How we score IP reputation
We evaluate the reliability of our IP reputation by aggregating statistics over pokemons and watchers. We score the watchers based on network contribution and longevity and integrate this with statistics aggregated over IP reports to determine a malevolence probability.
What leaked, and what we reported
We did leak 83 email addresses of Console users. This is unfortunate but rather marginal compared to the 150k user base. All the details were already reported to the relevant authorities and the affected users.
How we use Console user data
We do aggregate user data to identify segments inside our Console users. Sometimes we intend to figure out who the correct audience is to become beta testers for a new feature. Sometimes it’s protective: we do have free-riders trying to breach the rules (and license agreements) to avoid paying for our CTI access. Most of the time we engage in conversation with them and try to identify what limitation they found with our current pricing strategy. Hopefully, the more we correct the direction, the less of a necessity it becomes.
What’s next for the data team
All this retrospective is, in the end, very positive for me, as it revives new content ideas. What if we released an updated version of the Tale of Two Servers? Or an Internet IP reputation map, implementing geohash-like tiles for IP ranges 😉?
There won’t be a best moment for a proposal, especially as I am pleased to announce that the team is expanding. Alexandre Monteil just joined to help me build more captivating stories about our network (and Pokemons).
Stay tuned!
