4.3. Cases and Log Processing
The Cases section gives a good overview regarding the existing cases and also provides various filtering options. Column visibility can be configured by clicking on the Columns button of this section.
The Cases Section is split into the different sources of your Cases:
Log Watcher Cases (deprecated)
Additionally, you can find more information regarding:
When a case is created, the state will be "Open" and the type will be set to "Noteworthy" by default.
The following states can be set (by default):
Level 1 Finished
Level 1 Working
Level 2 Working
It is possible to configure custom states.
The following types can be set:
See chapter Glossary for a detailed description of these terms.
Within a case, it is possible to add various information, write a summary, provide canned recommendations or add assessment information.
The log lines contained in the case can of course be analyzed in detail and changes to the case are tracked automatically.
The cockpit will automatically calculate rules (auto_case_id), that
make sure, future incoming logs that are similar to the log lines in
this particular case are automatically assigned to this case and will
not show up in the
Automatically assign newly incoming events to this case needs to
be selected during case creation to automatically assign new events
to an existing case.
In order to understand this better, let's assume you have decided a group of logs are legitimate anomalies. Then all future logs that are similar to these anomalies will automatically be added to this case and not show up in the Baselining section.
In case you have decided a group of log lines represent a security incident, the same thing will happen. Future log lines that represent a security incident will show up only in the case and not in the Baselining section.
Most organizations want to be alerted in case of a security incident. The Cockpit can be configured to forward all logs that are automatically assigned to an incident case to the organizations' SIEM System via syslog. Organizations that prefer to handle THOR Events entirely within the Analysis Cockpit and not forward anything to a SIEM system may choose to configure a notification that shows up in the Cockpit's Notification Section.
The following picture shows the recommended log processing.
As one can see, an incoming log line only shows up in the
section when it matches no existing case.
This behavior is highly configurable and can be changed in the
Settings section of the Analysis Cockpit. One can even decide not to
forward anything to a SIEM System or may decide to also forward
suspicious elements in addition.
In other Words:
Cases represent the means of setting and maintaining the log baseline
within the Cockpit. When you scan your infrastructure once, assign all
logs to cases and then scan it for the second time, the
section should be empty if nothing has changed. All incoming logs should
be similar to the ones in the first scan and therefore be assigned to
the respective cases and not show up in the
Working with cases is explained in detail in the sections below.
4.3.1. Case Templates
Case Templates can be used to suggest new cases in the
section. If there are no Suggested Cases in the view, no events match
the Case Templates in your Analysis Cockpit.
To import new Case Templates, you need to create a
.yaml file with
the conditions first. This can be done by navigating to the
view and exporting your search results as Case Templates. You will
be able to download a
.yaml file from here, which can be used to
import as a Case Template.
2name: Thor started on a system with the wrong processor architecture
7condition: "\"MODULE: Startup\" AND \"MESSAGE: 32 bit THOR was executed on 64 bit
8 system. For improved results, use the 64 bit version of THOR.\"\r\n"
After you downloaded the Case Templates, you can import them in the
You can now inspect the Case Template. You can find it by either looking
for the name or filter by who created it. You can see that the conditions
match the contents of your exported Case Template (