Resolución de problemas de seguridad

Descripción general — qué hace

Seguridad ▸ Resolución de problemas gestiona la respuesta a incidentes y brechas de seguridad como un único tablero de casos con una tubería de cinco etapas:

open → investigating → cause_identified → resolved → closed

Cada caso lleva una estructura de informe 500 (causa directa / causa raíz / resolución / acción preventiva) y una línea de tiempo auditable. Esta pantalla es un espejo del controlador de Servicio ▸ Resolución de problemas: comparte la misma tabla infr_incident, pero filtra por area='security' para mantener los casos de seguridad separados de los incidentes de servicio.

Los casos llegan a este tablero por dos vías:

1. Alta manual — un operador crea el caso. Orígenes seleccionables: manual · agency · quarantine.
2. Promoción desde el diagnóstico — los hallazgos fail + crit del Diagnóstico de seguridad se promueven automáticamente a casos (source=detection). Es un origen exclusivo del sistema que los operadores no pueden elegir a mano.

Esta consola no toca directamente el crontab ni los cortafuegos remotos. Es una herramienta de flujo de trabajo que registra y hace seguimiento del proceso de respuesta humano. Las acciones reales de bloqueo o cuarentena están en Lista de bloqueo y Bloqueo automático.

Cuándo utilizarla

• Para promover una sospecha de brecha confirmada procedente de la detección IDS/IA (Amenazas, Detecciones · JA3) a un caso formal con su rastro de investigación y resolución.
• Para hacer seguimiento de solicitudes de cooperación o notificaciones de brecha de una agency (CERT, fuerzas de seguridad).
• Para gestionar un host desde la quarantine hasta su recuperación y nueva puesta en servicio.
• Para recibir como casos creados automáticamente los riesgos de bastionado o de rootkit marcados con fail+crit por el Diagnóstico de seguridad y asignar su seguimiento.
• Para calcular a posteriori el MTTR y el tiempo de caída acumulado, y documentar las causas directas y raíz junto con las acciones preventivas.

Disposición

Franja de KPI

Tablero de casos

Los casos se ordenan por:

1. Rango de estado — open → investigating → cause_identified → resolved → closed
2. Rango de gravedad — crit → warn → info
3. Más recientes primero — id descendente

Cada tarjeta muestra el título, la gravedad, el estado, la etiqueta de origen, el proyecto o servicio vinculado, la hora de ocurrencia, el tiempo de caída y el número de eventos.

Ventana de detalle

Al abrir un caso, la ventana se divide en dos paneles:

• Informe — campos de resumen, causa directa, causa raíz, resolución y acción preventiva.
• Línea de tiempo — historial de infr_incident_event (creación, nota, cambio de estado, …) en orden cronológico.

Al pulsar la tubería de estados de la parte superior se abre un diálogo de transición de etapa que muestra la guía de «qué hacer en esta etapa» y permite actualizar en línea los campos de informe de esa etapa.

Cómo utilizarla

Crear un caso (manual)

1. Pulse [Registrar caso] en la parte superior.
2. Introduzca el título (obligatorio), la gravedad y el origen (manual / agency / quarantine).
3. Opcionalmente, indique proyecto, servicio, URL, hora de ocurrencia, impacto y tiempo de caída (minutos).
4. [Guardar] — se crea un caso nuevo con status=open, area=security y detected_at=now(), y se escribe un evento created en la línea de tiempo.

detection no aparece en la lista de orígenes: es un origen exclusivo del sistema que el Diagnóstico de seguridad genera automáticamente.

Transiciones de estado (tubería)

Pulse el estado de destino en la tubería de la ventana de detalle. Trabajo recomendado en cada etapa:

Reglas de transición del lado del servidor:

• Al pasar a resolved, se rellena resolved_at con now() si estaba vacío.
• Al pasar a closed, se utiliza el valor de fecha de cierre del diálogo si se ha indicado; en caso contrario se toma now() por defecto cuando no existe ningún valor.
• Cuando el estado cambia realmente, se escribe un evento status_change (from→to) en la línea de tiempo; si además se aporta una nota, se añade un evento note.

Notas de colaboración

Añadir una nota en la ventana de detalle registra un evento kind=note en la línea de tiempo. No existe una tabla de notas independiente: las notas se consolidan en infr_incident_event.

Eliminación

Al eliminar un caso se eliminan también sus filas de infr_incident_event y la acción queda escrita en el registro de auditoría. (El análisis de diagnóstico original que hay detrás de un caso promovido es independiente y no se elimina.)

Resolución automática de los casos promovidos

Cuando el Diagnóstico de seguridad ingiere el resultado de una sonda, DiagnosticsService::reconcileCases() reconcilia los casos por host:

• Un hallazgo fail + crit → hace upsert de un caso abierto identificado por fingerprint (una reaparición incrementa occurrence_count).
• Cuando un análisis posterior supera esa comprobación o esta desaparece → el caso abierto se resuelve automáticamente (status=resolved, resolved_at, resolution=auto-resolved text) con un evento status_change en la línea de tiempo.

La resolución automática solo se dispara cuando la comprobación de diagnóstico vuelve a superarse. Los casos creados manualmente (manual/agency/quarantine) nunca se resuelven de forma automática: un operador debe hacerlos avanzar por la tubería.

Fuentes de datos

Tablas

Enumeraciones

STATUSES   = [open, investigating, cause_identified, resolved, closed]
SEVERITIES = [info, warn, crit]
SOURCES    = [manual, pulse, alert, agency, quarantine, detection]   # todos
manual-selectable sources = [manual, agency, quarantine]
OPEN_STATUSES (dedup targets) = [open, investigating, cause_identified]
AREAS = [service, security]   # eje de división de la tabla compartida

Campos del informe (estructura 500)

Puntos de la API

Acceso

• Lectura: todo el grupo de Seguridad está protegido por el middleware infr.level:2. Solo pueden entrar los usuarios de nivel 2 o superior (staff=5 · admin=10); la demo (1) queda bloqueada.
• Escritura (guardar/transición/nota/eliminar): el método canWrite() del controlador vuelve a comprobar el infr_user_level >= 2 de la sesión. Por debajo de ese nivel devuelve 403 (resolution.err.forbidden).
• Auditoría: toda escritura queda registrada en infr_audit_log — sec.incident_create · sec.incident_update · sec.incident_transition · sec.incident_delete. Las transiciones guardan {from,to} y los guardados {title,severity} en los metadatos. Véase Registro de auditoría.

Resolución de incidencias y preguntas frecuentes

P. Un caso que veo en el tablero de Servicio no aparece aquí. Ambos tableros comparten la misma tabla infr_incident, pero se separan por area. Esta pantalla muestra únicamente area='security'. Encontrará los incidentes de servicio en Servicio ▸ Resolución de problemas.

P. No puedo crear un caso con el origen detection. Es el comportamiento esperado. detection es un origen exclusivo del sistema que el Diagnóstico de seguridad crea automáticamente a partir de los hallazgos fail+crit. El alta manual solo ofrece manual, agency y quarantine.

P. Un caso promovido automáticamente ha pasado él solo a resuelto. Cuando la comprobación de diagnóstico subyacente se supera en un análisis posterior, reconcileCases() resuelve automáticamente el caso abierto: resolution se rellena con el texto de resolución automática y se añade un evento de cambio de estado.

P. El MTTR aparece en blanco. El MTTR solo se calcula para los casos que tienen a la vez occurred_at y resolved_at. Los casos sin hora de ocurrencia, o aún sin resolver, quedan excluidos.

P. ¿Puedo indicar una fecha de cierre pasada? Sí. Introduzca un valor en el campo fecha de cierre del diálogo de cierre (la misma interfaz que la hora de ocurrencia) y se guardará tal cual. Si lo deja vacío, el servidor rellena now() solo si todavía no existe ningún valor.

P. ¿Eliminar un caso elimina también su análisis de diagnóstico? No. Un caso promovido y el análisis de diagnóstico que lo originó son independientes. Al eliminar un caso solo se eliminan los eventos de línea de tiempo vinculados a él.

Contenido relacionado

• Diagnóstico de seguridad — el origen que promueve automáticamente a este tablero los hallazgos fail+crit.
• Resolución de problemas de servicio — el espejo del mismo flujo de trabajo en el lado del servicio (area='service').
• Resumen de seguridad — el relato del embudo de defensa amenaza → detección → respuesta.
• Amenazas · Detecciones · JA3 — fuentes de candidatos a brecha que promover a casos.
• Registro de auditoría — el registro persistente de las acciones de escritura sobre los casos.