TL;DR
Previous blogs:
- https://jstnk9.github.io/jstnk9/blog/TIBER-EU-ES-Threat-Intelligence-Series-01
- https://jstnk9.github.io/jstnk9/blog/TIBER-EU-ES-Red-Team-Series-01
This is the last entry related to TIBER-EU and TIBER-ES. So far we have seen the processes related to Threat Intelligence and Red Team. Now it is the turn to learn about the Blue Team process, which, unlike the last two, is the Entity Blue Team itself. This team can be outsourced or belong to Entity itself, and its objective is to detect and defend the Entity business in case of an attack.
During the implementation of TIBER-EU, the Blue Team is not aware that any penetration test will be performed, so they must be able to detect the attacks performed by the Red Team provider. Subsequently, they must generate reports relating the Red Team's attacks to the Blue Team's findings.
As I did in the previous case, I have developed some cases in the The Hive tool so that blue team teams can import them quickly and know the different actions that they have to carry out, thus allowing the use of the Task logs to document and attach everything that they carry out on the test.
The developed cases contemplate all the phases that TIBER-EU mentions in its documentation, in addition I have also included good practices and ways of facing some phases.
The fact of using The Hive is due to the following reasons:
- Allows to merge cases
- Can be integrated with MISP
- Can be integrated with Cortex and its analyzers
- Case templates can be created
GitHub project: https://github.com/jstnk9/TIBER-Cases
Abbreviations
| Key | Description |
|---|---|
| Entity | The term Entity during this blog and The Hive cases, refers to the entity that is going to carry out the TIBER-EU exercises. |
| TI | Threat Intelligence Provider. Is the provider of threat intelligence services for the Entity. |
| RT | Red Team Provider. Is the provider of red teaming services for the Entity. |
| WT | White Team. Team responsible of the scope and operative execution of the exercises. |
| BT | Blue Team. Team without knowledge about the exercise which have to respond to the attacks by the RT. |
Context
During this blog I will not go into detail about what TIBER-EU or TIBER-ES is. I will simply mention that TIBER-EU is a European framework for testing red teaming with a threat intelligence approach. This approach is related to Lockheed Martin's well-known Intelligence Driven Defense® method.
The offensive tests will be from the perspective of actual attacks with procedures used by actors targeting the financial sector. For more information, I recommend reading the TIBER-EU and TIBER-ES guides.
info
TIBER-EU Information: https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
TIBER-ES Information: https://www.bde.es/bde/es/secciones/servicios/tiber-es-3f6bfe7e907ed71.html
Goal of this project and blog
The main objective of this project is to help blue team analysts during the blue team closure phase (so called by TIBER-EU). For this purpose, different cases are made available which can be imported into The Hive in order to speed up the work.
For this purpose, a total of 3 cases have been developed, which have sub-tasks assigned so that blue team analysts can execute their actions from there. Additionally, there are some tasks where the participation of red team and detection engineering analysts is required.
Finally, in the phases and steps that come in this blog, I will not go into too much detail about what to do, since, in the very cases I have developed from The Hive, I put the necessary information for the analysts.
Process
The process that TIBER-EU defines for the blue team during the closure phase is as shown below:
Source: ecb.europa.eu
To simplify the entire TIBER-EU document and the blue team section a bit, I wanted to make a process explaining the most important points of the framework for those analysts who are going to work on it. Specifically, I have focused on the "Processes/Activities Closure Phase" section of the official TIBER-EU process.
Notify the blue team of the tests performed
First, after the red team has executed the tests as discussed in the previous entry, it must notify the blue team about the exercises performed.
The ideal scenario is that the blue team knows without warning that they are under attack (always, without knowing that the TIBER processes are running). This will mean that there are detection mechanisms in place for some of the steps performed by the red team.
in any case, the blue team must know the tests that the red team performed during its testing phase once it is finished, and for this purpose, they must receive a copy of the complete report made by the red team (red team report).
In many cases, the blue team will be an internal Entity team, in other cases, this team will be an outsourced team providing services to the Entity being targeted by the TIBER-EU Framework.
Blue Team Report
This phase is very important for the blue team.
As a red teamer, your goal is to help the blue team and explain in as much detail as possible the steps taken during the testing phase. Think that this collaboration with the blue team will be key to improve the security posture and minimize risks in the Entity.
As a blue teamer, your objective is to relate each step taken by the red teamer to possible detections in your technology that evidence the step taken by the red teamer.
By detection we mean that there is some kind of notification or something similar where it indicates that suspicious behavior has been detected. Usually these detections cover some kind of pattern previously generated either by an Entity analyst or by the vendor providing the solution.
Once we have a list of those steps detected and those steps not detected, let's focus on those NOT detected. For those tests performed by the red team where there was no detection, we must ask ourselves the following question... Did I not detect it because there is no visibility, or because there is no detection mechanism?.
First, it is advisable to review those gaps and map them to a data source, i.e., a technology or feature of the operating system that might know that the technique was executed. For example, if we are looking for process injection, we might have a chance for visibility through
- Windows API calls
- Process modification
- Process access
According to ATT&CK MITRE, the above three points could help us to identify the T1055.003 technique. Therefore, as a blue teamer, we have to keep this information in mind so that later, in the next phases when the red team repeats the test, we look at those places where we can see the executed step.
Replay the test
In this case, the blue teamers have to be able to at least see some kind of evidence in the steps repeated by the red team. That would mean that there is at least some kind of visibility.
In case there is no evidence on a step performed by the red team, it could mean that there is no visibility, which would mean either acquiring new technology to fill the gap or asking possible engineering teams from the Entity to fill the visibility gap.
There is a lot of technology and each one uses different formats for the generation of detections, therefore, it is recommended to use SIGMA Rules for those cases where the detection can be covered with this scheme. This could later help us when translating the detection to our technology using sigmac and/or uncoder.io.
For the development of detections, there must be a previous investigation, where the analysts must be able to cover the required behavior and with the least possible number (or none at all) of false positives. In this way, we will avoid a lot of unnecessary noise and possible alert fatigue.
Finally, the implementation of the developed detections should be carried out. In this case, there may be different teams responsible for this work, depending on each entity, the team may vary.
Remediation Plan and Test Summary Report
The blue team is not the only stakeholder for this phase. In this case, IR, Threat Intelligence, SOC, Architecture teams, etc. must be involved and coordinated to develop a remediation plan based on those vulnerabilities and failures identified during the red team tests.
The reports that must be generated in this case are the following:
Remediation Plan: The Remediation Plan is based on the test results, which should be used in turn to support the business case for implementing improvements to mitigate the vulnerabilities identified during the TIBER-EU test.
Test Summary Report: The Test Summary Report summarises the overall test process and results (including the Remediation Plan) and should draw on the test documentation, such as the Red Team Test Report, the Blue Team Report, the TTI Report, the Red Team Test Plan and the Remediation Plan. The Test Summary Report should not contain detailed technical information and findings regarding weaknesses and vulnerabilities, as information at that level of detail is highly sensitive and for the entity only. The entity must share the Test Summary Report with the lead authority. The lead authority may also review the more detailed findings from the test if this is deemed necessary.
Import case in The Hive
Version of The Hive used:
Scalligraph: 0.1.0-SNAPSHOT
TheHive: 4.1.18-1
Play: 2.8.7
Before you begin, I highly recommend following the guide below to import the ATT&CK MITRE Matrix and MISP taxonomies into The Hive. To do this, go to the following links.
info
To import the cases, you must have permissions to perform this task. To do this, you must first navigate to the Organization section that is located at the top next to the search bar.
Once inside that section, we will have to go to the section that says Import template and select the JSON files that are in my GitHub, specifically in the cases folder.
Once this is done, and when we click on the upper part where it says + New Case, all the imported cases will appear with the information about the TIBER-EU phases.
Case previsualization
As an example, once the cases are imported and one is generated to start working on it, they look like the following image:
As can be seen, it contains all the information the analyst needs to start working. The way cases are written is by using markdown.
When clicking on tasks, the user can see the following information.
All the Tasks that are included in each case have dependencies and goals, this will help the analysts not lose focus and focus on the goals to be achieved.
Cases information
Here you can find basic information about the created cases. Case name is the name defined for each case. Each case has different tasks to complete. You'll find all the information in the json files.
- Blue Team Report
- Red Team Replay
- Remediation Plan and Test Summary Report
Case name: Closure Blue Team #1 - Report
Tasks:
🔎 JSON File
Case name: Closure Blue Team #2 - Replay
Tasks:
🔎 JSON File
Case name:Closure Blue Team #3 - Remediation Plan and Test Summary Report
Tasks:
🔎 JSON File
Contact
Twitter: https://twitter.com/Joseliyo_Jstnk
LinkedIn: https://www.linkedin.com/in/joseluissm/
GitHub Project: https://github.com/jstnk9/TIBER-Cases