FIR (fast incident response) in docker

FIR (Fast Incident Response) is a project by CERT Société Générale. It is a nice system to do incident tracking and I use it on a regular basis for over a year now. After a year of daily use, I gathered the users and a series of issues and wanted features where expressed.

To make things go forward in an easy way I decided it was time to dockerize the installation so the end users can give quick feedback on features under development.

Although there is a Dockerfile in the repo, I decided to make my own based on the existing one:

# Dockerfile to build FIR container
# Original Dockerfile by Kyle Maxwell https://github.com/certsocietegenerale/FIR/blob/master/docker/Dockerfile
#
# to build: docker build -t fir .
# to run: docker run -d p 8000:8000 fir
# webinterface: http://x.x.x.x.:8000
#
# default administrator: admin
# default password:  admin

# Based on ubuntu:latest
FROM ubuntu:16.04
MAINTAINER Erik Vanderhasselt

# Set environment variables
ENV DEBIAN_FRONTEND noninteractive

# Upgrade Ubuntu
RUN \
  apt-get update && \
  apt-get dist-upgrade -y && \
  apt-get autoremove -y && \
  apt-get clean

# Set the timezone
# https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1554806
RUN ln -fs /usr/share/zoneinfo/Europe/Brussels /etc/localtime
RUN dpkg-reconfigure -f noninteractive tzdata

# Install dependencies
RUN apt-get install -y python-dev
RUN apt-get install -y python-pip
RUN apt-get install -y python-lxml
RUN apt-get install -y git
RUN apt-get install -y libxml2-dev
RUN apt-get install -y libxslt1-dev
RUN apt-get install -y libz-dev

# Install the latest version of pip
RUN pip install --upgrade pip

# create the user and group
RUN groupadd -r fir
RUN useradd -r -g fir -d /home/fir -s /usr/sbin/nologin -c "FIR user" fir

# Download FIR from Github
WORKDIR /home
RUN mkdir /home/fir
RUN cd /home/fir
RUN git clone https://github.com/certsocietegenerale/FIR.git
RUN mv FIR fir
RUN chown -R fir:fir /home/fir

# install the requirements
WORKDIR /home/fir/FIR
# remove psycopg2==2.6.2 from requirements.txt since we are not using PostgreSQL
RUN sed '/^psycopg2/d' /home/fir/FIR/requirements.txt > /home/fir/FIR/req1.txt
# run pip
RUN pip install -r /home/fir/FIR/req1.txt

# prepare to run
USER fir
ENV HOME /home/fir
ENV USER fir
WORKDIR /home/fir/FIR
RUN ./manage.py migrate
RUN ./manage.py loaddata incidents/fixtures/seed_data.json
RUN ./manage.py loaddata incidents/fixtures/dev_users.json

###############################################################################

# make it run
EXPOSE 8000
ENTRYPOINT ["/home/fir/FIR/manage.py"]
CMD ["runserver", "0.0.0.0:8000"]



To build the container you do sudo docker build -t fir .
To run the container you do sudo docker run -d p 8000:8000 fir
To access fir you point your browser to http://localhost:8000, the default login is admin and the default password is admin too.

Now you have a nice system to record your incidents which is a good start but you need incident response procedures. If you got no idea what I am talking about I recommend you read up on the documents written by ENISA, NIST, CERT.org, etc.

Is red a critical issue?

A couple of weeks ago I was giving a training and somebody made the remark that if something has the color red it is critical. The logic she used was parallel to the traffic lights but there is a problem with this. It starts with the idea that everybody can see colors and this is not the case.A good friend of mine is color blind for red and green and that is how I became aware of the issue.

When we are talking about a traffic light what color is lit actually, since we agreed upon the fact that the colors are in an order and it is thus actually the order of the light that matters and not the color. This is why color blind people are able to drive.

When we are talking about incident response this becomes an whole other issue since the color tag of an incident is pointless to a color blind person. If my friend would have a look at a dashboard tagging one incident red and another one green they would both be grey-ish. This means he has a 50% chance of starting to work on the incident with the least priority.

The solution is actually pretty simple, you use a defcon-type scale where 1 means it is your number one priority and the lower on the scale the incident is rated the less attention it will get. The classification of your incidents will influence greatly the value it gets on this scale.