I have noticed the same... I believe that not much is happening on this for the community.

Hallo Sir,
ich bin kein Entwickler oder Ähnliches, ich habe auch nur Fragen gestellt.
Show,Adios....good bye!!

2015-09-15 11:08 GMT+02:00 Konrad Mrożek notifications@github.com:

I see that nothing has changed in the repository for a long while. Only
README.md file changes. Does the development take place somewhere else?

—
Reply to this email directly or view it on GitHub
#16.

I had mentioned to Rob I wanted to start working on this and he said don't bother. I believe they are keeping the latest developments in-house for now, and are looking to bring it to production soon.

Did he say anything more about their plans? Fido needs complete refactoring from what I've seen in the code. Everything is written with statics.

Well it would be nice if they would release some kind of statement. I'm sure this may be Rob's project outside of Netflix, but in either case this project needs some type of progress to keep it alive. I would settle with any kind of plan, but atm it's not worth even checking. I plan on checking back occasionally though, since it has a lot of promise.

I don't think it's being developed outside of Netflix - I think it's being developed outside of GitHub.

The question is: when that happens, will it again be on GitHub? Or have we seen the last of the code?

From: A Smith [mailto:notifications@github.com]
Sent: Tuesday, September 22, 2015 2:58 PM
To: Netflix/Fido Fido@noreply.github.com
Subject: Re: [Fido] The development of Fido ongoing? (#16)

I don't think it's being developed outside of Netflix - I think it's being developed outside of GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-142385568.

Greetings everyone,

The development on Fido is very much continuing. We depend on it too much here at Netflix and I've worked too hard the last 4+ years to let it die. You're not seeing the effort yet, but I assure you I'll be putting in many long weeks to get Fido done right. Additionally, I've received a great deal of feedback from individuals, companies and security vendors on wanting to leverage, integrate with or contribute to Fido. The concept and prototype we released apparently strikes a chord. :) That said, because it's a prototype the current code base presents challenges for growth, contributions and it's not accessible enough for a non-developer to easily setup. Not a huge deal, it's a prototype and is the nature of such things. The lessons and concepts learned are more important than the flimsy code used to prove theories and designs.

What I've been working on since my return to Netflix is designing, partnering and coming with the the best way to get this done. As the sole developer of Fido the last 4 years I'm very much looking forward to leveraging more help... whether they be external or new Netflix hires. If that's you, let me know and I'll get you more included. If you want to know more, just email me and I'm more than happy to schedule a call, trade emails or do a screen share. UI mockups and testing are my life these days and I love to bounce ideas off people. And once I have a concise plan I'll share it to get opinions and advice too.

To give you a glimpse, though, at a high level Fido would become an Ubuntu virtual appliance with a full stack fitting the needed capabilities. The UI will be heavily modified Bootstrap inspired by the ProtectWise console, with a Node.js server backend running on Nginx. The DB layer will be a hybrid using either MongoDB or RethinkDB(<--leaning toward this because of it's ability to push instead of needing to poll). If I can find a good C/C++ developer then anything requiring speed will be moved there. Which leaves the 'squishy middle layer'... which I'm still undecided on.

To answer your questions about the code, though, all code will be put on Github. The 'outside' work mentioned in the thread either has to do with my 2 month sabbatical away from Netflix, or with security startups in the same space as Fido who I like to work with.

Thanks for your questions and I hope to speak with each of you in the future.

Thank you for clarifying this!

From: Rob [mailto:notifications@github.com]
Sent: Wednesday, September 23, 2015 12:51 AM
To: Netflix/Fido Fido@noreply.github.com
Cc: Rudman, Ron rjrudman@mitre.org
Subject: Re: [Fido] The development of Fido ongoing? (#16)

Greetings everyone,

The development on Fido is very much continuing. We depend on it too much here at Netflix and I've worked too hard the last 4+ years to let it die. You're not seeing the effort yet, but I assure you I'll be putting in many long weeks to get Fido done right. Additionally, I've received a great deal of feedback from individuals, companies and security vendors on wanting to leverage, integrate with or contribute to Fido. The concept and prototype we released apparently strikes a chord. :) That said, because it's a prototype the current code base presents challenges for growth, contributions and it's not accessible enough for a non-developer to easily setup. Not a huge deal, it's a prototype and is the nature of such things. The lessons and concepts learned are more important than the flimsy code used to prove theories and designs.

What I've been working on since my return to Netflix is designing, partnering and coming with the the best way to get this done. As the sole developer of Fido the last 4 years I'm very much looking forward to leveraging more help... whether they be external or new Netflix hires. If that's you, let me know and I'll get you more included. If you want to know more, just email me and I'm more than happy to schedule a call, trade emails or do a screen share. UI mockups and testing are my life these days and I love to bounce ideas off people. And once I have a concise plan I'll share it to get opinions and advice too.

To give you a glimpse, though, at a high level Fido would become an Ubuntu virtual appliance with a full stack fitting the needed capabilities. The UI will be heavily modified Bootstrap inspired by the ProtectWisehttps://www.protectwise.com console, with a Node.js server backend running on Nginx. The DB layer will be a hybrid using either MongoDB or RethinkDB(<--leaning toward this because of it's ability to push instead of needing to poll). If I can find a good C/C++ developer then anything requiring speed will be moved there. Which leaves the 'squishy middle layer'... which I'm still undecided on.

To answer your questions about the code, though, all code will be put on Github. The 'outside' work mentioned in the thread either has to do with my 2 month sabbatical away from Netflix, or with security startups in the same space as Fido who I like to work with.

Thanks for your questions and I hope to speak with each of you in the future.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-142490634.

Thanks Rob for your comment. Have you started the development of new version Fido? I assume that will be complete rewrite of Github hosted Fido or will you use any part of prototype.

Trying not to get too deep into new code until I've completed planning and understand the available resources I'll have to accomplish this. Also been talking to people smarter than I around components in the stack, pros/cons. However, I can't help myself some days, so current work I've done is around the configuration UI, which was one of the critical pieces missing from the current code base. Configuring software through direct database edits is a terrible user experience. And considering the number of current and future connectors, if someone can't easily configure Fido it won't be of much use, so lowering the bar around setup is important. Also doing initial design planning around an admin framework, architecture, etc.

As for the code, the core of it needs to be rewritten based on lessons learned. The biggest lesson learned, from a code perspective, was around speed/scale. Four years ago we were only processing a handful alerts a day, but as our security stack grew and gave us better visibility the number of items to process has grown. There have also been opportunities to turn Fido into a security detector itself by doing an integration for vendors that expose the underpinnings of their product such as Carbon Black or ProtectWise... or possibly even leveraging something like Bro. A Bro integration would be intensive, but is one that really fascinates me. :) I've also had the desire to break up the code into more manageable pieces. As it stands now Fido is a synchronous/sequential process and could be broken up to it's important pieces as a microservice architecture and to implement parallelism/multithreading to tackle large volume. This will make Fido more maintainable and scalable for different environments or the different pieces in a security stack.

Conversely, non-core code, such as connectors for threat feeds and detectors, could be refactored and used.

An enthusiastic second to reshaping FIDO around asynchronous processing. Thanks, Rob!

From: Rob [mailto:notifications@github.com]
Sent: Thursday, September 24, 2015 1:29 PM
To: Netflix/Fido Fido@noreply.github.com
Cc: Rudman, Ron rjrudman@mitre.org
Subject: Re: [Fido] The development of Fido ongoing? (#16)

Trying not to get too deep into new code until I've completed planning and understand the available resources I'll have to accomplish this. Also been talking to people smarter than I around components in the stack, pros/cons. However, I can't help myself some days, so current work I've done is around the configuration UI, which was one of the critical pieces missing from the current code base. Configuring software through direct database edits is a terrible user experience. And considering the number of current and future connectors, if someone can't easily configure Fido it won't be of much use, so lowering the bar around setup is important. Also doing initial design planning around an admin framework, architecture, etc.

As for the code, the core of it needs to be rewritten based on lessons learned. The biggest lesson learned, from a code perspective, was around speed/scale. Four years ago we were only processing a handful alerts a day, but as our security stack grew and gave us better visibility the number of items to process has grown. There have also been opportunities to turn Fido into a security detector itself by doing an integration for vendors that expose the underpinnings of their product such as Carbon Blackhttps://www.bit9.com/solutions/carbon-black/ or ProtectWisehttps://www.protectwise.com/... or possibly even levering something like Brohttps://www.bro.org/index.html. A Bro integration would be intensive, but is one that really fascinates me. :) I've also had the desire to break up the code into more manageable pieces. As it stands now Fido is a synchronous/sequential process and could be broken up to it's important pieces as a microservice architecture and to implement parallelism/multithreading to tackle large volume. This will make Fido more maintainable and scalable for different environments or the different pieces in a security stack.

Conversely, non-core code, such as connectors for threat feeds and detectors, could be refactored and used.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-142996748.