Welcome to the Monolith documentation site!

The documentation for Monolith is currently a work in progress so please be patient while we add new documentation for Monolith over time.

Monolith is licensed on a per user per year basis.

Pricing information for Monolith can be found here: Pricing Page

User Provisioning

When you purchase Monolith - your purchase includes a limit on how many active users you can have at any one time.

For Example: If you purchase Monolith with 5 active users, this means that you can have 5 active user accounts in Monolith. The users associated with these accounts can log into Monolith from anywhere and from as many different devices as they want.

Inactive users will not be able to access Monolith.

User Terms

Account sharing is not allowed in our licensing terms, however, exceptions to this rule can be made on a case-by-case basis.

License Expiration

If you choose not to renew your Monolith subscription, your Monolith access will revert to "Read-Only" mode. You will still have access to your Monolith data, but you will no longer be able to add new data or edit current data.

Your data will remain in Monolith for up to a year, after a year, we may permanently destroy any data still stored within our servers.

Data Export

An export of your data in Monolith can be requested at any time by making a request to support@monolithforensics.com.

The data export will consist of a SQL dump file and a ZIP file that contains files uploaded to Monolith.

Please allow up to 2 weeks to receive your data export.

Office hours are a weekly webinar hosted by Monolith Forensics owner and founder Matt Danner.

Feel free to join to ask questions, get some training, or request a demo of Monolith or specific feature.

The webinar is conducted over Zoom - you can register at this link:

Initial Installation

To download Monolith Desktop, go to the System section of the settings page and download the appropriate installer for you operating system (Windows or MacOS)

After installing Monolith Desktop and running it for the first time, you will be presented with an "API Mode" selection screen.

This screen allows you to connect Monolith Desktop to your Monolith Tenant, whether it is in the Cloud or On-premises:

Cloud Customers

For cloud hosted Monolith Tenants/Customers - keep the default selection as "Cloud". The region is defaulted to US/North America, but if you are a UK customer, change the region to "United Kingdom" and select submit.

This option ensures that Monolith Desktop will connect to the correct Monolith Server for your cloud deployment or region.

On-Premises Customers

For on premises customers - change the "API Mode" to "On-Premises". This mode allows Monolith to connect to an on-premises Monolith server that is running within your organization and network.

When you select the On-Premises option, you then need to enter your Monolith Server's API endpoint. This will typically be the IP address of your Monolith server, or a custom domain if you have one setup in your network.

The API endpoint must meet the following formats:

https://{monolith-server-ip-address}/api

https://{custom-monolith-domain}/api

Examples:
https://192.168.1.22/api
https://monolith.myorg.com/api

If Monolith Desktop can successfully reach the Monolith server, you will see a green check mark populate and the Monolith Login screen will load.

Reset Monolith Connection Settings

To reset Monolith's API connection settings, click the "Reset Monolith" button located on the Monolith Login screen. This will return you to the API mode selection.

Monolith Web App

Monolith can be accessed from web browsers such as Google Chrome, Firefox, and Microsoft Edge via one of the following URLs:

Monolith Desktop

Monolith be used as a desktop application called "Monolith Desktop". This app can be installed on MacOS and Windows Operating Systems.

You can download Monolith Desktop here:

Login

You can log into Monolith using your account email and password.

2-Factor Authentication

By default, all cloud users are required to use 2-Factor Authentication to login to their Monolith accounts. Monolith utilizes TOTP based 2FA, which means that users must have an authenticator application to use 2FA with Monolith. The following authenticator apps are recommended:

• Google Authenticator

• Microsoft Authenticator

On you first login to Monolith, you will be prompted to setup 2FA with the authenticator app of your choice. Open the authenticator app and scan the QR code presented by Monolith:

Once you have scanned the QR code, type in the 6-digit code generated by the authenticator app into the box at the Monolith Login screen.

For subsequent logins, you will be presented with a 2FA screen and asked to enter a 6-digit code generated by you authenticator application of choice.

2FA Reset

If you have lost your 2FA device or replaced it, a Monolith admin user can reset the 2FA device on your account. Once reset, Monolith will prompt you to connect a new 2FA device at your next login.

Disable 2FA

For cloud customers, you can request that 2FA be disabled for your account - please make a request to support@monolithforesics.com.

For on-premises customers, you can disable 2FA from your user profile page.

If your organization has purchased and setup SSO with Monolith, you will be able to log in with your SSO account.

When you type your email into the Monolith Login screen, Monolith checks your email domain and resolves it to your SSO provider. When you click the "Log In" button, you will be redirected to your SSO provider to authenticate. After authentication, you will then be redirected back to Monolith and given access to your Monolith Tenant.

Docker

Docker is a platform that uses OS-level virtualization to deliver software in packages called "containers". Docker is used to deploy, manage, and run containers within a variety of environments.

Monolith is deployed in on-premises environments using containers and Docker is recommended as the container management system to run and manage Monolith.

How Monolith Works

Monolith runs in a server-client configuration where users access and manage data via the Monolith desktop client or web application. A Monolith API server runs on a centralized host and handles HTTP requests from the desktop clients and web application. The API server communicates with a database to create, update, delete, and read data from the database.

The image above illustrates the basic setup of containers within an on-premises deployment. The containerized nature of Monolith allows for flexible and scalable on-premises deployment options.

Monolith Containers

NGINX proxy

This is a web server container that handles incoming requests from clients and proxies traffic to one of 3 containers: Monolith Web App,Monolith API, or the Relay App. This container can be configured to include custom domain TLS certificates.

Monolith App

This is the Monolith web application that can be access via a web browser. To access this application, you just need to navigate to the host system IP address or assigned domain name in a web browser - Ex: https://192.168.1.12

Monolith API

This container hosts an API server that can send authenticated requests for data to and from the Monolith and Relay web applications. This container connects directly to the MySQL server to store data and a file system to store files uploaded to Monolith.

Relay App

The Relay app container runs the Relay application. Relay is a web-based request system that allows non-monolith users to submit requests for forensic services.

MySQL DB

This container runs a MySQL database that stores data accessed and managed by users of Monolith and Relay. The MySQL database does not have to be a container inside Docker. You can use an external hosted MySQL database if you wish.

File System

This is not a container, it represents your chosen file system component to store files that are uploaded to Monolith and Relay. This can be the file system on the host system, AWS S3 object storage, or a network file share.

Watchtower

Watchtower is an optional container that manages automatic updates for the other containers. Watchtower checks for container updates every 30 seconds. When an update is available, Watchtower downloads the new container images and replaces the current containers with new containers built from the updates container images.

Where your license is managed

Currently, your on-premises license to Monolith is managed within the ".env" file that is within your Monolith package deployment folder.

There are two values within the ".env" file that related to your Monolith License:

MONOLITH_LICENSE_KEY=
MONOLITH_LICENSE_TOKEN=

When the Monolith server starts up, it derives your license from one of these two values.

Monolith License Token (Preferred - Offline Licensing)

The Monolith license token is a long string that is a securely signed token that contains your licensing information.

This method works in both online and offline environments and does not use the internet to operate.

The Monolith server derives your license details from this token.

This is the preferred method, because it does not rely on our licensing server to work and will keep your Monolith deployment operational even during internet outages.

Monolith License Key (Online Licensing)

The Monolith license key is a short, unique string that is associated with your Monolith customer account. Monolith uses this value to retrieve your licensing information from our online licensing server on the internet.

Updating your license

To update your license, simply replace the License key or token value in your ".env" file with a new one and restart your Monolith Docker deployment.

You can restart your Monolith Docker deployment with the following commands:

docker compose down
docker compose up -d

When first logging into Monolith, here are the first steps you should take to get Monolith ready for your forensic work and evidence:

1. Setup your Organization Info.

2. Create user accounts for your team.

3. Set the formatting for case numbers, evidence numbers, & storage numbers.

4. Create & Customize form selection options:

   1. Customize your Case Type selections.

   2. Customize your Case Status selections.

   3. Customize your Case Progress selections.

   4. Customize Evidence Type Selections.

   5. Customize Evidence Progress selections.

   6. Customize Time Entry Categories to use with the Task Management System.

   7. Customize Quality Assurance Issue Type selections.

5. Create and customize Quality Assurance checklists.

6. Create and upload evidence & storage labels with DYMO.

7. Create evidence locations.

8. Enter existing storage items.

9. Enter Forensic software.

Docker

Docker or Docker Desktop is required for Monolith on-premises deployments. Installation instructions can be found .

Hardware

The following hardware is required to properly run the Monolith API backend within Docker:

• Microsoft Windows 10/11, MacOS, or Ubuntu 20 system

• 4GB of RAM

• 2-core CPU

• At least 100 GB of storage (>500 GB recommended)

SMTP (Email Use)

To enable Monolith’s email capabilities, an email account is required with SMTP credentials:

• SMTP host

• SMTP port

• SMTP user

• SMTP password

These values are supplied to the Monolith API server/Docker container at run-time.

Amazon AWS S3 Integration

If you want to store Monolith files in AWS S3, you will need to have the following to integrate S3:

• AWS Access Key

• AWS Secret Key

• AWS Region & Endpoint

On-Premises Package

Once you have purchased Monolith and are ready to deploy - you will be provided with a Monolith On-premises deployment package. This package will contain configuration files necessary to run the deployment.

Package Contents

The package will contain the following items:

• .env

  • This is an environment file that will contain variables that are injected into your Monolith deployment at run time. This is where your licensing information will be location along with other settings.

• docker-compose.yml

  • This is a Docker deployment configuration file. This file dictates how the various Monolith containers will be built and deployed.

  • This allows you to use a pre-defined configuration so that you don't need to build the Monolith Docker deployment from scratch.

• init folder

  • This contains additional configuration files needed for successful deployment.

File Example

This file is used to define the deployment options for the various Docker containers that make up the Monolith on-premises deployment.

Unless you require an advanced deployment, you will not need to modify this file.

services:
  monolith-api:
    container_name: monolith-api
    image: monolithforensics/monolith-api:latest
    restart: always
    volumes:
      - ./data/logs:/usr/src/app/data/logs
      - ./data/Monolith:/usr/src/app/data/Monolith
      - ./data/Monolith-forms:/usr/src/app/data/Monolith-forms
    ports:
      - "3001:3001"
    env_file:
      - .env
    mem_limit: 512m

  monolith-forms:
    container_name: monolith-forms
    image: monolithforensics/monolith-forms:on-prem
    restart: always
    volumes:
      - ./data/logs:/usr/src/app/data/logs
    ports:
      - "3003:3003"
    mem_limit: 150m

  monolith:
    container_name: monolith
    image: monolithforensics/monolith:on-prem
    restart: always
    volumes:
      - ./data/logs:/usr/src/app/data/logs
    ports:
      - "3005:3005"
    mem_limit: 150m

  mysql:
    container_name: mysql2
    image: mysql:8.0.16
    command: --default-authentication-plugin=mysql_native_password --sql_mode=""
    security_opt:
      - seccomp:unconfined
    restart: always
    ports:
     - "3307:3306"
    environment:
      MYSQL_ROOT_PASSWORD: ${MONOLITH_DB_PASSWORD}
      MYSQL_USER: ${MONOLITH_DB_USER}
      MYSQL_PASSWORD: ${MONOLITH_DB_PASSWORD}
      MYSQL_DATABASE: ${MONOLITH_DB_NAME}
    volumes:
      - ./data/mysql:/var/lib/mysql
      - ./init:/docker-entrypoint-initdb.d
    mem_limit: 512m

  nginx:
    container_name: nginx
    image: monolithforensics/nginx:latest
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
     - ./data/logs/nginx:/var/log/nginx/
    # - /etc/nginx:/etc/nginx
    # - /etc/letsencrypt:/etc/letsencrypt/

  watchtower:
    container_name: watchtower
    image: containrrr/watchtower:latest
    restart: always
    environment:
     - WATCHTOWER_CLEANUP=true
    command: --interval 30
    volumes:
     - /var/run/docker.sock:/var/run/docker.sock
    mem_limit: 512m

How this file works

This file is used with the following commands to build, re-build, and remove the containers that run Monolith.

// Deploy Monolith
docker compose up -d

// Remove All Monolith Containers
docker compose down

Starting and Stopping Monolith Server

// Deploy and Run Monolith Containers
// Must be run in same directory as docker-compose.yml
docker compose up -d

// Remove Monolith containers
// ust be run in same directory as docker-compose.yml
docker compose down

These commands can be used together to conduct a "hard" restart of Monolith.

Various Docker Commands

// Show resource usage of docker containers
docker stats

// Show running containers
docker container ls -a

// Show downloaded container images
docker image ls -a

// Download fresh container image
docker pull [container-name]

// Restart container
docker container restart [container-name]

Docker CLI Reference

Additional Docker commands can be reviewed on Dockers official documentation pages:

https://docs.docker.com/engine/reference/run/

Docker Compose CLI Reference

Additional Docker compose commands can be reviewed on Docker's official documentations pages:

https://docs.docker.com/compose/reference/

Example

This is an environment variables file that is loaded into the Monolith Docker deployment at build/run time. These values determine various setup options and licensing information for your Monolith deployment.

The values are typically set for you when you purchase Monolith.

### Application Settings ###

### Mandatory Options ###

### Monolith License key
# Used to activate license

MONOLITH_LICENSE_KEY=
MONOLITH_LICENSE_TOKEN=

### API Token Secrets
# Used to generate secure access tokens and refresh tokens
# Set these to long, random alphanumeric strings

ACCESS_TOKEN_SECRET=
REFRESH_TOKEN_SECRET=


### Monolith Database Config

MONOLITH_DB_NAME=monolith
MONOLITH_DB_USER=monolith
MONOLITH_DB_PORT=3306
MONOLITH_DB_HOST=mysql
MONOLITH_DB_PASSWORD=

### Initial Monolith User - Only needed for initial setup

MONOLITH_ADMIN_FIRST_NAME=
MONOLITH_ADMIN_LAST_NAME=
MONOLITH_ADMIN_EMAIL=
MONOLITH_ADMIN_PASSWORD=

### Monolith Forms Settings

FORM_TENANT_NAME=
FORM_ORG_NAME=
FORM_TENANT_SLUG=
FORM_TENANT_EMAIL=

### OPTIONAL SETTINGS ###

### API Instance Total
# Set the number of API cluster instances to run
# default is 1 - which should be plenty for most deployments

#API_INSTANCE_COUNT=1

### File Service
# Choose the file service you wish to use
# Options are "S3" and "LOCAL"
# Defaults to "LOCAL" if not set
# S3 keys required if using S3 service

# FILE_SERVICE=S3
# FILE_SERVICE=LOCAL



### AWS S3 Config

# AWS_ENDPOINT={aws_endpoint}
# MONOLITH_FORMS_BUCKET={aws_bucket_name}
# MONOLITH_CLOUD_BUCKET={aws_bucket_name}
# S3_ACCESS_KEY={s3_access_key}
# S3_SECRET_KEY={s3_secret_key}

### SMTP settings
SMTP_HOST=
SMTP_PORT=
SMTP_USER=
SMTP_PASSWORD=

Values

MONOLITH_LICENSE_KEY

This is a license key that allows for your Monolith deployment to get licensing information from our online license server. Using this value ensures that your Monolith deployment always has up to date license info.

This key will be provided to you upon purchase.

MONOLITH_LICENSE_TOKEN

This is a signed token that contains licensing information for your Monolith purchase. This can be used to utilize cached license info without needed to query our licensing server for license info.

This is a good option for Monolith deployments that exist in air-gapped environments.

If this value is provided, Monolith will use this instead of the license key value.

ACCESS_TOKEN_SECRET

This should be a long alphanumeric string. This value is used for various cryptographic operations related to access tokens, encryption, and session management.

REFRESH_TOKEN_SECRET

This should be a long alphanumeric string. This value is used for various cryptographic operations related to access tokens, encryption, and session management.

MONOLITH_DB_NAME

This is the name of the MySQL schema that the Monolith API server should connect to.

MONOLITH_DB_HOST

This is the domain or IP address of the MySQL database host that the Monolith API server should connect to.

MONOLITH_DB_USER

This is the MySQL user name that should be used for database connections.

MONOLITH_DB_PORT

The port that should be used for database connections. The default MySQL port is 3306.

MONOLITH_DB_PASSWORD

MySQL password used to establish database connections.

MONOLITH_ADMIN_FIRST_NAME

First name of initial Monolith user. Only required for first time setup/deployment.

MONOLITH_ADMIN_LAST_NAME

Last name of initial Monolith user. Only required for first time setup/deployment.

MONOLITH_ADMIN_EMAIL

Email of initial Monolith user. Only required for first time setup/deployment.

MONOLITH_ADMIN_PASSWORD

Password of initial Monolith user - this will be used for firs time login to Monolith. Only required for first time setup/deployment.

FORM_TENANT_NAME

Initial tenant name for your Relay deployment. Only required for first time setup/deployment.

FORM_ORG_NAME

Organization name for your Relay deployment. Only required for first time setup/deployment.

FORM_TENANT_SLUG

URL slug for your Relay deployment. Only required for first time setup/deployment.

my-forensic-company

FORM_TENANT_EMAIL

Initial tenant email for your Relay deployment. Only required for first time setup/deployment.

API_INSTANCE_COUNT

The Monolith API server runs in "cluster" mode. This allows multiple instances to run at the same time, which increases scalability. This value defaults to 1 and is disabled by default. You will likely not need to use this value, but contact support if you think this is needed.

FILE_SERVICE

This value determines whether Monolith will use a local file system or Amazon S3 to store Monolith files. Allowed values are "S3" or "Local". The default value is "Local". If you set this to "S3", you will also need to set the S3 access key values.

AWS_ENDPOINT

This value configures Monolith to use the correct AWS region with your S3 bucket.

MONOLITH_FORMS_BUCKET

The S3 bucket where you would like to store files uploaded to Relay.

MONOLITH_CLOUD_BUCKET

The S3 bucket where you would like to store files uploaded to Monolith.

S3_ACCESS_KEY

AWS access key to use S3 APIs for file storage.

S3_SECRET_KEY

AWS secret key to use S3 APIs for file storage.

SMTP_HOST

Email host domain to enable email capabilities in Monolith.

SMTP_PORT

Email port to enable email capabilities in Monolith. This value is typically 587.

SMTP_USER

User value to enable email capabilities in Monolith. May not be required if you are using an SMTP relay.

SMTP_PASSWORD

User password to enable email capabilities in Monolith. May not be required if using an SMTP relay.

Windows

To Install Docker on Windows, you need to install Docker Desktop for Windows. This installer can be downloaded from here:

https://www.docker.com/products/docker-desktop/

WSL

To deploy Monolith on Windows, you will need to install the WSL package for Windows. This allows Windows to run Linux containers. During the Docker Desktop install, Docker typically prompts you to install this. If not, here is a direct link to download and install WSL:

https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi

MacOS

To Install Docker on MacOS, you need to install Docker Desktop for MacOS. This installer can be downloaded from here:

https://www.docker.com/products/docker-desktop/

Linux

To install Docker on a Linux OS, refer to the following Docker documentation for Linux installations:

https://docs.docker.com/engine/install/ubuntu/

Monolith On-premises deployments do not include a native backup solution.

The customer is responsible for creating and managing backups for data stored in the Monolith deployment.

The customer should set up a backup system that creates backups of the "data" folder maintained by the Monolith server. A backup solution for the MySQL Monolith database should also be implemented. The MySQL backup process should create something similar to SQL dumps of the databases stored by Monolith in MySQL.

This section will cover restoring a database backup of your Monolith MySQL database.

Backup Data

This restore process assumes you have previously created a SQL dump of your Monlith databse from MySQL. A SQL dump file is a plain text file that contains your database data in a SQL format.

Database Schemas

MySQL has a concept called "schemas". Schemas are the data segements within MySQL that store tables and data. You can have any number of schemas within a MySQL database. Your Monolith data is stored within a single schema within MySQL.

Schemas are the data object that we will backup and restore from backups.

Restore Steps

Recommended Tools:

• MySQL Workbench

  • This is a free tool provided by the MySQL team to access and manage MySQL databases. It also has several useful utilities including database backup and backup import services.

1. Open MySQL Workbench

2. Ensure that Workbench has a connection to your Monolith database.

3. Open your Monolith database in MySQL workbench.

4. Select "Server >> Data Import" from the Workbench menu bar.

5. The import wizard should start at the "Import from Disk" tab - select this tab if its not selected.

6. Under "Import Options", check the radio button for "Import from Self-Contained file".

7. Use the file select browser to locate and choose your Monolith database backup, which should have a ".sql" extension.

8. (Optional) Select a default target schema or create a new one.

   1. This is optional because your SQL dump file likely already has a directive to create a new schema with the correct name.

9. Click the "Start Import" button.

This process will create a new "schema" and populate it with tables and data from your Monolith database backup.

Setting up a custom domain for Monolith requires just a couple of item and steps:

1. Setup the domain that you want to use.

2. Create SSL certificates with any necessary intermediate certs that are required for the domain.

3. Add those SSL certificates to your Monolith deployment.

   1. Update the docker-compose.yml file

   2. Copy the SSL certs to your Monolith deployment folder.

Setting up a Custom Domain

This process will be different for everyone, but usually your IT department can establish a specific Domain for you to use to access your Monolith deployment in a web browser.

This is helpful because it allows you to use domain resolution in your browser instead of a plain IP address that points at your Monolith server.

This also lets you setup SSL that can be verified by your browser and create secure and encrypted web traffic between your Monolith users and the Monolith server.

Generating SSL certificates

Again, this process varies, but you will need to generate two SSL certificates that are associated with your custom domain. These certificate file comprise of a certificate file and a key file.

This is also a process that your IT department can help you with.

Update your docker-compose.yml

Before we can use the new SSL certificates, we need to update our Monolith deployment config so that it will override the built in self-signed certificates that Monolith uses by default.

Under the "nginx" block of the docker-compose.yml file, add the following line under "volumes":

./data/nginx/certs:/etc/nginx/certs

The entire "nginx" block should look like this:

  nginx:
    container_name: nginx
    image: monolithforensics/nginx:latest
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./data/logs/nginx:/var/log/nginx/
      - ./data/nginx/certs:/etc/nginx/certs

Rename the SSL certificates

When using custom SSL certs, Monolith is looking for certificates with specific names - rename your SSL certs to the following file names:

// Cert file
default_monolith.crt

// Key File
default_monolith.key

Copy SSL certs to Monolith Deployment Folder

Copy the SSL certs to "data" folder within your Monolith deployment, the final cert locations should look like this:

// Some code
{monolith-deployment-folder}/data/nginx/certs/default_monolith.crt
{monolith-deployment-folder}/data/nginx/certs/default_monolith.key

Re-deploy the Monolith Server

In order for Monolith to start using the new certs, we need to redeploy/restart the Monolith server so that it will indest the cert files.

Open a terminal or command prompt in the location of the docker-compose.yml file.

Enter the following commands, in order, to re-deploy and restart the Monolith server:

// shut down current deployment
docker compose down

// wait for process to complete

// Restart Monolith deployment
docker compose up -d

Conclusion

Now, Monolith will start using these certs and your custom domain to create a secure and encrypted connection between the server and your clients systems; both in the web browser and the Monolith desktop client.

Automatic Updates

If you have deployed Monolith with the Watchtower container, the Monolith API server, Monolith web app, and Relay web app will automatically update if the host system has internet access.

Watchtower checks for updates to these container every 30 seconds.

You may disable these automatic updates by simply removing the Watchtower container from your Monolith deployment.

Force an Update

If you don't want to wait for Watchtower or if you want to buld updates into a recurring script, you can force an update with a couple of commands.

The following commands use Docker compose to pull down the latest Monolith images, and rebuild the entire Monolith deployment with the new images.

## destroy currently running Monolith containers
docker compose down

## Pull latest images
docker compose pull

## Deploy Monolith containers with new images
docker compose up -d

You can imbed these commands within a bash or batch script if you would like to implement your own scheduled updates instead of using watchtower.

Manual Updates

You can also update the Monolith server containers manually. This can be useful in air-gapped environments or if you do not wish to deploy with automatic updates.

Download Latest Container Images

Run the following commands to download the latest container images for Monolith deployment or updates:

docker pull monolithforensics/nginx:latest
docker pull monolithforensics/monolith:on-prem 
docker pull monolithforensics/monolith-api:latest
docker pull monolithforensics/monolith-forms:on-prem
docker pull mysql:8.0.16

Export Container Images for Transfer

Run the following commands to export the container images to TAR files that can be transferred to the the host running the Monolith server:

docker image save -o monolithfornesics_nginx.tar monolithforensics/nginx:latest
docker image save -o monolithforensics_monolith.tar monolithforensics/monolith:on-prem
docker image save -o monolithforensics_monolith-api.tar monolithforensics/monolith-api:latest
docker image save -o monolithforensics_relay.tar monolithforensics/monolith-forms:on-prem
docker image save -o mysql_8.0.16.tar mysql:8.0.16

You can now transfer these TAR files to the host system that runs your Monolith deployment.

Import Container Images to Server

To import the TAR files, run the following commands on the host system that is using Docker to deploy the Monolith containers:

docker image load -i monolithfornesics_nginx.tar
docker image load -i monolithforensics_monolith.tar
docker image load -i monolithforensics_monolith-api.tar
docker image load -i monolithforensics_relay.tar
docker image load -i mysql_8.0.16.tar

Restart the Monolith Server

To restart Monolith with the new containers, run the following commands on your Monolith host and from the directory that includes your docker-compose.yml file:

docker compose down
docker compose up -d

Default Monolith deployments store files on the local file system of the host that is running Monolith's Docker containers.

If you want to use an external file share, you will need to adjust the docker-compose.yml file to include configuration settings for the file share you would like to use.

Windows/CIFS Share

To connect to a basic Windows file share, add the following configuration to the bottom of your docker-compose.yml file:

volumes:
  monolith:
    driver: local
    driver_opts:
      type: cifs
      o: "username=your_username,password=your_password,domain=your_domain"
      device: "//<SHARE_IP_ADDRESS>/share/data"

• Replace your_username, your_password, your_domain with the appropriate credentials for accessing the CIFS share. your_domain is not required if your share does not have a specific domain, so you can omit this value.

• Replace //<SHARE_IP_ADDRESS>/share with the network path to your CIFS share, but append the "/data" location at the end.

To utilize this new volume, we need adjust the current volumes listed in each service block of the docker-compose.yml file.

// Some code
monolith-api:
  container_name: monolith-api
  image: monolithforensics/monolith-api:latest
  restart: always
  volumes:
    - monolith:/usr/src/app/data
  ports:
    - "3001:3001"
  env_file:
    - .env
  mem_limit: 512m

Final docker-compose.yml File with CIFS

The following demonstrates the final docker-compose.yml file once a CIFS share has been configured:

services:
  monolith-api:
    container_name: monolith-api
    image: monolithforensics/monolith-api:latest
    restart: always
    volumes:
      - monolith:/usr/src/app/data
    ports:
      - "3001:3001"
    env_file:
      - .env
    mem_limit: 512m

  monolith-forms:
    container_name: monolith-forms
    image: monolithforensics/monolith-forms:on-prem
    restart: always
    volumes:
       - monolith:/usr/src/app/data
    ports:
      - "3003:3003"
    mem_limit: 150m

  monolith:
    container_name: monolith
    image: monolithforensics/monolith:on-prem
    restart: always
    volumes:
      - monolith:/usr/src/app/data
    ports:
      - "3005:3005"
    mem_limit: 150m

  mysql:
    container_name: mysql2
    image: mysql:8.0.16
    command: --default-authentication-plugin=mysql_native_password --sql_mode=""
    security_opt:
      - seccomp:unconfined
    restart: always
    ports:
     - "3307:3306"
    environment:
      MYSQL_ROOT_PASSWORD: ${MONOLITH_DB_PASSWORD}
      MYSQL_USER: ${MONOLITH_DB_USER}
      MYSQL_PASSWORD: ${MONOLITH_DB_PASSWORD}
      MYSQL_DATABASE: ${MONOLITH_DB_NAME}
    volumes:
      - ./data/mysql:/var/lib/mysql
      - ./init:/docker-entrypoint-initdb.d
    mem_limit: 512m

  nginx:
    container_name: nginx
    image: monolithforensics/nginx:latest
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
     - monolith:/usr/src/app/data

  watchtower:
    container_name: watchtower
    image: containrrr/watchtower:latest
    restart: always
    environment:
      - WATCHTOWER_CLEANUP=true
    command: --interval 30
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    mem_limit: 512m

# Connect CIFS share
volumes:
  monolith:
    driver_opts:
      type: cifs
      o: username={username},password={password},vers=3.0
      device: //192.168.1.12/Monolith/data

Default Deployment

Deploying Monolith with the default configuration is a simple matter.

1. Install Docker -

2. Pick a location to store your on-premises package files.

3. Open a command terminal.

4. Navigate to the location of your Monolith On-premises package files.

   • This is the folder that contains the .env and docker-compose.yml files.

5. Run the following command to download, deploy, and run the Monolith containers referenced in the docker-compose.yml file:

   • docker compose up -d

6. This will download the Monolith container images which may take a few minutes.

7. Once downloaded, the containers will launch and build the initial Monolith system.

8. You can then navigate to Monolith in a web browser using the IP address of the host system running Monolith:

   • https://{host_server_ip}

To remove the docker containers, you can use the following command:

docker compose down

Example

Once deployed, Monolith will store data in a folder called "data". This folder contains log files, files uploaded to Monolith, files uploaded to Relay, and database files generated by MySQL.

This data folder is important to maintain and create backups as the data that you store in Monolith will reside in this location.

When running MySQL in Docker or as a container, you may need to update the version of MySQL from time to time.

Ex: Update from MySQL 8.0.16 to 8.0.31 -

To update MySQL within Docker using Docker compose, you need to update your "docker-compose.yml" file.

1 - Edit "docker-compose.yml" file:

Find this line in the MySQL block:

image: mysql:8.0.16

Update the MySQL version in this line to the next version:

image: mysql:8.0.31

This will tell Docker which version of MySQL to use when deploying Monolith.

2 - Redeploy Monolith

Redeploy Monolith using the standard Docker compose command syntax:

docker compose down
docker compose up -d

This will stop the current Monolith deployment and restart it fresh containers. You should see the new version of MySQL download as a Docker image during this process.

Once redeployed, MySQL will go through a breif process of updating itself that may last a minute or two, so it may take a minute or two for Monolith to be available for use.

Conclusion

After completing steps 1 and 2, you should have a new version of MySQL installed and deployed for use with your Monolith deployment.

All of the standard tables in Monolith have several features to help users find and export data quickly.

Features

Sorting

To sort rows within a Monolith table, click the column header. Monolith will then sort the data based on that column.

Filtering

Column Resizing

Table columns can be resized by hovering over the edge of the column that you wish to resize. Then just click and drag the column to the desired width.

Column Reordering

Columns can be reordered by clic and dragging the column header to the desired position in the table.

Column Hiding/Showing

Columns can be hidden or shown by using the "Column Selector" which is a button that is typically located in the top right menu of a table. This button has an icon that looks like 3 vertical columns.

Pagination

Most tables in Monolith are "paginated" which means that only a certain number of records are loaded at one time. The default is 20, but you can use the page size selector to increase that amount to 100.

The table may also have a Page Selector that allows you to navigate to specific pages within the table data.

Searching

Table data may be searched if there is a search box associated with it. To search the table data, just enter your search string into the text box and press enter.

Exporting

Most tables can be exported to a Microsoft Excel document. to export the table data, use the table export button which is usually located in the top right table menu.

The table export is a "What you see is what you get" export, which means that the only columns and rows included in the export are based on the filters and table orientation.

All pages are included with the export.

The Query Filter is a system used throughout Monolith that allows you to create complex queries for data using a simple user interface.

The filter uses conditional logic to construct a query that will result in records that match the filter.

Example:

The above filter has three conditions:

• Open Date is sometime after January 1, 2023

• The Case Lead is Matt Danner

• The Case Type is Consultation

This filter combines those three conditions into an "exclusive" filter, which means that a record must match all three conditions. This can also be referred to as an "AND" statement:

"Show me all cases WHERE the open date is after January 1, 2023 AND the case lead is Matt Danner AND the case type is Consultation."

The query filter options are defined based on the type of records that your are filtering. So case data will have different filter options from evidence data.

Each condition within the filter may have different options as well.

The following condition filters are available"

• Date filters

• Text Filters

• Multi-select Filters

If a user's email has changed and you need to update it in Monolith, the change must be made directly in the Monolith database.

Here are the steps to make that change.

Install MySQL Workbench, open it, and create a connection to your Monolith database.

Open the Monolith database connection in MySQL workbench.

Navigate to your Monolith Database under the "schemas" tab and expand the schema and tables list. The Monolith db is usally called "monolith_db".

Scroll to the "users" table and open the table in Workbench to reveal the user records.

Find the user record that you want to update and click into that user's email column. Then type in the new email.

Click the "apply" button at the bottom right in Workbench, then click apply again in the confirm dialog that appears.

Once this is completed, the user's email has been updated and they can start logging into Monolith with that email address.

Watch the email update process:

To use an external database instead of using the MySQL Docker container that is included with the default Monolith deployment, just set the following values in the .env file to the connection details for your external MySQL database:

MONOLITH_DB_NAME=
MONOLITH_DB_USER=
MONOLITH_DB_PORT=
MONOLITH_DB_HOST=
MONOLITH_DB_PASSWORD=

Monolith works exclusively with DYMO printers to print labels. Here are printer model recommendations:

DYMO LabelWriter 550 Turbo

DYMO LabelWriter 5XL

Monolith supports integration with various hardware devices such as Signature pads, USB barcode scanners, and Dymo Label Printers

Monolith works well with USB based scanners. Here is the scanner we recommend to use with Monolith.

Tera Pro 8100 Wireless Barcode Scanner

This scanner conectst via Bluetooth or USB dongle, works with Windows and MacOS, scans barcodes and QR codes, and has several other useful features.

Using your DYMO Printer with Monolith

The first step of configuring your DYMO printer with Monolith is to ensure you have the latest DYMO software installed on the machine that is using Monolith.

Latest versions of the DYMO software can be downloaded here.

MacOS:

After install, ensure that the DYMO.WebAPI.Mac.Host software is running in your menu bar (it is a small blue DYMO connect icon on the menu bar on the top of your screen.

If it is not running, find "DYMO.WebAPI.Mac.Host" in your Applications folder and launch the program.

Once running, when you go to print labels in Monolith you will see your DYMO printer as an available printing option.

MacOS Troubleshooting Tips

When troubleshooting DYMO issues, we have found a complete uninstall and re-install fixes most issues. It's essential to remove all of the supporting files and certificates before re-installing the DYMO software.

How to uninstall all DYMO software from your Mac

1. Remove printer(s)

Open System Preferences > Printers & Scanners. Click the – button to remove the printer. (Do this for each DYMO printer shown)

1. Delete Application and Folder

• Go to your Applications folder and delete all instances of DYMO applications

• Open the Library/Extensions folder and Delete DYMOUsbPrinterClassDriver.kext, if found.

• Open the Library/Frameworks folder and Delete the DYMO folder, if found.

• Open the Library/LaunchAgents folder and Delete com.DYMO.dls.webservice.plist, if found.

• Open the Library/LaunchDaemons folder and Delete com.DYMO.pnpd.plist, if found.

• Open the Library/Printers folder and Delete the DYMO

1. Delete all DYMO Certificates from Keychain

• Open the Utilities folder (Finder>Go>Applications>Utilities)

• Double-Click Keychain Access to open keychain

• Type “DYMO” in the search field on the upper right

• Right-Click the certificate item (if found) and select Delete

• Type “localhost” in the search field on the upper right

• Click any item that appears and verify its properties show “issued by DYMO …” If so, then Right-Click and select Delete

After these steps are complete, re-install your DYMO software and try printing from Monolith.

Multi-Tenancy

All customers are assigned a Monolith "Tenant" - a tenant is a logical unit that separates every set of customer data into their own silos.

In Monolith, each customer is given thier own database and logical file storage area in our block storage. This means that data you enter into Monolith is not commingled with data from other customers.

The same idea applies to files uploaded into Monolith. Files stored in Monolith are stored in thier own logical silo based on the cutsomer tenant.

Data Export

This Multi-tenant infrastructure also means that it is very easy to get a copy of your data - just make a support request!

Encryption

All data stored in Monolith is encrypted at rest using AES-256 bit encryption algorithms. This includes data stored in databases, on servers, and in file object storage.

All data in transit to, from, or wihtin Monolith is also encrypted using HTTPS and TLS encryption standards/protocols.

While this data is encrypted, the encryption is controlled by us, which means a few select people from the Monolith team have access to customer data. This access is only granted for support and maintenance purposes.

Security Operations Policy

Monolith has an internal Security Operations Policy and Data Management Policy that covers our internal standards in more detail. If you would like to see it, please submit a request to support.

Cloud Hosting

Our Monolith infrastructure is currently hosted in AWS.

More specifically, we currently have 3 cloud infrastructure endpoints, which are all hosted on AWS: US East, London (UK), and Sydney (Australia)

Our United States endpoint is currently hosted in the AWS GovCloud East Region.

The AWS GovCloud infrastructure has some specific security policies in place that differs from normal AWS regions. These policies can be reviewed at the link below:

Data Backup

Database Backups

Monolith data within our databases is backed up every 24 hours. We keep a 30 days of backups which allows us to recover data from up to 30 days in the past.

We also typically create manual database backups for any major updates that require database maintenance.

These backups are stored in an encrypted format within a separate region from the current database. This allows for recovery of data in the event of an AWS region outage.

File Object Storage Backups

Files uploaded to our Object Storage system implement typical object storage versioning. This means that a deleted file can be recovered by restoring one of its versions. A new file version is created and stored in the event of a file overwrite, which can occur when a file with the same name and path of another file is uplaoded.

These file versions are kept for up to 90 days after deletion.

Basic Cloud Infrastructure

The following diagram illustrates the basic cloud infrastructure of the Monolith cloud environment. This is just an illustration to show how nodes communicate and share data/information:

Vulnerability Scans

The Monolith cloud infrastructure has network and system level scans that occur every 24 hours to test for network and system vulnerabilities. These scans produce reports that can be review for any issues or characteristics that are not inline with our security baseline.

A/V - Malware Detection

All of our endpoints, including employee systems, are monitored using Crowdstrike Falcon. This provides continious 24/7 monitoring of our endpoints for threat detetion and allows for immediate remediation.

Penetration Testing

We conduct annual pentests of Monolith that test for common infrastructure vulnerabilities, configuration issues, and application vulnerabilities. These pentests are conducted by an independent 3rd party. The testing targets our development and staging environments and not the customer facing production system to avoid interrupting services and prevent any potential access to customer data.

Customer may request a copy of our latest pen test reports by contacting support at support@monolithforensics.com

Logging

Various system logs are currently managed by logging services within AWS and Datadog. These logs are currently aggregated within Datadog, which allows for periodic review.

What is Single Sign On (SSO)

Single sign on is an authentication process that allows a user to log into Monolith using thier organization's authentication mechanism and identity management system. This authentication process is used in place of Monolith's default login system.

For example, if configured, a user may login into Monolith using Microsoft Azure AD credentials instead of using the default Monolith user credentials.

SAML 2.0

SSO integration with Monolith uses the SAML 2.0 open standard to connect to your identity provider.

Identity Provider/Service Provider

Identity and service provider are common terms used when configuring an SSO connection. The identity provider is the service your organization uses to manage it's employees' credentials to provide access to IT resources.

The service provider is the vendor or software that relies on the identiity provider ro authentication and identification.

In this case, Monolith is the service provider.

What about Multi-Factor Authentication (MFA)?

When logging in with SSO, the Monolith MFA process is not used - MFA is passed onto the identity provider that is used in the SSO process.

SSO Sessions

When a user authenticates into Monolith via SSO, a Monolith session is created that matches our default session standards.

SSO Setup and Configuration

To integrate SSO with Monolith, you must have purchased an Enterrpise license to Monolith.

In order to setup SSO with Monolith, your organization should provide a SAML metadata file that is in XML format. This metadata file will contain specific information related to the SSO connection with Monolith that we need for integration.

Monolith will then provide your organization with 2 key pieces of information to complete the SSO connection:

ACS URL:

https://monolith-app.monolithforensics.com/api/auth/saml/acs/{{UNIQUE ORG ID}}

Service Provider Entity ID:

https://monolith-app.monolithforensics.com/{{UNIQUE ORG ID}}

These values are used by your identity provider to create an SSO connection with Monolith.

Metadata Attributes

In order for Monolith to properly identify the user after SSO authentication, we need the user's email to be included with the SAML response.

This is typically included as a "NameID", but may also be added as an "email" attribute.

Support

To setup SSO with your Monolith account, please contact support: support@monolithforensics.com

Monolith can be integrated with Topaz Signature tablets.

Current Tested and supported models:

• Topaz T-S460-HSB-R model signature pad

Tablet Setup:

You must install the Topaz SigWeb software on the host system to use this feature. You can download the software from the Topaz website: https://topazsystems.com/sdks/sigweb.html

Standard Monolith Report

This is an example of the standard report that Monolith has generated automatically. This is the templated form. It contains examples of how to use template variables, loop syntax, tables, and evidence photos.

Monolith allows you to make use of report templates, so you can create any reports you wish based on data within a Monolith case.

Template Document

The template document must be a Microsoft Word document (DOCX).

Template Syntax

In order to use a template, you must insert placeholders that Monolith recognizes as case variables that can be replaced with case data:

Standard Variable:

Here is standard syntax for inserting basic values into a template -

{{ variable }}

Ex: {{ case.case_number }}

Please ensure that there is a space at the start and end of the variable name.

At the time of report generation, Monolith will replace this template variable with the chosen data from the case:

// Example Template Data in docx file
This case was issued case number "{{ case.case_number }}".

// Resulting document data in generated report
THis case was issued case number "MF-22-1985".

Lists and Loops

Some data in a Monolith case consists of a list of items. For example, you may want to reference data from evidence items associated with a case. You may have ten evidence items in a case and you want that evidence data to be included in your templated report.

To do this, we need to use some special syntax to loop through the list of evidence items and output each item's data into the template report.

Here is the basic syntax to loop through a list of items in a template document:

{% for item in evidence %}
{{ item.evidence_number }}
{% endfor %}

The above syntax will loop through a list of evidence items (stored in the "evidence" variable} and output a vertical list of evidence numbers.

// Here is a basic evidence list variable example:
// evidence = [{evidence_number: "1234"}, {evidence_number: "45689"}]

Example 1: Vertical list of evidence numbers - 

// template syntax for a loop
{% for item in evidence %}
{{ item.evidence_number }}
{% endfor %}

// The above syntax will result in the following document output:
1234
45689

Example 2: Horizontal list of evidence numbers - 
// template syntax for a loop
{% for item in evidence %}{{ item.evidence_number }} {% endfor %}

// The above syntax will result in the following document output:
1234 45689

Loops are a very powerful way to create complex report templates and display just about any data that you want.

Table Rows

There is special syntax used to iterate through table rows - similar to the looping syntax above, you may want to iterate through a list and create table rows with data.

Lets create a table that contains rows for each evidence item and columns for the evidence number and evidence provider (manufacturer, make, etc...)

Given the following evidence data passed to the template from a case:

[
    {
        evidence_number: "1234", 
        manufacturer: "Apple"
    },
    {
        evidence_number: "45689", 
        manufacturer: "Dell"
    }
]

Template Syntax for table -

Generated Document Result -

The "tr" prefix denotes that we are creating a loop through table rows.

You'll notice that the table rows that have the start loop syntax and end loop syntax are not included in the final rendered table.

Using this syntax you can create tables with templated lists pulled in from Monolith.

Other Template Syntax

There is more syntax available for templates, but the item listed about are the most common. If you need help with this or have more questions, reach out to us at support@monolithforensics.com.

What are storage items?

In Monolith, storage items are considered to be devices that are used for the purpose of storing forensic data that has either been collected, processed, or provided.

Examples of storage devices include:

• External Hard Drives

• USB Drives

• Network Attached Storage devices

• FTP Servers

• Cloud Storage Systems (AWS, Google Drive, etc...)

Examples of stored data include:

• Forensic Images

• Smartphone Extractions

• Case Data

• Forensic Reports

What is the difference between Evidence Items and Storage Items?

First, everything in Monolith is considered evidence, but for the puposes of organization and management Monolith tracks evidence and storage items separately.

Evidence typically represents the original source of forenisc evidence or data. Usually, this includes hard assets like smartphones or laptops and soft assets like email or cloud accounts. You should track anything that is considered as the original or "best" evidence as an evidence item.

Storage represents the vessel that collected forensic data is stored on. So when tracking storage items in Monolith, you are essentially tracking all the device you use to store forensic data.

What is a "General" storage item?

Monolith tracks two categories of storage items: "General" and "Assigned".

General storage items are meant to represent large storage arrays that are used as a permenant cache for all case data. This is typically a NAS array that stores pristine copies of all your case data and forensic images. It is also a fixed asset that usually stays in the lab and does not move.

Assigned storage items represent storage that is associated with a specific case and stored very specific data. These devices are usually smaller and portable devices that move around a lot and may even be wiped, destroyed, or recycled at the end of a case or matter.

General Item Rules:

• Cannot be assigned to a case.

• Monolith does not track chain of custody for these items.

• Tracks data from multiple cases.

Assigned Item Rules:

• Must be assigned to a case to use.

• Can only track data from one case.

• Chain of custody is only logged when assigned to a case.

• Can be removed from a case and reused/re-assigned.

• Removing from a case will destroy its chain of custody and unlink any tracked acquisitions.

Assigning Storage Items

There are two ways to assign a storage item to a case: Create or Assign.

Create an Item

You an create a storage item from the "Storage Items" tab of a case. This will both create the new item and assign it to the case at the same time.

Assign an Item

You can also assign a storage item that already exists to the current case. This option is available in the "Storage Items" tab of a case and in the "Actions" menu as shown in the screenshot below.

Case Report Variables

These variables represent data contained within a report instance of a case.

Organization Variables

These are template variables that reference your organization information entered into Monolith.

Current User Variables

These are variables that reference the currently logged in Monolith user.

Case Variables

These are variables that contain data related to the current case you are generated a report for.

Evidence Variables

These are variables that contain data related to evidence items within a case.

Remember - the evidence object within a template is a list of evidence items. To use this data in a template, The values must be inside a loop:

Example:
{% for item in evidence %}
{{ item.evidence_id }}
{% endfor %}

Chain of Custody Variables

The chain of custody records for an evidence item can be accessed by using the {{ item.coc }} variable listed above. The example below shows how to access COC records for each evidence item:

Chain of Custody Example:

// Loop through evidence items
{% for item in evidence %}

    // Loop through evidence item COC records
    {% for record in item.coc %}
    
        // Output COC record details
        {{ record.type }}
        {{ record.custody_to }}
        {{ record.custody_from }}
        {{ record.timestamp }}
        {{ record.reason }}
        
    // End loop for COC records
    {% endfor %}
    
// End loop for evidence items
{% endfor %}

Acquisition Variables

These are variables that contain data related to acquisition items within a case.

Remember - the acquisitions object within a template is a list of acquisition records. To use this data in a template, The values must be inside a loop:

Example:
{% for item in acquisitions %}
{{ item.acquisition_id }}
{% endfor %}

Each of the status tabs can be used to navigate through the items being audited.

How to Audit an Item

Auditing an item typically involves at least two procedures:

Verifying the item location

One type of audit requires the auditor to compare the location of the item listed in Monolith with its actual location in the forensic lab or designated evidence storage.

For Example, consider the following item:

According to Monolith, this item is currently located within the Calgary office, at the Evidence Room group, and at the AAA location.

Verify the location by finding the physical item in your posession and check if its actual location in reality matches the location recorded in Monolith.

Verifying the item's details

The other type of audit requires the auditor to verify all the item's details and not just the location. This type of audit requires more work but can be useful in maintaining accurate data in your Monolith database.

Audit Procedure

Failing an audit item

If the item's location or other details are incorrect, use the status selector of the item to mark it as "Failed". This will open a meu where you can enter a note about why the item failed.

You can then fix the item right away by updating the location or details in Monolith, or you can wait until you have audited all items first.

Once the status update is submitted, the audit item card is moved to the "Failed" tab.

Passing an audit item

If you determine that the details and location of the item are correct, you can then mark the item as having passed its audit.

This may also occur after you have failed the item and then updated the item with accurate information.

The process to pass an item is identical to failing an item. You simply update its status to "Passed" and enter a note about why it passed.

Audit methods

When updating an audit item's status, the audit method will update whenever you pass or fail an item.

The audit methods currently used are "Manual" and "Scanned". Using the status selector to update the item's status will set the audit method to "Manual" as it represent that the auditor manually passed or failed the item without using a scanner.

The "Scanned" method is discussed in more detail here: Using a scanner

Audit logs

The audit logs record each time and audit item's status is updated. These logs include a timestamp, auditor, and the notes entered at the time of audit.

These logs can be used for documentation or to keep track of why items did not pass an audit and then repair the items as needed.

The audit logs can also be viewed within the audit items detail's page.

Here is an example of the audit logs from this evidence items details page:

Client Details

On the left hand side of the clients page you can view and edit all of the details associated with your client.

Printing Labels

At the top of the client details section you can also print labels using the information in client details

Associated Cases

You can also see a table view all of the cases associated with this client in two views:

My Associated Cases: Cases associated with this client that you are assigned as a user.

All Associated Cases: Administrator view for all cases associated with this client.

Delete Client

Administrators can also delete a client from the client page.

In this section you can see a list of all clients associated with your organization in a table view.

Create Client

From this view you can also create new clients by clicking the "New Client" button above the clients table.

Navigation Tabs

The main audit view contains two tabs for navigation.

Audit Items - This is where the audit process takes place and contains the audit details and items.

Audit Logs - Contains a table of logs related to auditing items.

Audit Overview

This sub-tab contains the details about the audit you are viewing.

This section shows you the current status of the audit, "Open" or "Complete", along with other details such as the audit due date, assignment, and filter used to select the audit items.

Other Sub-tabs

The remaining tabs: All, Pending, Passed, & Failed, list the audit items included with the audit. The items are group by thier current status.

These tabs are used when conducting the audit process.

Audits in Monolith can be viewed by clicking the "Audits" section in the Monolith sidebar under "Evidence Management".

Within the "Audits" section, audits are listed in a standard Monolith table.

An audits can be viewed and accessed by clicking the name of an audit within the table, which should be highlighted as a blue navigation link.

Create a new audit

Use the "+ New Audit" button to begin creating a new audit.

The above screenshot shows the Audit Creation Menu:

1. Audit Name - This is the name of the audit, enter something simple and descriptive of the audit.

2. Assignee - This is the Monolith User/Person that will be assigned to run or administer the audit.

3. Start Date - This is anticipated start date of the audit.

4. Due Date - This is the expected due date of the audit.

5. Item Type - Select the type of items that will be included in this audit. Currently only Evidence and Storage items can be selected. You can only select one option.

6. Description - Provide a detailed description of the audit so that other users will know what this audit is for.

7. Cancel - Closes the menu and cancels the audit creation process.

8. Create Audit - Submits the completed form and creates a new audit with the supplied parameters.

Using the Audit Creation Filter

When conducted an audit of items your organization is tracking, you will likely only want to audit a subset of all the items in Monolith. For example, you may only want to audit items from a specific year or quarter, or items of a specific type or location. The audit filter allows you to do this.

Upon making a selection within the "Item Type" field, a new section within the audit creation menu will appear:

This filter will match the query filter you have seen in the Evidence and Storage items tables. Depending on the item type you selected, the filter will contain fields for either evidence or storage items.

You can apply any filters that you want, and this will dictate which items will be included in the audit you are creating.

The example filter below will include any evidence items that are "Smartphones" and were created in 2023:

Upon clicking the "Create Audit" button, the audit will be created and will appear in the audit table:

As you can see in the screenshot above, this audit includes 29 evidence items based on the filter that was applied.

Lab Management options allow you to manage lab equipment and software subscriptions for your forensic lab.

The Forensic Software table allows you to manage your software subscriptions including tracking details like purchase date, expire date, and cost. From this view you can also export the details of this table to an excel document.

Exporting to Excel

Your equipment list to an excel document by selecting the Download option from the table menu.

All of the columns you have selected in your table view will be shown in your exported excel document.

Add Software Item

You can add new software to your list by clicking the "New Software" button from the table view.

You can include details such as Vendor, Edition, Purchase Date, Expire Date, Cost, and Location.

Edit Software Item

You can also edit all of the details of your software items by opening a flyout menu from the table view.

Delete Software Item

From the flyout menu you can delete Software Items.

In this section you can add additional details to your organization's profile including name, address details, contact information, and website.

Here you are also able to change the default Monolith logo to the logo of your organization.

The Equipment table allows you to manage your lab equipment including purchase date, costs, and locations. From this table you can also export the details of this table to an excel document.

Exporting to Excel

Your equipment list to an excel document by selecting the Download option from the table menu.

All of the columns you have selected in your table view will be shown in your exported excel document.

Add Equipment Item

You can add new equipment to your list by clicking the "New Equipment" button from the table view.

You can include details such as Vendor, Model, Serial Number, Purchase Date, Cost, and Location.

Edit Equipment Item

You can also edit all of the details of your equipment items by opening a flyout menu from the table view.

Delete Equipment Item

From the flyout menu you can delete Equipment Items.

Monolith supports email notifications for assignments of tasks and cases.

Create and Manage Relay users

Relay can be used by any internal or external party interacting with your lab. Relay users do not need to be Monolith users and they do not require a Monolith user license. There is no limit to the number of Relay users you create.

Your Relay Users

You can view, invite, and search for current users from this view.

Editing and Removing Relay Users

By selecting a user from this screen you can edit that user's details, remove that user from your Relay Tenant, and grant or remove admin permissions for that user.

Inviting New Users

You can invite new users by selecting the "Invite User" button from the "Relay Users" table. You will be prompted to enter that user's email address.

Below is an example of an email invite to relay.

User Account Set Up

After accepting an invite users will be directed to register as a Relay user. An invitee must set up their account to access Relay.

View Pending Invite Requests

From the Access Requests tab, you can view all of your pending Relay user invites. They will remain pending until the invitee completes the user registration process.

Configuring your Relay Tenant

The Relay settings page has 4 tabs: Basic Details, User Management, Instructions, and Custom Field Options.

Coming Soon

In this section you can configure the details that your Relay Tenant will display to users.

Basic Details Items

Tenant Logo: Select the logo that will display in Relay

Tenant Name: Name that will display for your organization in Relay

Relay URL slug: The URL identifier for your relay tenant. For example, if we use the slug "my-relay-slug" the Relay URL will be:

https://relay-app.monolithforensics.com/my-relay-slug

Tentant Email: The default email for your relay tenant. All notifications from Relay (new users, request, etc...) will be sent the this email.

Basic Details View

In this section you can edit instructions that will be shown to the requester before they make any requests in Relay.

Account Information

Organization profile: Information can be changed in the Organization Info section.

Subscription Info: This section gives details about your licenses, subscription expiration date and storage usage. In this view you can also see your relay URL and current workspaces connected to your account.

Desktop Installers

If you would like to use Monolith as a desktop application, it can be downloaded from this section. We currently offer desktop applications for Windows and MacOS.

Date, Time, and Currency Format

Your selected format options will appear as the default throughout Monolith.

In this section, Monolith allows you to customize your Case number, Evidence number, and Storage number format.

Adding Labels

Click the "Add Label" button to upload a .dymo label file Monolith.

Working with Variables

Monolith fields for your organization's info (set in Organization Info), Evidence, Storage, People (Clients and Contacts) can be used as variables for custom DYMO labels.

Audits allow your team to reconcile physical items under your control with their digital references in Monolith.

You can create audits to check and verify the locations and details of items currently recorded within your Monolith database.

In this section you can view all of the Case Statuses associated with your organization. This is also where you can create new Case Statuses and delete your current Case Statuses.

Creating a New Case Status

Select the "Create Case Status" button and enter the name of the Case Status you would like to create.

Delete a Case Status

You can also delete Case Statuses from this section.

In this section you can view all of the Case Types associated with your organization. This is also where you can create new Case Types and delete your current Case Types.

Creating a New Case Type

Select the "Create Case Type" button and enter the name of the Case Type you would like to create.

Delete a Case Type

You can also delete Case Types from the Case Types Section.

Every Evidence Item in Monolith has a progress bar that illustrates the current stage of a particular evidence item. See also Case Progress.

The current progress status for an evidence item can also be found under the Evidence Details section on the left sidebar of that item's page.

In the Evidence Progress section you can reorder, add, and delete these evidence progress options to best reflect your organization's workflow.

Reordering Evidence Progress Items

You can reorder your current Evidence Progress Items by dragging and dropping them into place. Your timeline will display the order of items going from top to bottom.

Create New Progress Item

Select the "Create Evidence Progress" button to create a new progress item. By default, this item will be added to the beginning of the list.

Delete a Progress Item

Select the Delete button to the right of the item you would like to delete.

Every case in Monolith has a progress bar that illustrates the current stage of a case. See also Evidence Progress.

In the Case Progress section you can reorder, add, and delete these case progress options to best reflect your organization's workflow.

Reordering Case Progress Items

In this section you can reorder your current Case Progress Items by dragging and dropping them into place. Your timeline will display the order of items from going from top to bottom.

Create New Progress Item

Select the "Create Case Progress" button to create a new progress item. By default, this item will be added to the end of the list.

Delete a Progress Item

Select the Delete button to the right of the item you would like to delete.

In this section you can view all of the Evidence Types associated with your organization. This is also where you can create new Evidence Types and delete your current Evidence Types.

Creating a New Evidence Type

Select the "Create Evidence Type" button and enter the name of the Evidence Type you would like to create.

Delete an Evidence Type

You can also delete Evidence Types from the Evidence Types Section.

Custom Field Settings

From the custom fields section you can create, edit, delete, and enable custom fields for your Monolith tenant. Monolith currently supports custom field items for: Cases, Evidence, Acquisitions, Inquiries and Storage.

Adding Custom Fields

Open the collapsable section for the category of custom field you would like to create (for example Custom Cases Fields).

Creating Custom Fields Options

1. Field Name (Required): The display name of your custom field

2. Is Required (Required): A yes/no option to indicate whether this should be a required field in Create and Edit modals for this category.

3. Editor Type(Required): Select whether you want this field to be:

   • Textbox - Regular text field

   • Date - Provides a date selector dropdown

   • Drop Down Menu - User's can select an item from a dropdown list

   • Tag Box - User's can select multiple items from a dropdown list

4. Description: Populates placeholder text in the input box associated with your custom field in the category's Create and Edit modals.

Managing Custom Fields

• Enable/Disable: Determines if custom field will appear in Create and Edit Modals.

• Edit: Edit custom field details.

• Delete: Removes the field and its values from your Monolith tenant.

Re-Order Custom Fields

Each category's custom field sections can be re-ordered by dragging and dropping custom field components within their respective lists.

In this section you can view all of the Time Entry Categories associated with your organization. This is also where you can create new Time Entry Categories and delete current Time Entry Categories.

These categories can help define the type of work conducted when recording billable time entries.

Creating a New Time Entry Category

Select the "Create Category" button and enter the name of the Time Entry Category you would like to create.

Delete a Time Entry Category

You can also delete a Time Entry Category from the Time Entry Categories Section.

In this section, you can manage your QA Issue Types to identify events that do not meet your organization's quality assurance standards.

Creating a New QA Issue Type

Select the "Create Type" button and enter the name of the QA Issue Type you would like to create.

Delete a QA Issue Type

You can also delete a QA issue type in this section.

Users with administrative access will be able to view a log of user activity throughout the Monolith application.

Features

The Admin Log table offers robust sort and filter functionality.

Total Logs: The total number of logs can be found to the right of the filter button at the top of the table.

Filters: Admin logs can be filtered by Timestamp, User, and/or Admin log

Search: Admin logs can also be searched to quickly find specific items

You can find more on filtering, searching, and customizing views in our Tables UI documentation.

In order to submit an authenticated API request to the Monolith API, you need to include an API key in the following header value with the request.

X-API-KEY

This header must be present in all Monolith API HTTP requests and have a value that is a valid Monolith API key.

The Monolith API is still under development, so if you would like access, please reach out to support to request an API key.

Example API Request

Use the "info" endpoint to get details related to your API key. This example shows how to make a simple API request to Monolith using an API key in the headers of the request.

import requests

# set your Monolith API key into a variable
api_key = "qucuqwqg5q3rve28ehfh" # this is a fake API key

# Set the api key in the header of the request
headers = {
	"x-api-key": api_key
}

# Use the appropriate API endpoint for your region
api_url = f"https://monolith-app.monolithforensics.com/v1/info"

# Execute the GET request
response = requests.get(api_url, headers=headers)

# print the JSON response to console
print(response.json())

This endpoint retrieves basic details about your Monolith tenant and the API key currently being used.

Get Info

GET /api/v1/info

This endpoint retrieves basic details about your Monolith tenant and the API key currently being used.

No parameters are required for this API.

Response

{
    "message": "Monolith API is running",
    "success": true,
    "user": {
        "name": "John McClain",
        "email": "jmcclain@diehard.com",
        "title": "Detective",
        "user_id": 1,
        "last_name": "McClain",
        "first_name": "John",
        "monolith_tenant": "tenant_123abc345"
    }
}

{
  "error": "Invalid request"
}

Get Cases

GET /api/v1/cases/:uuid?

Retrieve a list of cases from your Monolith database.

Path Parameters

Query Parameters

This section describes the basic access requirements for using the Monolith REST API via HTTPS.

Monolith will including integrations in future releases. As of now, we offer integrations for organizations issuing reports to the US Secret Service.

Forensic Partner Reports

Click the "Configure" button to allow you to map Evidence Types and Case Types to your report.

Create a Case

POST /api/v1/cases

Create a new case in Monolith

Request Body

Monolith allows you to enable Custom Fields for Inquiry and Evidence Items for Relay users making request. Once a field is enabled, it is viewable by all Relay requesters.

Custom Inquiry Fields: Allows Relay requesters to provide additional inquiry details with their request

Custom Evidence Fields: Allows users to provide additional details about evidence items associated with their request.

Create a new evidence item

POST /api/v1/evidence

Use this API endpoint to create evidence items within Monolith.

Either case_id, case_uuid, or case_number is required.

If evidence_number is not provided, Monolith will automatically generate a value.

Request Body

Custom Fields

To create custom fields for your evidence in an API request, you must include a custom_fields value that consists of an array of JSON objects in the following form:

The field_id is the numeric identifier for the custom field you are setting a value for.

// Custom Fields Example
"custom_fields": [
    {
        "field_id": "1",
        "value": "I am some custom data."
    },
    {
        "field_id": "2",
        "value": "This is some separate custom field data."
    }
]

Get Evidence

GET /api/v1/evidence/:uuid?

Retrieves a list of evidence items. Calling with no parameters returns a paginated list of all evidence items in your Monolith database. Use the uuid query param to get details for one item or use the case_uuid param to get a list of evidence items for one Monolith case.

Query Params

Delete a current evidence item

DELETE /api/v1/evidence/:uuid?

Use this API endpoint to delete evidence items within Monolith.

Request Body

GET /api/v1/locations/:location_id?

Retrieve a list of locations from your Monolith tenant.

Path Parameters

Example Response Body

{
    data: [
        {
            "location_id": 1,
            "name": "Released",
            "type": "Released",
            "is_parent": 0,
            "parent": null,
            "office": {
                "name": "Austin",
                "office_id": 1
            }
        },
        {
            "location_id": 2,
            "name": "Evidence Cage",
            "type": "Team",
            "is_parent": 1,
            "parent": null,
            "office": {
                "name": "Austin",
                "office_id": 1
            }
        },
        {
            "location_id": 3,
            "name": "Matt Danner",
            "type": "User",
            "is_parent": 0,
            "parent": {
                "name": "Evidence Cage",
                "location_id": 2
            },
            "office": {
                "name": "Austin",
                "office_id": 9
            }
        },
        {
            "location_id": 4,
            "name": "Rick Sanchez",
            "type": "User",
            "is_parent": 0,
            "parent": {
                "name": "Evidence Cage",
                "location_id": 2
            },
            "office": {
                "name": "Austin",
                "office_id": 1
            }
        }
    ]
}

Migrate evidence items to a different case

POST /api/v1/evidence/migrate

Use this API endpoint to migrated chosen evidence items from one case to another.

Request Body

Use this API to manage evidence and storage locations within Monolith.

Update a current evidence item

PUT /api/v1/evidence/:uuid?

Use this API endpoint to update evidence items within Monolith.

Request Body