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.
This Multi-tenant infrastructure also means that it is very easy to get a copy of your data - just make a support request!
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.
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.
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:
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.
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.
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:
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.
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.
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
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.
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.
SSO integration with Monolith uses the SAML 2.0 open standard to connect to your identity 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.
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.
When a user authenticates into Monolith via SSO, a Monolith session is created that matches our default session standards.
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.
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.
To setup SSO with your Monolith account, please contact support: support@monolithforensics.com