Merge pull request #56 from redBorder/Feature/#18101_add_incidents

Feature/#18101 add incidents

build_pdf/redborder_manual_book/en.yml

@@ -32,6 +32,7 @@ nav:
   - manager/more_in_detail/ch4_5_views.md
   - manager/more_in_detail/ch4_12_anomalies.md
   - manager/more_in_detail/ch5_dashboards.md
+  - manager/more_in_detail/ch5_1_incidents.md
   - manager/platform_configurations/ch6_sensors.md
   - manager/platform_configurations/ch7_tools_and_admin.md
   - manager/platform_configurations/ch7_4_general_config.md

build_pdf/redborder_manual_book/es.yml

@@ -32,6 +32,7 @@ nav:
   - manager/more_in_detail/ch4_5_views.es.md
   - manager/more_in_detail/ch4_12_anomalies.es.md
   - manager/more_in_detail/ch5_dashboards.es.md
+  - manager/more_in_detail/ch5_1_incidents.es.md
   - manager/platform_configurations/ch6_sensors.es.md
   - manager/platform_configurations/ch7_tools_and_admin.es.md
   - manager/platform_configurations/ch7_4_general_config.es.md

docs/guides/use_cases/ch9_detect_eternalblue.es.md

@@ -1,39 +1,94 @@
-# Detectar un ataque de Eternalblue con Redborder
+# Detección de un ataque Eternalblue con Redborder
 
-En este caso, veremos cómo Redborder puede usar las reglas de Snort para detectar un ataque de *Eternalblue*.
+En este caso, veremos cómo gestionar un incidente de ataque *Eternalblue*.
 
-Todo comienza con un correo electrónico malicioso que contiene un *dropper* que instala un *ransomware*.
+!!! info "Tenga en cuenta..."
+    Este caso está basado en un incidente real, pero las capturas tomadas corresponden enteramente a una simulación.
+
+## Contexto
+
+Todo comienza con un correo electrónico de phishing malicioso que contiene un *dropper* que instala un *ransomware*.
 
 El *ransomware* intentará utilizar un *exploit* conocido para tomar el control de todas las máquinas posibles.
 
 ![Ataque Eternalblue: escenario](images/ch09_img016.png)
 
 Ataque Eternalblue: escenario
 
-Redborder puede usar las reglas de Snort para detectar la respuesta de eco del protocolo *SMBv1* utilizada por el *ransomware*, por lo que podemos usar el módulo de intrusión para ver las firmas para identificar el ataque.
+## Gestión de Incidentes
+
+En la vista de incidentes, ha aparecido un nuevo incidente que necesita ser investigado. En este caso, tú eres el encargado de hacerlo.
+
+![Lista de Incidentes](images/eternalblue_incident_list.png)
+
+*Lista de Incidentes*
+
+Al hacer clic en el incidente se mostrarán los detalles del mismo. Comenzando por la visión general, puedes ver que el incidente está afectando a *algunas* máquinas.
+
+![Resumen del Incidente](images/eternalblue_incident_overview.png)
+
+*Resumen del Incidente*
+
+A partir de aquí, se puede deducir que el ataque es importante porque puede estar afectando a muchas máquinas.
+
+## Iniciar la investigación
+
+Puedes decidir iniciar la investigación manteniendo el incidente abierto. Sin embargo, en otras situaciones, puedes decidir rechazar el incidente porque es un falso positivo o trasladar la tarea a otra persona como informar del incidente. Hagas lo que hagas, añade la nota correspondiente en el **playbook**, en la sección **Respuesta**.
+
+![Respuesta al incidente](images/eternalblue_incident_response.png)
+
+*Respuesta al incidente*
 
-![Ataque Eternalblue: intrusión](images/ch09_img017.png)
+![Primeras notas](images/eternalblue_first_notes.png)
 
-Ataque Eternalblue: intrusión
+*Primeras notas*
+
+Las notas pueden ampliarse en función de la información que tengas, como módulos extra, acceso a la máquina física o fuentes externas. Pero el lugar más interesante para revisar es la fuente de datos correspondiente, que en este caso es **redBorder Intrusion**. Al hacer clic en ella, te redirigirá a la vista correspondiente.
+
+## Entrando en la fuente
+
+Redborder puede utilizar reglas Snort para detectar la respuesta de eco del protocolo *SMBv1* utilizada por el *ransomware*, por lo que podemos utilizar el módulo de intrusión para ver las firmas que identifican el ataque.
+
+![Ataque Eternalblue: Intrusión](images/ch09_img017.png)
+
+Ataque Eternalblue: Intrusión
 
 Aquí podemos ver las firmas actuales recopiladas por Redborder.
 
-![Ataque Eternalblue: filtrando firmas](images/ch09_img018.png)
+![Ataque Eternalblue: filtrando firma](images/ch09_img018.png)
 
-Ataque Eternalblue: filtrando firmas
+Ataque Eternalblue: filtrando firma
 
-Una vez que hayamos filtrado la firma de *Eternalblue*, podemos mostrar la métrica *SRC Address* para rastrear las IP involucradas en el ataque.
+Una vez que hemos filtrado la firma de *Eternalblue*, podemos mostrar la métrica de Dirección SRC para rastrear las IPs involucradas en el ataque.
 
-![Ataque Eternalblue: selección de métrica SRC Address](images/ch09_img019.png)
+![Ataque Eternalblue: seleccionando métrica de Dirección SRC](images/ch09_img019.png)
 
-Ataque Eternalblue: selección de métrica SRC Address
+Ataque Eternalblue: seleccionando métrica de Dirección SRC
 
-Ahora tenemos las IP de las máquinas involucradas, por lo que es posible tomar medidas para resolver el agujero de seguridad.
+Ahora tenemos las IPs de las máquinas involucradas, por lo que es posible tomar acciones para resolver el agujero de seguridad.
 
-![Ataque Eternalblue: IPs envueltas en el ataque](images/ch09_img020.png)
+![Ataque Eternalblue: IPs involucradas en el ataque](images/ch09_img020.png)
 
-Ataque Eternalblue: IPs envueltas en el ataque
+Ataque Eternalblue: IPs involucradas en el ataque
 
 !!! info "Ten en cuenta..."
+
+    Es importante tener una versión actualizada de las reglas Snort para detectar comportamientos y tráfico extraños con Redborder.
+
+## Volver al informe
+
+Volviendo a la vista de respuesta al incidente, debes añadir las notas sobre la investigación. En este caso, puedes informar de las IPs de origen descubiertas.
+
+![Añadiendo notas de hosts afectados](images/eternalblue_affected_notes.png)
+
+*Añadiendo notas de hosts afectados*
+
+E informar que el siguiente usuario necesita revisar esos hosts para iniciar la siguiente fase del incidente.
+
+![Confirmar notas del incidente](images/eternalblue_confirm_notes.png)
+
+*Confirmar notas del incidente*
+
+## ¿Qué sigue?
 
-    Es importante tener una versión actualizada de las reglas de Snort para detectar comportamientos extraños y tráfico con Redborder.
+Se espera que el usuario informado recoja el incidente en este estado e inicie la fase de contención del malware, empezando por aislar las máquinas afectadas.

docs/guides/use_cases/ch9_detect_eternalblue.md

@@ -1,6 +1,11 @@
 # Detecting an Eternalblue Attack with Redborder
 
-In this case, we will see how Redborder can use Snort rules to detect an *Eternalblue* attack.
+In this case, we will see how to manage an *Eternalblue* attack incident. 
+
+!!! info "Please note..."
+    This case is based on a real incident, but captures taken corresponds entirely to a simulation.
+
+## Context
 
 It all starts with a malicious phishing email which contains a *dropper* that installs *ransomware*.
 
@@ -10,6 +15,38 @@ The *ransomware* will try to use a known *exploit* to take control of all possib
 
 Eternalblue attack: scenario
 
+## Incident Management
+
+On incidents view, a new incident has appeared that needs to be investigated. In this case, you are the one in charge of it.
+
+![Incident List](images/eternalblue_incident_list.png)
+
+*Incident List*
+
+Clicking on the incident will show the details of the incident. Starting from the overview, you can see the incident is affecting to SOME machines.
+
+![Incident Overview](images/eternalblue_incident_overview.png)
+
+*Incident Overview*
+
+From here, you can deduce that the attack is important because it can be affecting to a lot of machines.
+
+## Start the investigation
+
+You can decide to start the investigation by keeping the incident open. However, in other situations, you can decide to reject the incident because it is a false positive or move the task to another person as reporting the incident. Whatever you do, add the corresponding note in the playbook, in the **Response** section.
+
+![Incident response](images/eternalblue_incident_response.png)
+
+*Incident response*
+
+![First notes](images/eternalblue_first_notes.png)
+
+*First notes*
+
+Notes can be expanded based on the information you have, as extra modules, access to the physical machine or external sources. But the most interesting place to look at is the corresponding source, which in this case is **redBorder Intrusion**. By clicking on it, it will redirect you to the corresponding view.
+
+## Getting into the source
+
 Redborder can use Snort rules to detect the *SMBv1* protocol echo response used by the *ransomware*, so we can use the intrusion module to see the signatures to identify the attack.
 
 ![Eternalblue attack: Intrusion](images/ch09_img017.png)
@@ -37,3 +74,21 @@ Eternalblue attack: IPs involved in the attack
 !!! info "Keep in mind..."
 
     It is important to have an updated version of Snort rules to detect weird behaviour and traffic with Redborder.
+
+## Back to report
+
+Going back to the incident response view, you should add the notes about the investigation. In this case, you can report the Source IPs discovered.
+
+![Adding affected hosts notes](images/eternalblue_affected_notes.png)
+
+*Adding affected hosts notes*
+
+And report that the next user need to review those hosts to start the next phase of the incident.
+
+![Confirm incident notes](images/eternalblue_confirm_notes.png)
+
+*Confirm incident notes*
+
+## What's next?
+
+It is expected that the reported user is picking up the incident on this state and start the containment phase fo the malware, starting with the affected hosts.

docs/index.es.md

@@ -39,7 +39,7 @@ La plataforma cuenta con una función de búsqueda integral. Puede utilizarla pa
 
 Para abrir una página en los resultados de la búsqueda simplemente haga clic (o toque en el móvil) en la página deseada en la lista mostrada.
 
-## Primeros Pasos
+### ¿Qué es lo siguiente?
 
 Si esta es su primera vez visitando esta plataforma de documentación, puede visitar la página [primeros pasos](guides/getting_started/first_steps.es.md) para ver la información inicial para aprender sobre RedBorder.
 

docs/index.md

@@ -39,7 +39,7 @@ The platform features a comprehensive search function. You can use it to quickly
 
 To open a page in the search results, simply click (or tap on mobile) on the desired page in the displayed list.
 
-## First steps
+### What's next
 
 If this is your first time visiting this documentation platform, you can visit the [getting started](guides/getting_started/first_steps.md) page to see initial information when learning about RedBorder.
 

docs/manager/more_in_detail/ch5_1_incidents.es.md

@@ -0,0 +1,123 @@
+# Incidentes
+
+Los incidentes son el punto de entrada principal de la plataforma RedBorder. Son el resultado del análisis de los eventos y alertas generados por el sistema que esperan ser revisados por el usuario, ya sea para ser reportados o descartados.
+
+![Vista de incidentes](images/ch05_1_incidents_view.png)
+*Vista de incidentes*
+
+## Partes de la vista
+
+Puedes ver las diferentes partes de la vista en la imagen anterior:
+
+* Una barra de búsqueda para encontrar un incidente.
+* Una barra de filtros para filtrar los incidentes.
+* La lista de incidentes.
+
+Por defecto, no se aplica ningún filtro y la lista está ordenada por fecha, de más reciente a más antiguo.
+
+## Campos de un incidente
+
+Los campos de un incidente son los siguientes:
+
+* ID: Identificador único del incidente.
+* Prioridad: La prioridad del incidente a gestionar.
+* Nombre: Un nombre explicativo del incidente.
+* Source: La fuente de datos desde la cual se generó el incidente.
+* Creado hace: La fecha y hora en que se detectó el incidente.
+* Asignado: El usuario de la web que tiene actualmente asignado el incidente.
+* Estado: El estado actual del incidente. Los valores posibles incluyen:
+
+Los posibles estados son:
+
+* Nuevo: El incidente ha sido creado pero aún no ha sido revisado.
+* Abierto: El incidente está siendo investigado actualmente.
+* Cerrado: La investigación del incidente está completa y no se requiere ninguna acción adicional.
+* Contención exitosa: El incidente ha sido contenido y se ha evitado que se propague más.
+* Incidente Reportado: El incidente ha sido oficialmente reportado a las partes interesadas o autoridades relevantes.
+* Rechazado: Se ha determinado que el incidente es un falso positivo o no requiere acciones adicionales.
+* Restauración exitosa: Los sistemas y datos afectados por el incidente han sido restaurados exitosamente.
+* Detenido: La investigación o resolución del incidente se ha detenido temporalmente debido a varios factores.
+## Acciones sobre un incidente
+
+Las acciones que se pueden realizar sobre un incidente son las siguientes:
+
+* Hacer clic en el nombre del incidente para ver los detalles del incidente.
+* Hacer clic en la fuente del incidente para ir a la vista de la fuente del incidente.
+* Hacer clic en el estado para cambiar el estado del incidente.
+* Hacer clic en el icono de configuración para comenzar a gestionar el incidente.
+* Hacer clic en el icono de papelera para eliminar el incidente.
+
+Al hacer clic en el nombre del incidente se mostrarán los detalles del incidente, ampliando su explicación. Hacer clic en **Ver Detalle del Incidente** tendrá el mismo efecto que hacer clic en el icono de configuración. En ambos casos, si el estado del incidente era **Nuevo**, cambiará a **Abierto**; y el usuario será asignado a ti mismo.
+
+![Resumen del incidente](images/ch05_1_incident_sum.png)
+
+*Resumen del incidente*
+
+## Adentrándose en el incidente
+
+El propósito principal de esta vista es proporcionar al usuario toda la información sobre el incidente y la posibilidad de documentar el proceso de **detección** y **respuesta**.
+
+![Detalle del incidente](images/ch05_1_incident_detail.png)
+
+*Detalle del incidente*
+
+### Vista general
+
+La visión general del incidente muestra la siguiente información relacionada con el incidente:
+* La lista de **activos**.
+* La lista de **observables**.
+* La lista de **indicadores**.
+
+Además, la información se resume en una vista de gráfico interactivo que permite al usuario ver la conexión entre los observables.
+
+![Visión general del incidente](images/ch05_1_overview.png)
+
+*Visión general del incidente*
+
+### Detección
+
+La sección de detección muestra la lista de alertas relacionadas (mensajes), observables y activos que componen el incidente.
+
+![Detección](images/ch05_1_detection.png)
+
+*Detección del incidente*
+
+### Respuesta
+
+La sección de respuesta muestra un **playbook**, que es una guía estructurada para manejar el incidente. Un playbook proporciona un enfoque sistemático para la respuesta a incidentes, asegurando que todos los pasos necesarios se sigan de manera consistente. Hay diferentes tipos de playbooks, que se definen por el tipo de incidente. El playbook se divide en fases. Cada fase puede tener diferentes tareas a realizar, y cada tarea tiene una descripción y un espacio específico para escribir los comentarios del proceso de respuesta. Se espera que los usuarios ejecuten las fases y tareas en el orden propuesto.
+
+![Respuesta](images/ch05_1_response.png)
+*Respuesta del incidente*
+
+En este ejemplo, el playbook tiene cuatro fases: **Identificación**, **Contención**, **Erradicación** y **Recuperación**. Cada fase tiene una lista de tareas a realizar en orden. El usuario puede agregar comentarios a las tareas y marcarlas como completadas.
+
+### Worklog
+
+El worklog es un registro de las acciones realizadas por cada usuario que trabajó en el incidente. Cualquier cambio en él se registrará y se podrá filtrar y mostrar aquí. Además, cualquier usuario puede agregar comentarios manualmente al worklog según sea necesario.
+
+![Worklog](images/ch05_1_worklog.png)
+
+*Worklog*
+
+#### Búsqueda en el worklog
+
+Los **registros** se pueden filtrar por **Tipo** y **Usuario**, y ordenar por fecha. Hay tres tipos de registros:
+* Cambios en el incidente: Estos registros son generados automáticamente por el sistema cuando cambia el estado del incidente, como cuando cambia el estado o el usuario.
+* Registros de respuesta: Estos son agregados manualmente por el usuario durante el proceso de investigación y respuesta.
+* Notas: Además, el usuario puede agregar notas manualmente al worklog. Útil cuando la información detallada no encaja en el resto de los tipos.
+
+#### Agregar notas
+
+Además, el usuario puede agregar notas al worklog. Al hacer clic en **Agregar Nota**, aparecerá el editor de texto para agregar la nota. La nota se agregará al worklog después de hacer clic en **Guardar**. El editor de texto tiene características útiles como:
+* Insertar enlaces
+* Insertar bloques de código y otro texto formateado
+* Adjuntar archivos
+* Entre otras opciones
+
+![Agregar nota](images/ch05_1_add_note.png)
+
+*Agregar nota*
+
+# ¿Qué es lo siguiente?
+
+Ve a la sección de **Incidentes** para comenzar a gestionar un incidente. El playbook probablemente te guiará para ver la **fuente** del incidente. O ve a **Herramientas/Playbooks** para definir nuevos playbooks para nuevos tipos de incidentes.