4 ms·
Hi HN, I'm the lead dev of MIG and author of this presentation. We've been using it at Mozilla for over two years now, and it's proven to be very useful in our
by jvehent 11y ago
Hi HN, I'm the lead dev of MIG and author of this presentation. We've been using it at Mozilla for over two years now, and it's proven to be very useful in our security effort. Happy to answer any questions you may have.
Also worth noting, there's a standalone install script at [1], and a deployment doc at [2].
[1] https://github.com/mozilla/mig/blob/master/tools/standalone_install.sh https://github.com/mozilla/mig/blob/master/tools/standalone_...
[2] http://mig.mozilla.org/doc/configuration.rst.html http://mig.mozilla.org/doc/configuration.rst.html
- zobzu 11y agoWhy do you use it instead of Grr/osquery?
- jvehent 11y agoMIG was started in 2013, and osquery did not exist back then. Even today, osquery does not provide a good way to remotely investigate your infrastructure, it's mostly a local-only tool (I know they are working on that now, but it's not a core feature). GRR was and still is a very strong inspiration to MIG. I interact with the GRR team regularly, and we exchange ideas. GRR takes the approach of transferring all data from endpoints into central servers for analysis, which adds high bandwidth and storage costs. It's fine if you're Google and have tons and tons of storage, but we wanted to go with a lean approach for MIG, so we pushed the investigation to the agents, and only return results, never any raw data. Not returning raw data has the added benefit of respecting the privacy of the endpoints being investigated, but also means that MIG is not your typical digital forensic imaging tool: it's a distributed search framework. If you want to take images of your systems, you need to do it via other means. (That said, we almost never need that capability).