Hi @cronlabspl and thanks for your comments.
I have commented those of your comments I feel it make sense to comment 
Excuse me, what? So, once on the fire datalake, all it takes for bad actor to be withdrawn from fire DL is to become silent ( ceasse all activity ) for 72 hrs? After 72 hrs they can become " vocal " again?
Seriously flawed…
The point is that in the vast majority of cases, a machine that is malevolent now is a legitimate machine that was breached. Sooner than later, the owner is going to be made aware of it (abuse email etc.) and is going to clean up its mess. On the other hand, if the machine start to attack again, it is going to be banned again (and quicker than the first time) and being shared back to the community. Past participative initiatives have failed to “expire” bad IPs, and it lead to issues for legitimate people. Obviously we don’t want that.
Why? If its wrong, than what we should think CS tries to be?
Seeing CS as a f2b replacement is seeing only the tip of the iceberg. It’s so much more. The real endgame here is the participative CTI.
But, we already have well established, proven, working mechanism for detection and prevention of DDoS and other attacks. Its called CloudFlare; we dont need yet another clone.
Are you using cloudflare to deal with scalping or credit card stuffing ? CS is going to simply leverage cloudflare as a way to remediate an attack, more business-oriented scenarios (ie. credit card stuffing, or scalping for example) are so dependent on your local application that you usually need to come up with your own scenarios.
For every serious security admin, thats huge NO-NO
This has been commented elsewhere. No need to repeat that.
GROK = REGEX…
The goal here is mostly to hide the complexity of such regexps
- where is this " curation platform " hosted ?,
AWS Europe, mostly
- if whole project is OSS, than we. should be able to have ( at least read ) access to this " curation platform ", dont you think?
No, however the IPs that have been reliably flagged as being malevolent are automatically shared back to the community (sent to each user to be integrated into their blocklists)
- user’s IP is PII so storing it without user consent is illegal ( GDPR ),
Yes. That is why neither collect nor store that.
- any guarantee that " curated platform " is leak-proof?
Noone in their right mind who knows anything about security would want to make claims that anything is ‘hacker-proof’. But we do our best. Most developers have a background as pentesters and out code has been audited by an acknowledged 3. party earlier this year. So I can say that we do our best.
- if you say that other installations of CS rely on this " curated platform " than how do you know what other people do with data downloaded from this platform?
We don’t, we redistribute the IPs that we know for sure are bad to the community, so that they can protect themselves against these
- whats the data retention period on this platform?
Could you elaborate on which data you’re talking about? The ‘smoke’ datalake with the ‘maybe’ malevolent ips or the ‘fire’ datalake with the verified ones?
- if CS is not SIEM, than what it is? From what one can read, as well as how you present CS, its clear that CS is ( or at least tries to be ) fully fledged SIEM software
Not to us. We don’t claim (or think) that it’s a SIEM. We do however think that CS is a lot of things in one: IDS, IPS, firewall, CTI and more. There’s nothing quite like it out there already.
In terms of our business model, data, privacy and open source there has (naturally) been critical questions before - and we expect it to happen again (which is totally fine). People tend to expect that when something’s free there’s a nasty downside. I honestly can’t see that here. In case you are interested in those issues as well, our CEO wrote a couple of posts on Reddit about it: here and here.
I hope my replies answered at least some of your questions. If not, feel free to ask again. And have a nice day!
/k