Course Introduction

This course is a mix of theoretical concepts, implementation, and operational instructions designed to help you understand how Incident Management is implemented and managed within eramba.

The course follows a logical progression through three main pillars:

1. Theoretical Concepts: The underlying logic and Incident methodology.

2. Common Features: Explains how common features (Notifications, Reports, etc.) apply to this use case with multiple examples.

3. Implementation Steps: The technical implementation of the module step by step.

4. Operational Steps: The day-to-day activities required to manage Incidents.

To successfully navigate this course, you will need to reference two additional types of documentation:

• Common Features: These are universal functionalities found across almost every eramba module. Examples include Notifications, Reports, Custom Fields, and the API.

• Related Modules: These are supporting modules that relate to Incidents

LLMs

Statistically, most people don’t "read" — and certainly don’t fully "understand" — documentation. If you’re planning to take this course be assured you will get in trouble.

You can use LLMs to clarify doubts from what you "read" to make sure you "understand", you simply need to copy the URL and paste it into your preferred LLM (OpenAI, Gemini, etc.) together with the prompt below:

I’m trying to understand how Incident Management works and how it’s implemented in Eramba. This is their documentation. If you’re able to review it, can you answer any quick questions I may have? This is the URL: (paste url here)

If you are somewhat diligent and careful on your questions you will get a lot of support from your LLM.

You can then ask questions a bit like if you would be asking them on a demo call:

Typical Scenarios

This use case allows you to work with the following common situations:

• Record incidents and their lifecycle. These incidents do not necessarily have to be cybersecurity-related; they can be business, technology, etc.

• Define custom stages that every incident must go through in order to manage them systematically.

• The Incident module helps address multiple compliance requirements from well-known standards such as PCI, ISO 27001, DORA, NIS2, SOC 2, etc.

• With the use of automations, you can receive incidents from SIEM tools, trigger notifications, etc.

Supported Versions

Incident Management runs on both on-premise and cloud deployments and is available in Enterprise and Community editions. Community limitations relate to common functionalities (notifications, reporting, etc), not related modules, as most of these features are not included.

Theory

Concepts

This is a summary of the key topics for this use case:

• You can document any type of incident.

• You can classify the incident as Incident, Event, or Possible Incident; these cannot be changed.

• Incidents can be “Open” or “Closed.”

• You can (optionally) define as many stages as you want. They have a title and description, and these stages will be attached automatically to every incident.

• Stages are “Incomplete” by default until you work with them and switch them to “Complete.”

• Once all stages are “Completed,” you can “Close” the incident.

• Incidents can have related known risks, which can include optional playbooks that will be displayed when you create a risk.

• The module supports REST APIs for incident synchronization.

Module Relationships

The Incident module can work on its own without any related modules, which allows you to document simple incidents. Alternatively, you can optionally define predefined “Stages” that will be applied to every incident you create.

These “Stages” are the typical stages an incident goes through in its lifecycle (Identification, Containment, etc.). The screenshot above shows the stages defined in the settings module and how the created incident has them associated with it.

The Incident module can also link optionally to the Risk module (all three), because risks provide information about problems you knew could affect your organization. You may also have associated a policy describing a “playbook” that must be followed if the scenario becomes a reality.

When the incident is created, if you enable playbooks, you can select one or more related risks. If these risks have associated playbooks, they will be shown to you in a way that helps your incident handler know how to deal with the incident.

Status

It essential to understand the Dynamic Status common feature before making configuration decisions.

There are multiple pre-defined statuses on the Incident and Stages modules, they help you understand where you are with these items. On the incident module the more relevants are "Open", "Closed" and "Lifecycle Incomplete" (when the incident has incomplete stages associated).

On the Stages tab you will see two statuses "Complete" and "Incomplete" depending if the stage status

Stages

As discussed, stages are optional. You can create, edit, and save incidents without using them. The reason you might want to use them is to make sure all incidents are processed systematically. Stages are defined under Settings / Stages and include only a “Name” and “Description.”

You might want to change stages after had created many incidents, if that happens the changes you made to ezisting stages, created stages, etc can apply to existing stages too not just new ones. When saving you will get a confirmation modal where you can choose what you want to do.

Once incidents are created, the stages will be automatically created and associated with the incident. You can access these stages from the “Incident” module using “Shortcuts” or by directly opening the “Stages” tab in the top menu.

Editing a stage will only allow you to set it to “Complete” or “Incomplete.” Stages can also have comments and attachments associated with them. These comments are typically used to document notes for that particular stage.

Incident Process

The process you should follow to use this module, whether or not you have defined stages, is basically this:

1. When an incident is detected, you create an incident. If you are using playbooks, you search for a risk that might be related to the incident and use the playbook if applicable.

2. When you save the incident with the status set to “Open,” go through each stage by following the instructions there, adding comments and attachments to the stage (updates, feedback, etc.).

3. Once the stage is completed, you can set it to “Complete.”

4. After all stages are “Completed,” you can edit the incident and switch it to “Closed.”

Common Features

Customisation

There are many possibilities when it comes to customisations. It essential to understand the customisation common feature before making configuration decisions.

tbd

Dynamic Status

There are many possibilities when it comes to Dynamic Stauses, in particular using them in combination with Custom Fields, Notifications, Reports and Automations. It essential to understand the Dynamic Status common feature before making configuration decisions.

tbd

Views

Views are essential as is the main interface with data in eramba, you will most likely adjust them to suit your needs. It essential to understand the User Interface guide before making configuration decisions.

tbd

Notifications

There are many possibilities when it comes to notifications. It essential to understand the notification common feature before making configuration decisions.

tbd

Automations

There are many possibilities when it comes to notifications. It essential to understand the Automation common feature before making configuration decisions.

tbd

Reporting

See Reporting documentation

Implementation

tbd

Operation

tbd