In my last post about the MITRE attack Navigator I covered how you can create multiple layers and then aggregate them together which is all well and good until you realise, that if you wanted to see that level of detail each time you accessed the Attack Navigator you need to specify that json file. This is where this post comes in. Its quite a straight forward process to host your own navigator and further customise it to suit your needs.
MITRE ATT&CK. Its the bread and butter for Security Operations Centres. But how are you tracking what you can detect? Does your SIEM have a built in tool?, Perhaps you have you straight up copied the matrix into Excel? or keeping score in a text file? You may or may not be aware of the online version of the MITRE Navigator. Theres heaps of functionality, allowing you to apply custom colors, heat mapping to score tallies, show all the tactic/technique ID’s as well as export functionality to Excel/SVG/JSON.
So I wanted to do something which has been done many times before and that was to create an SSH honeypot for some threat intelligence collection purposes. The twist to this is that I want to send the results to MISP and I came across a few hicups along the way. Ive previously blogged about Fail2Ban and it got me thinking, what if I added a secondary action to send the resulting banned ip into MISP.
When it comes to online applications some of the best functionality comes when you can programmatically tap into it as it creates countless opportunities to customise and extend the functionality to suit your needs without having to modify the underlying application. In the Context of TheHive, the API will allow you to query, post or search data which can aid in the lifecycle of an incident as well as create alerts and cases programmatically.
I’ll start by saying, that I have done these sorts of posts in the past where I have stood up TheHive and reverse proxies etc using a docker-compose file so the basic configuration etc is going to be heavily borrowed except for some minor tweaks. I am still old school so this isnt a configuration you would want to run for mission critical services, however there is a guide for how to use Docker in Production.
TheHive. You know i’m a huge fan of this Incident Response platform with many blog posts dedicated to it including how you can integrate and interface with it. Over the years TheHive has been on a journey and has matured and stabalised. Now with a new code base the developers have taken full control of the licensing for version 5. I do however have mixed feelings about this. On one hand i’m sad that TheHive no longer open source.
In my last post, I covered how I went about upgrading TheHive from 3.4 to 3.5RC1 along with a double upgrade of Elasticsearch. Well now its Cortex’s time. Cortex 3.1.0 also uses Elasticsearch 7.8 so we are in for a similar upgrade process. Depending on your reliance on Cortex it may be a nice addition to TheHive that is rarely used, or it may be critical to your operation. Either way, getting to the latest version is desirable as there are always welcome bug fixes and improvements with error handling, reporting and general integration.
TheHive 3.5.0 RC1 has now been released and my environment is in a bit of a shambles for this upgrade. You see when I performed my upgrade of TheHive 3.2.1 to 3.4.0 I elected to not upgrade to ElasticSearch 6.8 at the time as I wanted to do some more testing on it. I told myself, TheHive 3.4 was working just fine using Elasticsearch 5.6, so I never went ahead with the Elastic part of the upgrade.
Well its been a few months since I have written anything on my blog. Its not that I’ve been lazy, well OK its because I’ve been a little lazy and that I have been chasing squirrels and playing around with Home-Assistant and other various pieces since being in lockdown. I have also lacked the motivation to get something down in writing. Anyway, on with what I wanted to write about….
With my Java issue sorted out now, here are the steps to upgrade TheHive from RC1 to RC2. This is a dirty upgrade, but since TheHive is still in Release Candidate status, we can get away with upgrading like this. Ordinarily you should ensure that you have your system backed up in case there are breaking changes. Stop TheHive service sudo service thehive stop Update apt repositories and upgrade May as well apply all the security updates while I am at it.
I was so excited at the thought of all the cool new features that have popped up in TheHive v4.0.0-RC2 that I went straight onto my lab to give it a spin. Little did I know that my system was broken before I even started and I spent the best part of a few hours trying to figure out what exactly happened. For a brief moment I did consider burning the lab down and just rebuilding it, but I asked myself what would happen if this were a prod system?
Docker is something that i’ve not fully embraced to date, I know, I know… I’m a little late off the mark, but as I get to know Docker more, I can see that it has some worthwhile advantages for me in some of the projects I use and generally getting to know technology is never a bad thing. For instance, why spin up a single server for a service that only has 1 of the 65535 ports used when 99% of the time that server will most likely be idle.
Template by Bootstrapious. Ported to Hugo by DevCows
