TheHive Reloaded: 4.1.0 is out

We are proud and excited to annonce the availability of TheHive v4.1.0. This release is the new beginning of TheHive’s future, because all the upcoming features and enhancements will be based on this version, without the brakes.

4.1.0 is out after a significant work done during the last 6 months, interrupted by multiple events like:

supporting ES 7 in TheHive 3 and Cortex
supporting ES 7.11 in TheHive 3 and Cortex
5 patch releases of TheHive 4.0
recent OVH datacenter incident (but this one was quickly fixed)

Our community is waiting for it, as we announced it will fix the performance issues that many of you were facing. The reason is that TheHive 4.0.x doesn’t include a database indexation component resulting on poor data fetching performance.

We are glad about this release, it includes tons of new features and improvements, across all the application.

The first and maybe, the main one, is the database indexation (#1731) that will significantly improve performance of queries such as lists, filters and sorting. As a consequence, you should experience a smoother browsing and usage of the application.

Amongst all other news features, we introduced:

Support for MISP taxonomies, in addition to custom tags and tag colour support;
Support for Case TTPs specified by MITRE ATT&CK framework;
Better and improved Case merging and deleting capabilities;
A customisable date and time format
A refined Case Templates management UI
Enhanced Case list UI with bulk actions
Enhanced Task list UI with bulk actions
A platform status page to get an overview of the platform health
Support for migration from TheHive 3.5.1 to 4.1
Support for authentication on Webhook endpoints

For those of you who want to know the full details, here is the change log

A word about the documentation

As you might know, TheHive has a documentation repository that includes content for TheHive 3 and TheHive 4, but the structure needs to be redefined. For that reason, we introduced a new documentation website that aims to be the single starting point of all the docs we produce for TheHive Projects’ products.

In the upcoming days, we will mark the old docs repositories as ARCHIVED and we will maintain the new docs repository.

To visit the new documentation website, go to
https://docs.thehive-project.org

More about the new features

Database indexation

Until now, we knew TheHive suffered from a performance issue with the database.

Technically, TheHive uses basic index mechanism embedded in JanusGraph. This indexes are simple to use and manage but they contain limitations. They only support equality lookups and cannot be used for sort (for example, this is not possible to simply look for cases with severity > LOW) . However, within TheHive, almost all lists – lists of cases, lists of alerts, tasks …- are sorted. So, getting a list means a scan of all the elements of the list, which have a heavy performance impact, particularly if the list is long.

In order to solve this issue, TheHive 4.1.0 comes with a new index engine, and indexes have to be stored outside the database. As a consequence you need to define and setup dedicated storage for these indexes.

If TheHive is used in a cluster mode, all servers must connect to a common index engine, which can be in a cluster mode or not. In this case, a new component must be installed for index management. Elasticsearch should be used, only as an index engine. For clusters, Elasticsearch is not used like it was with TheHive 3.x when it stored data.

If TheHive is used on a standalone server, Elasticsearch can be used, but a file based index engine – Lucene – can be preferred. The latter solution has less infrastructure impact – no component to install – and only requires configuration that indicate where index data is stored in the filesystem.

For more details about database indexing configuration, please refer to the documentation

MISP taxonomies support

TheHive 4 handles tags in a completely different way than TheHive 3, even if the APIs are still considering tags as simple strings. For example when you create a Case from TheHiv4py, you specify tags as a simple array of strings.

Behind the scene, TheHive transforms the tags into objects, with a namespace, a predicate and an empty value. For example if your create a case with a free tag src=mailbox, TheHive 4 creates a new Tag object as following:

{
    "namespace": "_freetag",
    "predicate": "src=mailbox",
    "value": null,
    "colour": "DEFAULT_COLOUR_FROM_THE_CONFIG"
}

This is where we introduced the support of MISP Taxonomies, allowing admin users with `manageTaxonomy` permission, to import tags defined in machinetag.json format, from the “Administration > Taxonomies page”

Note: importing the full MISP taxonomies library can take some time (1 minute)

Once imported, you need to enable the taxonomies you need for use cases. All the taxonomies are disables by default. Enabling a taxonomy, make its tags available to all the organisations on the platform, so analysts can use the to tag Cases, Alerts, Observables.

Taxonomy tags can also bee used from any tag filter in Case, Alert and Observable lists:

Custom tags support

Custom tags or free tags, is the way we call free text tags associated with TheHive objects. Internally, custom tags are included into organisation related spécial taxonomy called `freetags`.

Custom tags are not shared across organisations, so existing users defining sensitive data in tags won’t suffer any data leakage issue.

In general, custom tags in TheHive are not supposed to user data and information. It’s not a best practice to use email adresses as tags. Custom fields are the right place for this type of data.
This topic needs a dedicated blog post, to share the best practices of using tags.

So, how do an org admin manage the custom tags? Well, TheHive 4.1 comes with a new UI section, under the organisation management page, allowing:

Listing all the custom tags
Filtering and sorting
Updating custom tag values and colours
Deleting custom tags
Displaying custom tag usage (# of cases, # of alerts, # of observables and # of case templates)

For users migrating from TheHive 3, all the existing tags are imported as custom tags

Tactics, Techniques & Procedures, with MITRE ATT&CK

Supporting MITRE ATT&CK framework is one of the feature that has been postponed many time from TheHive. It’s a no brainer feature that any blue team oriented product must include.

In TheHive 4.1, we allow:

Importing the official MITRE ATT&CK attack patterns collection as defined in https://github.com/mitre/cti. In this version support the entreprise catalog, but the future goal is to allow managing multiple catalogs in a misp-galaxy-like manner.
Defining TTPs associated with TheHive Cases

Attack Pattern management

From the administration page, any user with managePattern permission is able to have access to a page where patterns can be imported, filtered, viewed.

Case TTPs

In addition to Tasks and Observables, in TheHive 4.1, you can associated TTPs to your Cases. TTPs objects are defined by:

A tactic
A technique or sub-technique
An occur date
An optional procedure description

The Case TTPs are displayed in a dedicated tab on the Case details page, the same way as Tasks and Observables, with filtering and sorting capabilities.

List of TTPs *published in the report* “SANDWORM INTRUSION SET
CAMPAIGN TARGETING
CENTREON SYSTEMS” by CERT-FR

This screenshot, showcases the tactic colours we use, thanks to Paul Tol’s blogpos t

Case list TTP related improvements

One more feature: Case list now show the number of TTPs associated with each Case, with a link to the TTPs list page.

Customise date and time

Since the very beginning, TheHive displays dates with the Month-Day-Year format. After 5 years, you can now customise the way you want date and time be displayed in all views of the UI.

This can be configured at the Organisation level, by defining the preferred format in the UI Configuration view. This required a user with org-admin profile or any profile with manageConfig permission.

Improved Case templates management

Case template management UI has been rewritten to allow more capabilities, required when you start having a growing number of templates:

Filtering
Sorting
Display dates
Display number of tasks and custom fields

Case merging

This is a feature that has been removed from TheHive 4.0 as it required a design update to take into account the multi-tenancy support.

In TheHive 4.1, case merging has the same UI:

Go to a case details page
Click merge
Select the case to merge data into
Validate

The difference in TheHive 4.1 is that, merging two cases, removes the originating cases, and create a new one with all the merged data.

Platform status page

This feature aims to help understand the issues related to TheHive health status. It contains details about:

database schema version
status of database indexes
status of database integrity checks

It also allows:

exporting a JSON report of the health status including more details then what is displayed on the UI
reindexing the database
triggering the database integrity checks

This page is available to super admin users and contains cross organisations data

Webhook authentication options

In TheHive 4.1, you can define authentication configuration for your Webhooks. For more details, please refer to the documentation website

KNOWN ISSUE: the auth property in Webhook definitions, in application.conf file is REQUIRED, so if your webhook doesn’t need authentication, then just add
auth: {type: "none"}
for each Webhook definition

Updating from TheHive 4.0

Due to the new database indexation feature, updating from 4.0.x requires some attention. Depending on your type of installation – standalone server or cluster – your setup will need to be upgraded accordingly.

On standalone servers, you will have to define a new local folder to store indexes;
For a cluster, you will need to locate an Elasticsearch instance to use it as index.

Finally, update the /etc/thehive/application.conf configuration file, install the new version of the application and restart the service.

more detailed information regarding this update can be found here:

https://docs.thehive-project.org/thehive/operations/update/

Indexes related to existing data will be created at the first start after the update to TheHive 4.1.0. Depending on the size of your database, this process can take a long time.

Upgrading from TheHive 3.x

If you are still using TheHive 3.x and want to migrate to TheHive 4.1, then you need to take a look to the following supported paths:

Target version	Required source version
TheHive 4.1.x	TheHive 3.5.1
TheHive 4.0.x	3.4.x < TheHive < 3.5.1

Supported migration paths

For more details, please refer to the documentation website

How to install

If you starts using TheHive with this version, we recommend having a look at our documentation site, and particularly to the installation and configuration section which is up to date and contains all instructions to install & configure TheHive 4.1.0.

Docker

If you use TheHive as a docker container, you can refer to the Docker-Templates repository that has a TheHive 4 up-to-date docker-compose configurations.

How to report issues

Please open an issue on GitHub with the dedicated template for TheHive 4 . We will monitor them closely and respond accordingly.

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

Elasticsearch 7.11.x is now supported !

After the first feedback received from the community on Discord and Github, we have put the coming 4.1.0 release of TheHive on hold to focus on what can potentially break Cortex v3.1.0 and TheHive v3.5.0 with the upgrade to Elasticsearch v7.11.x.
Several questions appeared on our side:

How to fix the installation process ?
How to fix the upgrade process ?
As the update of an existing Elasticsearch database to 7.11.x makes the downgrade impossible after that, will our fix repair it ?

Good news: this is fixed with TheHive v3.5.1 and Cortex 3.1.1, and these versions will repair databases that have already been updated to ES 7.11.x.

The update to these new versions introduces new indexes, for Cortex (cortex_6), as well as for TheHive (the_hive_17).

If you plan to run a new installation for Cortex, just follow the installation guide;
If you want to update your setup, we recommend to follow this process:
- Stop TheHive or Cortex
- Stop Elasticsearch
- Update Elasticsearch package
- Restart Elasticsearch and ensure this is going well
- Install TheHive 3.5.1 or Cortex 3.1.1 package
If you already updated Elasticsearch to version 7.11.x and faced potential breaks with Cortex or TheHive, follow the process described previously and you should regain access to your data.

Once updated, you should be invited to update the database:

Update Database after installing TheHive 3.5.1 or Cortex 3.1.1

Click on “Update Database” and you should then be invited to login. Everything should work fine after that.

As usual, we recommend making backups or a snapshot of the database before running the upgrade.

How to report issues

Please open an issue on GitHub for Cortex of the TheHive with the dedicated template for TheHive 3.x. We will monitor them closely and respond accordingly.

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

Compatibility issues with Elasticsearch update

Dear TheHive and Cortex users,

If you are running TheHive v3.5.0 and / or Cortex v3.1.0, the underlying database is Elasticsearch v7.x.

Elastic recently released two new versions: v7.11.0 and v7.11.1. After some initial feedback and investigations, we found that the new releases introduce changes that break the compatibility with our products – TheHive 3.5.0 and Cortex 3.1.0.

Therefore, please DO NOT upgrade your current database to Elasticsearch v7.11.x as no rollback is possible. Elasticsearch v7.11.x breaks the installation process as well as the update process.

If you are in the process of installing or updating to Cortex v3.1.0 or TheHive v3.5.0, you need to specify the exact working version of Elasticsearch to use:

For Debian packages: “apt install elasticsearch=7.10.2”
FOR RPM packages: “yum install elasticsearch-7.10.2-1”

We are currently running deeper investigations and are planning to release updated versions as soon as possible for Cortex v3.1.0 and for TheHive 3.5.0.

We will keep you informed, stay tuned!

TheHive 4.0.4 and TheHive4py 1.8.1: alerts got more APIs

Dear community, the new year has brought us another opportunity to build new features in your favorite Security Incident Response Platform, TheHive. We wish you a cheerful new year ahead and we thank you for being beside us all these years.

Last week, we released TheHive 4.0.4 and TheHive4py 1.8.1, and here is the official announcement including the details of the new features.

These releases focused on adding more capabilities to play with alert observables and give more flexibility when building alert feeders.

Please find the change logs for more details:

What’s new in TheHive

New Alert observable APIs

The major change in TheHive 4.0.4 is related to alert management. In TheHive 3, alert observables were included in the alert as an array of observable objects, and not as independent objects with links to the alert itself. This data model made alert observables CRUD operations, a bit challenging.

TheHive 4 has a better design for this, and alert observables have their own existence, and can be added/updated and deleted independently from the alert object.

This new design allows adding dedicated API endpoints to:

Add an observable to an existing alert;
Update the data of an existing alert observable;
Delete an observable from an alert.

Those APIs are not used by the user interface for now.

New Alert properties

This release introduced a new property called `importDate`. It represents the date at which an alert has been merged into a new/existing case. This property is then used to:

Allow filtering the alert list, for example: “List the alerts merged today”
Display the duration between the alert creation and its merge into a case.

*Alert list showcasing alert importDate*

This new property is of course available on the dashboard creation UI as a date field, among others:

imported: true if the alert has been merged
`handlingDurationInSeconds`: number of seconds before importing an alert
`handlingDurationInMinutes`: number of minutes before importing an alert
`handlingDurationInHours`: number of hours before importing an alert
`handlingDurationInDays`: number of days before importing an alert

To showcase the mentioned new properties, here are some screenshots:

importDate field used on a line chart as date field for x-axis

Simple line chart using the imported filter

Dashboard including two charts using the newly introduced alert fields

What’s new in TheHive4py

The 1.8.1 release of TheHive4py mainly focuses on adding support to the new alert APIs introduced by TheHive 4.0.4. It comes with 3 new functions:

`create_alert_artifact` to allow developers adding a new artifact to an existing alert

from thehive4py.api import TheHiveApi
from thehive4py.models import Tlp

THEHIVE_URL = 'http://127.0.0.1:9000'
THEHIVE_API_KEY = '**YOUR_API_KEY**'

api = TheHiveApi(THEHIVE_URL, THEHIVE_API_KEY)

# Instanciate a new domain artifact
artifact = AlertArtifact(dataType='domain', data='malicious-domain.tld', ignoreSimilarity=True, ioc=True)
api.create_alert_artifact(ALERT_ID, artifact)

# Instanciate a new file artifact
artifact = AlertArtifact(
    dataType='file', 
    data='malicious-file.exe', 
    ignoreSimilarity=False, 
    ioc=True, 
    sighted=True, 
    tlp=Tlp.RED.value)
api.create_alert_artifact(alert_id, artifact)

`update-alert-artifact` to allow updating the data of an existing alert artifact:

from thehive4py.api import TheHiveApi
from thehive4py.models import Tlp

THEHIVE_URL = 'http://127.0.0.1:9000'
THEHIVE_API_KEY = '**YOUR_API_KEY**'

api = TheHiveApi(THEHIVE_URL, THEHIVE_API_KEY)

# Create a new domain artifact
artifact = AlertArtifact(dataType='domain', data='malicious-domain.tld', ignoreSimilarity=True, ioc=True)
response = api.create_alert_artifact(ALERT_ID, artifact)

# Update its tlp, sighted and ignoreSimilarity flags
artifact_data = response.json()[0]
artifact_data['tlp'] = Tlp.RED.value
artifact_data['sighted'] = True
artifact_data['ignoreSimilarity'] = False

new_artifact = AlertArtifact(json=artifact_data)
api.update_alert_artifact(artifact_data['id'], new_artifact, fields=['tlp', 'ioc', 'ignoreSimilarity'])

`delete_alert_artifact` to allow removing an existing artifact from an existing alert

from thehive4py.api import TheHiveApi

THEHIVE_URL = 'http://127.0.0.1:9000'
THEHIVE_API_KEY = '**YOUR_API_KEY**'

api = TheHiveApi(THEHIVE_URL, THEHIVE_API_KEY)

# Delete alert artifact
api.delete_alert_artifact(ARTIFACT_ID)

Note that these new three methods are only available when using TheHive4py with TheHive 4.0.4+

You can find more details on the official documentation of TheHive4py.

Updating/Installing

To update your existing package to version 1.8.1:

$ sudo pip install thehive4py --upgrade

How to report issues

Please open an issue on GitHub with the dedicated template for TheHive 4 or the dedicated for m for TheHive4py. We will monitor them closely and respond accordingly.

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

Xmas Release: TheHive 4.0.3

This year is coming to an end. It’s a new opportunity to our team to release a new version of your favorite free and open source incident response platform, TheHive. We don’t aim to bother you during your Xmas holidays, but we thought of those who will be in front of their screens during the years’ last days.

Today, we announce the release of 4.0.3 that comes with some interesting enhancements and bug fixes.

What’s new?

The major features added in this release are:

improvement of the task management capabilities for collaboration, by adding a new flag called “Action Required”
review and improvement of the implementation of MISP synchronisation filters
new API capability to allow searching for Alerts per observables
new S3 provider and configuration for file storage (observables and task log attachments)

Require an action on a task

This feature is useful for collaboration to allow a master team requiring actions from the teams it collaborates with. Let’s explain it using a concrete example. Imagine a TheHive instance defining two organisations: SOC and CERT, both of them working on a Case led by the CERT team who is the owner of the Case.

For one of the tasks, the incident handler from the CERT team needs an action from the SOC team on a Task called “Gather evidences or IOC”. In the Task’s details page, at the “Sharing” section, for each “Share”, a new button “Require Action” is displayed. It allows any user with `manageTask` permission to enable the flag for the specific organisation for that specific Task.

The incident handler can also require an action from his team members.

Task details, Require Action from its own team

Task details, Require Action from another team

When the user clicks the “Require Action” button, TheHive asks if a Task Log needs to be added to the Task, to explain the required action. The user can proceed without adding a Task Log

If the user clicks on “Yes, add log”, a dialog is displayed asking the user to type a Task Log message and optionally add an attachment:

Once confirmed, the action is completed and the Task is marked as requiring action from the right team.

Action required from the SOC team on the “Gather evidences or IOC” Task

This feature comes not only with these Task related buttons but also includes some features for Case and Task listing pages, including filtering: its easier to list the cases where at least one task is still requiring an action from a team:

When navigating to the Task list, the user can easily see which Task needs an action:

Task list, filtered by the action required flag

When a user accesses a Task that is marked as requiring an action, the Task details page displays a warning message, with a “Mark as Done” button, that when clicked, confirms the completion of the required action:

When clicked, the “Mark as Done” button goes through the same confirm dialog as described above, allowing to optionally add a Task Log.

Review MISP filters configuration

TheHive 4.0.3 has reviewed and improved the performance of the MISP synchronisation services and added a new config to whitelist events by organisation, not only by tags. Below is a non exhaustive configuration of a MISP server, where the `whitelist.organisation` filter is used:

play.modules.enabled += org.thp.thehive.connector.misp.MispModule
misp {
  interval: 1 hour
  servers: [
    {
      name = "local"            # MISP name
      url = "http://localhost/" # URL or MISP
      auth {
        type = key
        key = "***"             # MISP API key
      }

      ...

      # Organization and tags 
      whitelist {
        organisation = ["good organisation"]
      #  tags = ["tag1", "tag2"]
      }
    }
  ]
}

Search for alerts by observable conditions

In TheHive 3, Alert observables are stored within the Alert data, not as un independent piece of data, and querying them is not possible through the `_search` APIs and the Query DSL.

In 4.0.3 this limitation has been removed, allowing querying an alert with conditions on it’s child observables.

Using TheHive4py, the following code is now possible:

import json
from thehive4py.api import TheHiveApi
from thehive4py.models import *
from thehive4py.query import *

THEHIVE_URL = 'http://127.0.0.1:9000'
THEHIVE_API_KEY = 'API_KEY'

api = TheHiveApi(THEHIVE_URL, THEHIVE_API_KEY)

# Define the query
query = And(
    Eq('source', 'THEHIVE-PROJECT'),
    Eq('severity', Severity.MEDIUM.value),
    Child('alert_artifact', And(
        Eq('dataType', 'hash'),
        Eq('data', 'A_HASH_VALUE')
    )),
    Like('title', '*MALSPAM*')
)

# Search for alerts
response = api.find_alerts(query=query, range='all')

# Print 
print(response.json(), indent=4)

The code snippet above, searches for Alerts of with:

source='TheHive-Project'
severity=medium
title including the word “MALSPAM”
having a specific `hash` observable

S3 storage support

File storage is used in TheHive to store attachments. TheHive now supports a new type of storage in addition to hadoop and local file system: Amazon S3.

S3 storage provider can be configured by specifying endpoint, region and credentials. The settings must be located in the provider section, in application.conf:

storage {
  provider: s3
  s3 {
    bucket = "thehive"
    readTimeout = 1 minute
    writeTimeout = 1 minute
    chunkSize = 1 MB
    endpoint = "http://s3.amazonaws.com"
    accessKey = "xxx"
    secretKey = "xxx"
    region = "us-west-1"
  }
}

How to install/update ?

Our installation guides are up-to-date.

Important note

If you are updating an existing instance of TheHive 4.0.0, ensure to read the installation guide. Since our recent release of TheHive 3.5.0, we updated our repositories. The codename of repositories containing all new released packages is now named release, instead of stable. So update your apt or yum repository file.

How to report issues

Please open an issue on GitHub with the dedicated template for TheHive 4. We will monitor them closely and respond accordingly.

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

TheHive4py 1.8.0 is hot off the press

TheHive4py 1.8.0 is finally released. During the last 5 months, the team was busy working on TheHive and Cortex but today, it’s time to unveil the biggest milestone of TheHive’s official python API client.

TheHive4py official documentation website

1.8.0 contains 31 Github issues including 17 contributions for which, we would like to thank all the community members who helped shaping the release.

TheHive4py is getting a bit hard to maintain because of the backward compatibility constraints introduced by TheHive 3 and 4 versions. TheHive 4 also introduces new features that are not available in TheHive 3, and this makes it challenging to serve both versions with the same code base.

TheHive 4 has also its dedicated and optimised APIs (read APIs v1), and those are not used by TheHive4py, which is still relying on APIs v0 of TheHive 4.

Anyways.

What’s new?

1.8.0 release introduced a significant number of new methods and changes:

attachment download support for files (by id), observables and task log attachments
alert merge into case
alert delete
case task delete
case task log search
task log search
support to alert similarity in fetch
case observable search method
case observable fetch method
case observable delete method
support to in memory files when calling APIs evolving attachments
MISP export
support to PAP in alerts
add Tlp, Pap, Severity, CaseStatus, TaskStatus enumerations

in addition to some TheHive 4 related features:

Add a version parameter to TheHiveApi class’s constructor
Add support to ignoreSimilarity attribute
Add support to alert.externalLink attribute

Please read the full release notes for more details.

Below, we will highlight the major features other than the self explanatory newly added methods.

New `version` parameter

This change is important and required for developers using TheHive4py to play with a TheHive 4 instance. the `version` parameter has been introduced to allow fine tune access to features available on TheHive 4 and not in TheHive 3, like for `alert.extrnalLink` field.

The version is set by default to Version.THEHIVE_3.value, which means version 3.

from thehive4py.models import Version

# Init an API client for TheHive 4
api = TheHiveApi(THEHIVE_URL, API_KEY, version=Version.THEHIVE_4.value)

Add support to `ignoreSimilarity` field

This capability has been introduced by TheHive 4.0.1 release. It allows setting an `ignoreSimilarity` flag at the case and alert observable level. When set to True it tells TheHive to ignore the observable from any similarity computing.

So, if you need to create an alert with an observable you would like to skip when running the similarity algorithm, then, you need to set ignoreSimilarity to True

Here is an example that creates and alert with an observable to be ignored for similarity:

import uuid
from thehive4py.api import TheHiveApi
from thehive4py.models import Tlp, Pap, Alert, AlertArtifact

sourceRef = str(uuid.uuid4())[0:6]

# Prepare the Alert object
alert = Alert(title='Sample alert - ID {}'.format(sourceRef), 
  tlp=Tlp.AMBER.value, 
  pap=Pap.AMBER.value, 
  tags=['TheHive4Py'],
  description='Sample alert for the blog post',
  source='dev',
  type='script',
  sourceRef=sourceRef,
  externaleLink='https://some-web-site/alert/{}'.format(sourceRef),
  artifacts=[
    AlertArtifact(
      dataType='domain', 
      data='dl.some-web-site.com', 
      tlp=Tlp.WHITE.value, 
      ioc=True,
      sighted=False,
      ignoreSimilarity=True
    )
  ])

# Init an API client instance
api = TheHiveApi(THEHIVE_URL, THEHIVE_API_KEY, version=4)

# Create the alert
response = api.create_alert(alert)

Note that the same option is available for Case observables during creation and update:

# Set an observable as ignorable

api.update_case_observable(
   observable_id, 
   {"ignoreSimilarity": True}, 
   fields=['ignoreSimilarity']
 )

Support in-memory files

Old versions of TheHiv4py required existing files when dealing with attachments. For example, to create a file case observable, the corresponding file has to be already stored on the file system before calling the `create_case_observable` method.

This release allows using files from memory and not relying on file paths. So you use, for example, an API to download a file and you want to store that file as observable, you can use the new feature of TheHive4py, as below:

from thehive4py.models import Tlp, Pap, Alert, CaseObservable

# Say you have a method to get a screenshot
file = get_screenshot()

# Prepare the observable
observable = CaseObservable(
    dataType='file',
    data=(file, 'screenshot-{}.png'.format(int(time.time())*1000)),
    tlp=Tlp.WHITE.value,
    pap=Pap.GREEN.value,
    tags=['category:screenshot']
)

# Create the observable
response = api.create_case_observable(case_id, observable)

# Close the file object
file.close()

Note: closing the file object is still required. We will handle closing the files during the upcoming releases.

Attachment download features

The new methods introduced by 1.8.0 release and related to attachment download, light some interesting TheHive APIs up.

Did you know TheHive has APIs to download existing file from the datastore? Do you know how does TheHive store files?

Well, when a file is uploaded to TheHive as case observable, alert observable or case log attachments, the file is stored in the DataStore and is given an ID that can be used in two APIs:

`/api/datastore/{attachment_id}`: downloads the file content
`/api/datastorezip/{attachment_id}`: downloads the file content as zip password protected file, and the password is the one defined in application.conf (defaults to `malware`)

In this release, we introduced methods to make these APIs available on TheHive4py.

Download an attachment by its ID

This method is useful if you know the attachment ID (could be an alert file observable for exemple, in TheHive 4)

# Download an attachment by a known id
response = api.download_attachment(
  attachment_id, 
  filename='screenshot.png',
  archive=False
)

# Save the attachment to disk
f = open('./{}'.format('screenshot.png'), 'wb')
f.write(response.content)
f.close()

Download an attachment of a task log

This method allows downloading the attachment of a given task log object, identified by its ID

response = api.download_task_log_attachment(log_id, archive=False)

f = open('./{}'.format('screenshot.png'), 'wb')
f.write(response.content)
f.close()

If the task log doesn’t have an attachment, this methods throws an exception.

Download a file attachment of a file observable

This methods allows downloading a file observable, and forces protecting it as password protected zip archive

response = api.download_observable_attachment(observable_id)

f = open('./{}'.format('observable.png.zip'), 'wb')
f.write(response.content)
f.close()

If the observable is not a file, this methods throws an exception.

Documentation

As you might know, with the 1.7.0 release we released a documentation website for TheHive4py where all the methods are documented. Donc hesitate to refer to it for more details: https://thehive-project.github.io/TheHive4py

Updating/Installing

To update your existing package to version 1.8.0:

$ sudo pip install thehive4py --upgrade

Got a question?

If you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. As usual, we’ll be more than happy to help!

It’s not Patch Friday… TheHive 4.0.2 released

Last Friday, our team released a significant number of changes and fixes, improving TheHive 4. The community was very reactive and hurried to test it. Today we are announcing a patch release to fix annoying issues we decided to quickly patch: welcome to 4.0.2.

The major issue is related to Alert bulk merging which is part of the big refactoring of the Alert listing section.

Well, s**t happens, but as a gentlemen, we owe you a feature, or two 🙂

What’s new?

In addition to the Alert bulk merging issue, we fixed bugs related to:

Migration
Filtering observables by attachement attributes
Backward compatible APIs

Curious to read the detailed change log? Here your go.

TheHiveFS, do you remember?

It stands for TheHive File System, a feature we released with TheHive 4.0-RC1. In today’s milestone we are improving the security of this feature by adding a new user permission, required to have access to TheHiveFS features.

The newly created accessTheHiveFS permission is included by default in both org-admin and analyst user profiles.

Refined editable fields, for a better UX

In TheHive UI, editing objects relies on editable fields instead of dedicated form to edit objects. This means you can update a case title by clicking the Blue Pencil icon displayed when you mouse-over the case title for exemple.

In this release we refactored all the editable fields to provide a better user experience:

You no longer need to click just on the `Blue Pencil` icon to switch to edit mode, you just need to click on any value, for example the Case assignee field, or the Observable tags field:

Editable fields have now a `Clear` option, allowing users to unset the value of an attribute:

*Editable custom fields can be set empty*

This new improvement benefits to the custom fields sections in Case and Alert details sections, as showcased above.

Configurable layout of custom fields

In older TheHive versions, custom fields were displayed using a single column. Cases with big number of custom fields produced a long scrolling Case details pages, so we decided in TheHive 4 to use a 3-column layout to reduce the resulting scroll fatigue.

Now some users are complaining because of long custom fields values not being correctly displayed. So we decided to let users choose their preferred layout.

1-column layout to display custom fields in a Case details page

How to install/update ?

Our installation guides are up-to-date.

Important note

Have you got a minute to let us know how you use TheHive ?

We would love to hear from you (10 questions < 1minute) : https://t.co/l5osjvQ1k7

Many thanks for taking the time 🙏

How to report issues

Please open an issue on GitHub with the dedicated template for TheHive 4. We will monitor them closely and respond accordingly.

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

It’s now time for TheHive 4 to get an update: TheHive 4.0.1 is out!

Back in July, we announced TheHive 4.0, the foundation for future releases of your favorite Open Source SIRP.

Today, we are pleased to deliver one of the biggest patch releases we’ve done so far, in terms of number of fixed issues: TheHive 4.0.1! Not only did we squash lots of bugs, we also included some cool improvements we didn’t want to hold until the next version.

As for TheHive 3 and Cortex unveiled few days ago, we fixed the vulnerabilities reported by Play framework in October as well.

A huge work has been accomplished to fix a backlog of bugs (thanks to the community) in several parts of the product:

Configuration;
API;
Dashboards;
Livestream;
Cases;
Alerts;
Observables;
Multi Factor authentication;
Active Directory authentication;
Export to MISP.

You can find details of the 80+ issues included in this milestone: Changelog file.

Wait, there is also new stuff:

Cases and Alerts similarity fine tuning;
Similar cases in Alert preview panel refined;
Filtering capabilities improvements;
New UI settings & options;
Custom fields in Case and Alert lists;
Statistics panel improvements;
API key in user settings page;
More migration tool options.

Cases and Alerts similarity fine tuning

In TheHive, correlation between Alerts and Cases, and between Cases themselves, is computed throughout their respective Observables:

A Case is considered similar to an Alert, if they have at least one common observable;
A Case is considered related to another Case, if they have at least one common observable.

In some situations, those relationships are undesirable when based on useless/meaningless observables.

Starting with TheHive 4.0.1, Observables are enriched with a new attribute called ignoreSimilarity, set to false by default. Now, when this attribute is set to true, an observable is simply not taken into account in the relationship between two cases, and is not involved in the similarity calculation, for Cases and Alerts.

This attribute is displayed alongside with the IOC and Sighted flags, in the Observables list – which has been tweaked for the occasion – as well as in the detailed view.

IgnoreSimilarity flag in the revamped Observables list

And you can also edit this for a set of selected observables.

Long story short, if you want to break a correlation, you just need to set the linking Observable‘s ignoreSimilarity flag to true.

Alerts and similar Cases

The attribute mentioned earlier is taken into account when correlating Alerts with existing Cases : the Similar Cases view in the Alert preview dialog.

Observables with ignoreSimilarity set to true will be ignored when fetching cases similar to the current Alert, whether it is in the Alert or the Case side.

A forthcoming update of thehive4py library will allow to set this attribute in Alerts, along with many other new things.

The Similar Cases view has been thoroughly enhanced to provide more highlights facilitating alert triage and the merging of alerts into existing cases. First, a column named “Matched” has been added. It contains the list of observable dataTypes and the number of occurrences matching the Alert : this should be very useful to identify quickly what type of data has matched the alert content. A filter on this column has also been added.

And there are more refining capabilities in this view:

Sorting and Filtering on Title of Similar Cases;
Specifying a minimum observables rate that matches the Alert;
Specifying a minimum IOCs rate that matches the Alert.

Refining the Similar Cases view during Alerts triage

… And, above all, columns can now be sorted. With all these new capabilities, triage and merge Alerts in Cases should be easier.

Filtering capabilities improvement

In TheHive 4, filter forms have the same structure all over the product. Any improvement in the area, benefits to all the listing pages.

For example, in the alert similar cases tab, a new filter form has been included. You can quickly select the type of Cases you want to display, but also use the advanced rules and search criterias.

In this release, the filter component has new capabilities:

Date filter: now allows setting dynamic ranges instead of setting from and to fixed date values. Possible values are:
- Today;
- Last 7 days;
- Last 30 days;
- Last 3 months;
- Last 6 months;
- Last year;
- Custom: allowing the old-fashioned way of setting date ranges.
Tag filter: Autocomplete is now enabled.

*Advanced filtering for Similar Cases during Alert triage*

In TheHive 4.0.1, there is one more place that welcomed a filter form: the list of Alert observables in the preview dialog.

New Org level UI settings

UI configuration page is the place where TheHive adds new options to customise the behavior of the UI, for a given organisation. This is an area that will be expanded over time.

For this milestone, two new options have been introduced:

Allow merging Alerts in resolved cases;
Default filter of Alert similar cases.

*Default filter for Similar Cases in Alerts preview*

The first one is self-explanatory and will hide the `Merge into case` button in the Alert similar cases section

The second one allows an administrator define, for an organisation, the default filter to apply to Alert similar cases view. For example: “show only potential similar cases created in the last 7 days and are still open”.

If during the triage, the filter has been updated by an analyst, the default filter cas be retrieved through Default filter option of the Quick Filters.

Retrieve default filter in alert similar cases

Custom fields in Case and Alert lists

“Damn, why I’m not able to see my custom fields in my cases list”, “It’s a shame I cannot filter my alerts with my custom defined properties”… We are pretty sure you said it, at least once.

Well, you dreamt of it, and here we go, we did it for Cases and Alerts

You will be able to see all the custom fields you defined in your Case Templates and propagated to your Cases;
Custom fields with undefined values are not displayed;
Custom fields are shown with respect of the order you define;
Clicking on a custom field, filters your lists using the selected value;
You can enable displaying the custom fields using the toggle button on the toolbar located on top of the filter form;
All those capabilities are available in Cases and Alerts views.

New statistics view in Cases and Observables lists

The Stats view has been revamped to represent the statistics using both tables and shiny colourful donuts (not only for managers).

This improvement has been made in Cases, Observables and Alerts views.

User settings

This feature has been initially introduced in Cortex and was missing in TheHive. All users can now access their API key, copy or update it, as long as an administrator created it first. No more API keys sent over emails or chat applications.

Migration

The migration assistant program has been updated with a few bug fixes and new filtering options. When migrating, you can now specify:

If you want to include or exclude Alerts generated from specific Sources or by their Type;
If you want to include Audit trails regarding specific objectType (case, case_task, case_observable …);
If you want to filter out Audit trails with specific actions (Update, Creation, Delete).

/opt/thehive/bin/migrate --help

[..]  
  --include-alert-types ,...
                           migrate only alerts with this types
  --exclude-alert-types ,...
                           don't migrate alerts with this types
  --include-alert-sources ,...
                           migrate only alerts with this sources
  --exclude-alert-sources ,...
                           don't migrate alerts with this sources
[..]   
  --include-audit-actions 
                           migration only audits with this action (Update, Creation, Delete)
  --exclude-audit-actions 
                           don't migration audits with this action (Update, Creation, Delete)
  --include-audit-objectTypes 
                           migration only audits with this objectType (case, case_artifact, case_task, ...)
  --exclude-audit-objectTypes 
                           don't migration audits with this objectType (case, case_artifact, case_task, ...)

So, you can migrate your data directly to TheHive 4.0.1.

However, please note that the migration tool does not support data from TheHive 3.5.0 yet. In short, you can only consider migrating you data from TheHive 3.4.0, 3.4.1, 3.4.2 or 3.4.4 to TheHive 4.0 or TheHive 4.0.1 for the time being.

How to install/update ?

Our installation guides are up-to-date.

Important note

Have you got a minute to let us know how you use TheHive ?

We would love to hear from you (10 questions < 1minute) : https://t.co/l5osjvQ1k7

Many thanks for taking the time 🙏

How to report issues

Please open an issue on GitHub with the dedicated template for TheHive 4. We will monitor them closely and respond accordingly.

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

TheHive 4.0 is out!

Introduction

Several ~~months~~,no, years ! after the first line of code – the first line was committed in 2016–, we are very excited and proud to announce the release of TheHive 4.0.

This means more than a major version for us. This was – and still is — like a completely new project, a new generation, a lot more challenging than before. We had to make the application climb a major step to introduce new key features, some we added in this version, others we have in mind for the future.

Objectives

The development of the second generation of TheHive, aka. version 4, was driven by three main objectives:

Add support to multi-tenancy: allow 1 instance of TheHive to serve many teams and organisations
Add support to Role Based Access Control to define fine grained user profiles
Rethink the data model and structure to support the goals listed above (Moving from Elasticsearch as main persistence layer, to a data model designed as a graph).

Challenges

TheHive Project is thoroughly adopted by SOC, CERTs and CSIRT teams, who decided to go with TheHive Project since the first releases. It is worth noting that until today, TheHive has had a total of 52 releases since 2016.

Those teams helped the project by contributing to our QA, questions, feature requests etc… and our way of thinking drove us to not let them down, and we decided to produce a backward compatible software.

The way we have been working until now aims to make our community move smoothly from TheHIve 3 to TheHive 4.

Backward compatibility

This is the most difficult challenge we have had, but we have hard heads and soft hearts.

TheHive 4 is expected to be backward compatible, thanks to APIs v0. Yes, we provide versioned APIs having the same endpoints as TheHive 3, and producing the same results. Search APIs also support the same query language, except some corner cases like searching using the “_string” operator (which is tightly coupled to Elasticsearch query language, but we have working alternatives).

Performance concerns

Supporting backward compatibility might force you to accept complex designs. And TheHive 4 RC3 was a clear example of that limitation.

Many kind users who tested TheHive 4 RC3, raised performance issues, slow UI problems etc… And it was completely expected. We thank them for making such a pressure on us, we used it to boost the refactoring of the UI, which was using backward compatible APIs (unoptimized for the new data model and representation), specially to read data (listing cases or observables for example).

We can discuss the technical details of this hard point later, but it mainly relates to navigating through graph-based data using a document based query system, which is not optimised.

For example, if you want to search for list of observable of a given case, the ideal way of doing that on a graph-base model is to:

Get the case by its ID, which is indexed (very fast operation)
Navigate through case relation, to find its links of type observable

But the backward compatible query language works differently: It scans all the graphs to search for observables that have a case parent with a given ID, which has a slower performance in a graph-based database.

Multi-tenancy and RBAC

TheHive 4 comes with a special multi-tenancy support. It allows the following strategies:

Use a siloed multi-tenancy: you can define many organisations, without allowing them to share data
Use a collaborative multi-tenancy: you can define a set of organizations and allow them to collaborate on specific cases/tasks/observables, using custom defined user profiles (RBAC)

This feature is very powerful but has a cost: an expected performance overhead. For example, when scanning the graph of data to search for a list of cases, TheHive must return the cases of your organisation and the case you can have access to because of the sharing rule.

New foundations

TheHive 3 was based on a framework called Elastic4play, written by Thomas to abstract all the routines required by a web application written with play 2 and using Elasticsearch.

TheHive 4 has its own core framework: Scalligraph, built to handle the following features.

Scalligraph will be the foundation of the next major version of Cortex.

What’s new in 4.0

TheHive 4.0 release has a significant amount of changes. We will quickly explain the most important, and you can refer to the change logs if you need to have more details.

UI Performance

This was the most important task of this release. As we mentioned above, we were using backward compatible APIs in RC3 release, and migrated 80% of the UI to use the APIs v1 which are optimised for the new graph-based and multi-tenant data model.

OAuth2 Support

This topic gave birth to many github issues, some of them related to TheHive’s UI not correctly redirecting authenticated users. OAuth2 support has been tested with many providers like: Okta, Keycloak, FusionAuth, Microsoft Azure, Office 365 and Google Gsuite.

Starting from this version, there is an API endpoint that handle all the authentication and redirections: /api/ssoLogin

Here is a configuration sample for MS Office 365

{
  name: oauth2
  clientId: "CLIENT_ID"
  clientSecret: "CLIENT_SECRET"
  redirectUri: "http://THEHIVE_URL/api/ssoLogin"
  responseType: code
  grantType: "authorization_code"
  authorizationUrl: "https://login.microsoftonline.com/TENANT/oauth2/v2.0/authorize"
  authorizationHeader: "Bearer "
  tokenUrl: "https://login.microsoftonline.com/TENANT/oauth2/v2.0/token"
  userUrl: "https://graph.microsoft.com/v1.0/me"
  scope: ["User.Read"]
  userIdField: "mail" 
}

You can find more details about the OAuth2 support in the authentication config documentation

Improved Analyzer and Responder selection

Analyzer selection when calling bulk observable analysis has been improved to show the possible analyzers per observable type.

Analyzers selection during observable bulk analysis

For responders, the user experience has been improved as well, especially for instances with a big number of responders. The simple dropdown menu available to select responders has been replaced by a dialog allowing list filtering and scrolling:

Add bulk operations to case listing

Before this release, simple case updates required visiting the cases one by one and editing them. We added in this release a bulk edit feature, depending on user’s permissions on the selected cases

Bulk edit dialog, used here from case list

The same bulk editing component has been used to improve the same operations on observable list page.

Other noteworthy changes

We need to mention that the following changes have been included in TheHive 4.0 release:

Add pagination and filtering to users administration
Add back the UI configuration by organisation. The only available option is related to enabling/disabling the use of Empty Case.
Show sharing summary in task and observable lists
Improve alert preview dialog
Add alert externalLink feature allowing the display of external links for any alert, not only MISP alerts.

Known limitations

Even after 49 closed Github Issues, there are still major topics to be addressed by the upcoming releases:

Add back support to case merge which is not satisfying today. The challenge is to find the best to merge cases and make sure that it works in a profile-based multi-tenant design.
Add full text search support. In older versions, TheHive benefited from the full text search capabilities of Elasticsearch. With the new database and persistence system, full text support requires adding a dedicated indexing layer.

Installing and testing TheHive 4.0

After months of testing versions, this official release means that we consider it ready for production purposes. If you’re new with TheHive, we recommend going with TheHive 4.0.

Several installation guides have already been published, suitable with the chosen operating system and installation type, and new are coming.

For testing and training purposes, a virtual machine with a simple configuration of TheHive 4.0 and Cortex 3.0.1, is also published and available starting from now. Please refer to the documentation for download and usage instructions.

Want to upgrade from TheHive 3.x ?

All changes brought to TheHive make the upgrade more challenging than installing the new package and watch the progress bar. To support you with the upgrade, a migration tool comes along with the application to shift your current version of TheHive to TheHive 4.0.

A dedicated guide has been published to help users with this significant task. We recommend using a new server aside from your production server to ensure everything works fine with the migration.

Future of TheHive 3.x

This major outcome doesn’t mean TheHive 3 end of life is reached. As previously announced, we plan to support this version for some time, our next milestone being to support Elasticsearch 7.x with a first Release Candidate.

How to report issues

Please open an issue on GitHub using the template made for TheHive4 if you’d like to report a bug on this version. We will monitor those closely and respond accordingly.

TheHive 4.0-RC3, a new kid on the block

Three weeks ago, on May 6th, we announced the availability of TheHive 4.0 RC-2 release and the active community made the usual hard work of testing the release to find bugs and ask for enhancements.

Special thanks to Christopher, alias crackytsi who has already created 122 Github issues, 11 of them are just for 4.0-RC-3 milestone.

We are thrilled to present our third release candidate before the final release of TheHive 4. As the RC-2, this milestone brings new features and fixes a nice set of issues.

This blog post will focus on the following new features:

Multi-orgs users
Switch organisation
OAuth2
Migration tool performance
Case sharing overview

If you are curious about all the issues that have been addressed, you can read the full changelog

Multi-orgs users

This feature doesn’t introduce UI changes, but it allows a superadmin or an org-admin to add an existing user to an organisation.

Users in TheHive 4 are identified by their email addresses, so when an administrator adds a new user, with an email address that already exists, TheHive 4 links that existing user to the organisation being updated.

This ends up with a single User record on the database, linked to multiple organisations. Thanks to the new graph data model. This means the given user has:

the same credentials
the same api key, if enabled
the same 2FA settings, if enables
the same status (locked or not)

With that being said, the user can have a different profile for on the organisation (s)he belongs to.

What happens when a user is logged in?

As we mentioned earlier, a user belonging to several organisations, has the same authentication settings, and after the login, his/her workspace is opened with the context of the first organisation (s)he has been created on.

For example, if John was firstly created on the *SocLevel2* organisation, and was later attached to *CTI* organisation, then after signing in, the user is redirected to the workspace of *SocLevel2* organisation.

Future improvements

We will consider allowing the user to define a default organisation to be displayed juste after the login. We are examining the possibility to allow the user to define a default organisation to be displayed just after the login process. Hopefully, we will be able to add this feature in TheHive 4.0.0 release.

Switch organisation

This feature empowers the multi-tenancy capabilities brought to you by TheHive 4. Following what has been showcased above, how can a user, who belongs to more than one organisation, switch between his/her tenants?

The UI introduces a simple feature, available to “multi-org” users only, as a button on the right hand side of the page’s header, aka. the navigation bar.

This button is just hidden for users who belong to a single organisation.

Once clicked, that button show a dialog that displays the following details:

user’s organisations
user’s profile on each organisation
the current organisation

Clicking on an item of this list, refreshes the page by loading the context of the selected organisation, and the UI behaves like if the user was logged in a a member of that selected organisation.

Very useful.

OAuth2

We had a considerable amount of users asking for SSO and OAuth support in TheHive. We tried to make it more robust in TheHive 4, and let it rely on a redirectUri provided by the backend (/api/ssoLogin) instead of the old redirectUri that some OAuth providers don’t support (index.html/#!/ssoLogin).

In TheHive 4.0 RC-2, OAuth 2 partially worked, and failed to redirect the user to the home page after the authentication success. Yes, sorry for that.

We spent some time testing the new implementation. We will devote some blog posts to it, but firstly, here is a working example relying on Keycloak

auth {
  providers: [
    {name: session}               # required !
    {name: basic, realm: thehive}
    {name: local}
    {name: key}    
    {
      ##############
      # Keycloak
      ##############
      name: oauth2
      clientId: "CLIENT_ID"
      clientSecret: "CLIENT_SECRET" # or empty
      redirectUri: "http://THEHIVE/api/ssoLogin"
      responseType: "code"
      grantType: "authorization_code"
      authorizationUrl: "http://KEYCLOAK/auth/realms/TENANT/protocol/openid-connect/auth"
      authorizationHeader: "Bearer"
      tokenUrl: "http://KEYCLOAK/auth/realms/TENANT/protocol/openid-connect/token"
      userUrl: "http://KEYCLOAK/auth/realms/TENANT/protocol/openid-connect/userinfo"
      scope: ["openid", "email"]
      userIdField: "email"
    }
  ]
}

After a question asked on Twitter, we tried to test our OAuth implementation with the providers mentioned in the answers, and we have successfully tested:

Migration tool performance

The migration tool we implemented in TheHive 4.0 RC-2 suffered from important performance issues as a result of our desire for a clean design.

In fact, enabling database locks during a parallelised and asynchronous processing of the migration operations produce a migration tool with poor performance.

We changed the strategy, by disabling locks and programmatically handling duplicates if they happen. This ended by a significant improvement of performance

We hope you can test it and provide us with your feedback.

Case sharing overview

Case sharing is the most important feature that the multi-tenancy support adds to TheHive. Allowing users to quickly spot if a case is owned or is coming from a share (made by another organisation) improves the user’s experience.

The other handy information is: the number of organisations having access to a certain case

This screenshot shows all the case sharing related UI element:

The blue line, indicates that the case is coming from another organisation
The green line, indicates that the case is owned by the current organisation
The red line, highlights the column that show the number of organisation having access to the corresponding case

How to report issues

Please open an issue on GitHub using the template made for TheHive4 if you’d like to report a bug on this version. We will monitor those closely and respond accordingly.

A word about the documentation

More about the new features

Database indexation

MISP taxonomies support

Custom tags support

Tactics, Techniques & Procedures, with MITRE ATT&CK

Attack Pattern management

Case TTPs

Case list TTP related improvements

Customise date and time

Improved Case templates management

Case merging

Platform status page

Webhook authentication options

Updating from TheHive 4.0

Upgrading from TheHive 3.x

How to install

Docker

How to report issues

Running Into Trouble?

How to report issues

Running Into Trouble?

What’s new in TheHive

New Alert observable APIs

New Alert properties

What’s new in TheHive4py

Updating/Installing

How to report issues

Running Into Trouble?

What’s new?

Require an action on a task

Review MISP filters configuration

Search for alerts by observable conditions

S3 storage support

How to install/update ?

Important note

How to report issues

Running Into Trouble?

What’s new?

New version parameter

Add support to ignoreSimilarity field

Support in-memory files

Attachment download features

Download an attachment by its ID

Download an attachment of a task log

Download a file attachment of a file observable

Documentation

Updating/Installing

Got a question?

What’s new?

TheHiveFS, do you remember?

Refined editable fields, for a better UX

Configurable layout of custom fields

How to install/update ?

Important note

Have you got a minute to let us know how you use TheHive ?

How to report issues

Running Into Trouble?

Cases and Alerts similarity fine tuning

Alerts and similar Cases

Filtering capabilities improvement

New Org level UI settings

Custom fields in Case and Alert lists

New statistics view in Cases and Observables lists

User settings

Migration

How to install/update ?

Important note

Have you got a minute to let us know how you use TheHive ?

How to report issues

Running Into Trouble?

Introduction

Objectives

Challenges

Backward compatibility

Performance concerns

Multi-tenancy and RBAC

New foundations

What’s new in 4.0

UI Performance

New `version` parameter

Add support to `ignoreSimilarity` field