TheHive: June-Dec 17 Roadmap

A new version of TheHive will be released by the end of June. We will take this opportunity to review our release naming and numbering from the ground up.

Months ago, we started giving ‘major’ versions (2.10, 2.11, …) the name of honey bee varieties. 2.10 was called Buckfast. 2.11, the current version, is called Mellifera. And we were supposed to give 2.12 yet another name. However, and after the few hiccups we’ve encountered with our QA as of late, we have decided to change things around in order to make sure new releases are as stable and well-maintained as you should expect them to be.

Starting from the next release (2.12), we will abide by the following numbering scheme:

  • Major versions == X (2, 3, …)
  • Minor versions = X.Y (2.12, 2.13, 3.1, …)
  • Hotfix/maintenance versions = X.Y.Z (2.12.1, 2.13.2, 3.1.1, …)

Only major versions will have corresponding honey bee names. So long as we stay with v2, we’ll keep calling all the minor versions Mellifera N (2.12.0 = Mellifera 12). Version 3 will be called Cerana.

Mellifera 12 – June 29, 2017 (planned date)

Mellifera 12 (v 2.12) will succeed to Mellifera 2 (the current version) to comply with the new naming scheme. It will allow you to see how similar new alerts are to existing cases so you can decide whether you import them into an existing case, create a new one or ignore them altogether. Mellifera 12 will show you the status of all the related cases (#229) to the one you are working on. Finally, you’ll have the ability to change the default case template before importing an alert.

M12 will also support custom fields (#12), a feature that has been requested by numerous users. This version will also add mini-reports to the Observables tab. That way, once a Cortex analysis has been completed, analysts will be able to view part or all the resulting short report in that tab instead of having to navigate to the page of each observable to read the short report.

Mellifera 13 – September 14, 2017

TheHive 2.13 should be the last Mellifera version. It will complete TheHive’s integration with MISP by adding the ability to export all observables or a subset of them to a MISP instance. Please note that TheHive allowed you from the start to import events from multiple MISP instances but since sharing is caring, we wanted to add the ability to export to this very popular threat sharing platform from your Security Incident Response Platform (SIRP). We do not want to rush it though.

Cerana – October 12, 2017

Cerana or TheHive 3.0.0 will bring a complete UI overhaul to make it even easier to work on cases, perform analysis and get your job done, after the interface refreshments Mellifera brought. It will lay the ground for some nifty features we have in mind.

Cerana 1 – November 15, 2017

TheHive 3.1.0 will include dynamic dashboards: the ability to work with the statistics and metrics the way you want and generate customized dashboards to help you drive your activities.

Keep an eye on TheHive’s milestones on GitHub. There are other features and enhancements that we might add as we progress and we will reflect them on that page.

Correction: June 12, 2017
An earlier version mentioned GitHub issue #36 as pertaining to custom fields while it is a request for globally-defined tags that an analyst can choose from.




Case Merging

The chefs behind TheHive authorized this reporter a sneak preview into their code kitchen as they were preparing a delicious recipe for an upcoming release: case merging.

Reading about someone else’s experience with food, wine, music or in this case code can be baffling but let us not shy away from a tedious task and call an example to the rescue.

Antoine is the security incident response lead of the StarGazer CSIRT which is using TheHive (TH) to handle incidents and keep the monsters at bay. Their TH instance is connected with their MISP server and Antoine has been keeping an eye on the top navigation bar of the application to spot new MISP event notifications that would need processing. Here comes one. Antoine clicks on the notification bubble and is taken as a result to the Import MISP events view.

The Import MISP events View

Indeed, a new MISP event showed up from a partner’s instance that is synced with StarGazer’s. Antoine previews the event, decides it worths an investigation and creates a TH case out of it with a number of associated tasks by clicking on import event. StarGazer CSIRT has indeed taken advantage of TH case template engine to match handling MISP events to their processes.

Preview a MISP event before importing it

Isabelle, a StarGazer security analyst, has just wrapped up a task from a previous case, looking for suspicious activities in proxy logs. She completed her analysis, updated the task in TH and closed it. Since the Flow was open on her screen, she saw Antoine creates the new case and the related tasks. As it happens, one of them consists of searching URLs copied over from the MISP event in the proxy logs.

The Flow

Isabelle clicks on the new task, an action that automatically assigns it to her, and starts working on it. Antoine sees what Isabelle is up to thanks to the Flow and then moves on to deal with a different task.

A few minutes later, Antoine’s eyes are caught by a new MISP event notification. He can’t handle it right now so he reaches out to Sabine, the backup incident response lead, and asks her to take care of it. Sabine obliges and previews the new event which is from a different source than the first one. She decides that it deserves an investigation as well and there, she creates a new case. Time flies by and StarGazer analysts are buzzing along the two investigations only to realize that the two MISP events were in fact almost the same.

Here is what happened. The two events were published by two different sources who were subjected to a spear-phishing attack by the same threat actor. While the malicious attachments are unique for each recipient, they drop the same malware which beacons using HTTP to a small set of C2s that were successfully identified by both parties. The email addresses used by the attacker are different but not the MTA. Moreover, the email subjects have the same pattern.

In this situation, using the current TH version (2.9.0), the analysts’ hands are kind of tied. They may close the second case after manually copying the observables that were created out of the new MISP event to the case opened by Antoine for example. What a hassle. It kinds of defeat the productivity boost they were expecting by choosing TH.

Enters case merging.

In TH version 2.9.1, which will be released in a few days, the StarGazer team will be able to merge both cases very simply, creating a new one, without losing observables, tasks or their associated logs. So even if a new MISP event pops up hours or days later, they will be able to create a case out of it and merge the case right away with an existing one if similarities are found. And spotting similarities is quite easy with TH since when you create and update a case, the Web UI Case View will tell you if there are look-alike cases based on observables. You can also navigate to the observables tab of the new case, choose to display 100 at a time and see if most observables have an ‘eye’ icon associated with them (which means they have already been seen). Of course, this second method is not ideal and if you want be thorough you’d want to review if all the observables have an ‘eye’ icon.

Case merging will not be limited to cases created out of MISP events. You may use this feature for any case that you have created in TH.

But what happens if, after merging, the MISP event that was used to create one of the original cases is updated and new attributes have been added to it? As this reporter was pestering the chefs with questions, they asked him to leave the kitchen since they were putting the very last touches to the recipe so he complied.

Well, all we have to do is grab a nice table, put a napkin on our lap, and wait for the new version to be served. Maybe then our question will be answered.