Distributed & real time digital forensics at the speed of the cloud
Перейти к файлу
Julien Vehent ec6e2e8764 [minor/bug] add program name to initlogger in agent 2014-06-10 15:33:39 -04:00
conf [minor] configurable detection of multiple agents in Scheduler 2014-05-09 18:07:14 -04:00
doc Merge pull request #15 from mozilla/compliance 2014-05-30 17:22:28 -04:00
examples/actions [doc] added type system to example actions 2014-05-30 17:18:53 -04:00
src/mig [minor/bug] add program name to initlogger in agent 2014-06-10 15:33:39 -04:00
.gitignore [doc] new logo 2014-04-01 17:49:35 -04:00
AUTHORS [doc] add missing AUTHORS file 2014-02-03 10:44:32 -05:00
LICENSE [medium] Makefile support 2014-02-03 10:42:36 -05:00
Makefile [minor] API compilation fix 2014-05-13 17:21:17 -07:00
README.md [doc] added bugzilla links to readme 2014-05-22 14:20:24 -04:00
inotify_make.sh [doc] better inotify_make information 2014-03-26 14:57:24 -04:00

README.md

MIG: Mozilla InvestiGator

MIG is OpSec's platform for investigative surgery of remote endpoints. It's a platform that allows investigators to send actions to pools of agents, and check for indicator of compromision, verify the state of a configuration, block an account, create a firewall rule or update a blacklist.

MIG logo

For example: an investigator launches an action to search for an apache module that matches a given md5 value. MIG will register the action, find all the relevant targets and send commands to each target with the detail of the action. Each agent then individually run the action using built-in modules locally, and sends the results back to the MIG platform.

Agents are designed to be lightweight, secure, and easy to deploy. All parameters are built into the agent at compile time, include the list of investigator's public keys. The agent binary is statically compiled for a target platform and can be shipped without any external dependency.

MIG is designed to be fast, and asynchronous. It uses AMQP to distribute actions to endpoints, and relies on Go channels to prevent components from blocking. Running actions and commands are stored on disk cache, and don't rely on running processes for reliability.

Speed is a strong requirement. Most actions will only take a few hundreds milliseconds to run. Larger ones, for example when looking for a hash in a large directory, should run in less than a minute.

Check out this 6 minutes presentation for background:

MIG youtube video

Goals

  • Query a pool of endpoints to verify the presence of a specific indicators (similar to IOC, but we use a different format)
  • Provide response mechanisms to lock down compromised endpoints
  • Periodically verify endpoint's compliance with the Security Policies

Features

  • Provide strong authentication of investigators
    • Actions must have a valid GPG signature, each investigator has a different key, for tracking.
  • Provide a way to inspect remote systems for indicators of compromise (IOC). At the moment, this is limited to :
    • file by name
    • file content by regex
    • file hashes: md5, sha1, sha256, sha384, sha512, sha3_224,sha3_256, sha3_384, sha3_512
  • Protect data security, investigate without intruding:
    • Raw data must not be readily available to investigators

Todo list:

  • More agent modules
    • low level devices (memory, file system blocks, network cards)
    • established connections
    • firewall rules
    • lots more ...
  • Provide response mechanisms, including:
    • dynamic firewall rules additions & removal
    • system password changes
    • process execution (execve) & destruction (kill)
  • Input/Output IOCs, Yara, ... through the API
  • Output results in standard format for alerting

Documentation

All documentation is available in the 'doc' directory.

Bug & Issue tracker

We use Bugzilla to track the work on MIG.