Skip to content
Collaborative, web-based case management for incident response
Branch: master
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
app remove routes and links for half-baked features Jun 27, 2019
bin purge webpacker and actiontext Jun 13, 2019
config remove routes and links for half-baked features Jun 27, 2019
db made admin false by default Jun 26, 2019
docs added lack of abstraction benefit Jun 28, 2019
landing-page remove completed feature Jun 20, 2019
lib get datatables working Jun 9, 2019
log initial commit May 31, 2019
public initial commit May 31, 2019
site generate site for documentation Jun 30, 2019
storage initial commit May 31, 2019
test make incident description rich text Jun 25, 2019
tmp initial commit May 31, 2019
vendor initial commit May 31, 2019
.browserslistrc add rich text editing to incident description Jun 12, 2019
.dockerignore created .dockerignore Jun 4, 2019
.env.sample 2fa works (but poorly) Jun 25, 2019
.gitignore add .netlify to .gitignore Jun 27, 2019
.ruby-version initial commit May 31, 2019
.swn add rich text editing to incident description Jun 12, 2019
Dockerfile set RAILS_SERVE_STATIC_FILES in Dockerfile Jul 1, 2019
Gemfile make incident description rich text Jun 25, 2019
Gemfile.lock make incident description rich text Jun 25, 2019
LICENSE Create LICENSE Jun 14, 2019
README.md add Docker Compose instructions Jul 1, 2019
Rakefile initial commit May 31, 2019
babel.config.js add rich text editing to incident description Jun 12, 2019
config.ru initial commit May 31, 2019
docker-compose.yml can run INCIDENTS with a separate postgres DB Jun 13, 2019
mkdocs.yml set site name Jun 27, 2019
package.json make incident description rich text Jun 25, 2019
postcss.config.js add rich text editing to incident description Jun 12, 2019

README.md

INCIDENTS

Gitter

INCIDENTS is a web-based, actively maintained case management tool for incident response, just like TheHive.

You can use INCIDENTS whether you're investigating a malware infection, a phishing campaign, insider abuse, an application vulnerability, a denial-of-service attempt, or any other kind of security incident.

If you work at a SOC, MSSP, incident response firm, or an internal detection/response team, INCIDENTS is for you.

Get INCIDENTS Running Locally

# change environment variables in .env.sample, then:
cp .env.sample .env

# build docker image
docker-compose build

# create and migrate database
docker-compose run web rake db:create db:migrate

# start application
docker-compose up

# create initial user (see below)
docker-compose exec web rails console

Create initial user:

user = User.new(username: 'admin', email: 'admin@protonmail.com', password: 'mypassword', admin: true)
user.save

Then visit http://localhost:80

Why INCIDENTS?

Investigations are tree-like: a piece of malware may spawn an enterprise-wide sweep, which may find a related piece of malware, which may spawn another sweep, and so on.

Unfortunately, existing ticketing systems -- like TheHive and JIRA -- don't let you create subtickets of subtickets. So effectively your tree can only have 2 levels--and they don't show you a visualization of the tree, either.

INCIDENTS models an incident as a tree of tickets, with any number of levels.

Tree

I believe this approach better captures an incident responder's mental model of an incident.

Benefits

  • Avoid missing things with centralized lead management--whether you're analysing a single system or leading a large engagement
  • Keep people on the same page--team members can glance at the tree to find out what's going on, instead of reading old status updates or reading the entire Slack channel
  • Complete investigations faster--divide large tasks into smaller tickets you assign to people to get things done in parallel. And analysts can identify open tickets to work on, without waiting for the investigation lead
  • Preserve institutional knowledge--document how investigations developed over time to reference in future incidents and for training new analysts
  • Improve your IR process--by documenting an investigation's evolution, be able to look back and find bottlenecks, areas for improvement, opportunities for automation
  • Tame incidents with large scopes--people only need to worry about the few levels in the tree below theirs, instead of being exposed to all the information about the incident

Concepts

  • Create an incident for each investigation
  • Each incident has many tickets, or pieces of work.
  • If a ticket needs to be investigated further, mark it as a lead.
  • Add comments, attachments, and observables (aka indicators) to a ticket.
  • Add child tickets to a ticket to break it down into smaller pieces, or to indicate the ticket spawned another piece of work.

Features

  • Restrict who can view an incident
  • View all an incident's attachments in one place
  • View all an incident's observables in one place
  • View all an incident's leads in one place
  • Drag/drop nodes in the tree to quickly reorganize an incident
  • Tag indicators, attachments, tickets, and incidents
  • Assign tickets to users
  • Assign statuses and priorities to tickets
  • Keyboard shortcut for creating an incident

Tech Stack

INCIDENTS is built using:

  • Ruby on Rails
  • ActionText
  • Bulma
  • JQuery

Get in Touch

To request a feature or report a bug, please open an issue on GitHub

You can email the author at veeral.patel@berkeley.edu. I reply to all emails, and most within a couple hours. I welcome feedback!

We're on Gitter, too.

You can’t perform that action at this time.