☰ InicioDEFENSA DIGITAL Core
Manual de usuarioManual de administrador

Manual de usuario

DEFENSA DIGITAL Core · 2026-10-02

Esta guía explica, módulo a módulo, qué puede hacer en el día a día. Los iconos ? de cada pantalla abren la ayuda contextual; este manual es la visión de conjunto.

Acceso y roles

Inicie sesión con su correo y contraseña. Su rol determina lo que puede ver y hacer:

  • viewer: Lectura de la mayoría de recursos protegidos mediante current_user; no tiene las acciones de escritura reservadas a analyst/admin/superadmin.
  • analyst: Puede crear y actualizar la mayoría de recursos operativos: activos, vulnerabilidades, reglas, eventos, incidentes, SOAR no aprobador, DFIR, continuidad, recovery, resiliencia, GRC y tickets.
  • admin: Incluye capacidades de analyst y añade aprobaciones, auditoría, gestión de integraciones, diagnóstico y operaciones MSP de consulta.
  • superadmin: Máximo rol de la build. Incluye admin y puede además crear/delegar tenants gestionados desde MSP.

Módulos

Acceso, identidad y roles

Inicia sesión con correo y contraseña. Si una misma identidad existe en más de un tenant, indica el tenant correspondiente. El rol del usuario condiciona las acciones disponibles.

Consultas habituales:

  • Mi sesión — Objetivo: Muestra id, tenant, correo y rol de la identidad autenticada. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/au

Portal y Dashboard

Usa los indicadores para localizar rápidamente activos, vulnerabilidades abiertas, exposiciones críticas, Exposure Score y carga SOC. Los datos del portal pertenecen siempre al tenant de la sesión.

Consultas habituales:

  • Resumen principal — Objetivo: Obtiene los KPIs principales del tenant: activos, vulnerabilidades abiertas, exposiciones críticas, Exposure Score, alertas e incidentes SOC abiertos. Procedimiento: inic
  • Portal — Objetivo: Lista o resume del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (public); accede a /; consultar el recurso o acción; revisa la respuesta y, cua

Inventario de activos

Registra cada activo con nombre, tipo, IP, criticidad, exposición a Internet y propietario. El inventario sirve de contexto para vulnerabilidades, Security Graph y XDR.

Consultas habituales:

  • Assets — Objetivo: Lista o resume Assets del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/assets; consultar

Gestión de vulnerabilidades

Introduce CVE, CVSS, EPSS, explotación conocida y remediación. Core calcula un risk score contextual y permite cambiar el estado de cada vulnerabilidad.

Consultas habituales:

  • Vulns — Objetivo: Lista o resume Vulnerabilities del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/vulnerabi

CTEM

CTEM combina el score de vulnerabilidad con el contexto del activo. La vista de exposiciones ordena los hallazgos abiertos y la acción Recalcular actualiza los scores cuando cambia el contexto.

Consultas habituales:

  • Exposiciones CTEM — Objetivo: Lista vulnerabilidades abiertas ordenadas por risk score e incluye banda de riesgo, CVSS, EPSS y explotación conocida. Procedimiento: inicia sesión con un rol autorizado

Threat Intelligence

Añade tipo de indicador, valor, fuente, confianza, severidad y notas. El registro actual es un repositorio controlado; no implica enriquecimiento externo automático.

Consultas habituales:

  • Threat List — Objetivo: Lista o resume Threat Intel del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/threat-intel

Security Graph

Utiliza relaciones entre activos para documentar dependencias o conectividad. Core comprueba que ambos activos pertenezcan al tenant antes de crear la relación.

Consultas habituales:

  • Ver Security Graph — Objetivo: Devuelve los activos como nodos y sus relaciones como aristas del tenant. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede

SOC / XDR

Crea reglas, ingiere eventos y revisa las alertas generadas. Una alerta puede promoverse a incidente; la promoción es idempotente mientras exista un incidente activo para esa alerta.

Consultas habituales:

  • Detection Rules — Objetivo: Lista o resume Rules del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/soc/rules; consulta
  • Security Events — Objetivo: Lista o resume Events del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/xdr/events; consul
  • Alerts — Objetivo: Lista o resume Alerts del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/soc/alerts; consul
  • Incidents — Objetivo: Lista o resume Incidents del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/soc/incidents;
  • Resumen SOC — Objetivo: Cuenta eventos, alertas abiertas, incidentes abiertos y alertas críticas del tenant. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewe
  • Incident Timeline — Objetivo: Consulta información asociada a Timeline dentro del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a

SOAR gobernado

Define playbooks y ejecútalos contra incidentes. Las acciones sensibles terminadas en _request requieren aprobación humana; después se registra su resultado y el timeline del incidente.

Consultas habituales:

  • SOAR Playbooks — Objetivo: Lista o resume Playbooks del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/soar/playbooks;
  • SOAR Runs — Objetivo: Lista o resume Runs del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/soar/runs; consultar
  • SOAR Tasks — Objetivo: Consulta información asociada a Tasks dentro del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /ap

DFIR y Evidence Vault

Crea un caso, registra evidencias con SHA-256 y añade eventos de custodia. Cada evento de custodia se encadena por hash al anterior para preservar trazabilidad lógica.

Consultas habituales:

  • DFIR Cases — Objetivo: Lista o resume Cases del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/dfir/cases; consult
  • DFIR Evidence — Objetivo: Consulta información asociada a Evidence dentro del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a
  • Custody List — Objetivo: Consulta información asociada a Custody dentro del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /
  • DFIR Timeline — Objetivo: Consulta información asociada a Timeline dentro del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a

Business Continuity

Define criticidad, MTPD, RTO, RPO y nivel mínimo operativo. Estos servicios son la referencia para Recovery y Resilience Assurance.

Consultas habituales:

  • Business Services — Objetivo: Lista o resume Services del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/continuity/servi

Cyber Recovery

Crea un recovery case para un servicio, añade tareas y aprueba las que lo requieran. La liberación se bloquea mientras queden tareas no completadas o no validadas.

Consultas habituales:

  • Recovery Cases — Objetivo: Lista o resume Cases del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/recovery/cases; con

Resilience Assurance

Los modos simulation y digital_twin no requieren aprobación previa en Core. external_lab sí requiere aprobación de admin/superadmin antes de registrar su finalización.

Consultas habituales:

  • Resilience Requirements — Objetivo: Lista o resume Requirements del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/resilience/r
  • Resilience Experiments — Objetivo: Lista o resume Experiments del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/resilience/ex
  • Resilience Summary — Objetivo: Lista o resume Summary del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/resilience/summar

GRC y Compliance Evidence

Relaciona controles con requisitos de marcos, adjunta evidencia y calcula riesgo inherente/residual. Los mappings y métricas de readiness no constituyen certificación ni asesoramiento legal.

Consultas habituales:

  • GRC Controls — Objetivo: Lista o resume Controls del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/grc/controls; co
  • GRC Mappings — Objetivo: Lista o resume Mappings del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/grc/mappings; co
  • GRC Risks — Objetivo: Lista o resume Risks del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/grc/risks; consulta

Executive Risk

La vista ejecutiva consolida riesgos abiertos, riesgo residual medio, efectividad de controles, exposiciones críticas e incidentes abiertos.

Consultas habituales:

  • Resumen ejecutivo — Objetivo: Consolida riesgos abiertos, riesgo residual medio, efectividad media de controles, exposiciones críticas e incidentes abiertos. Procedimiento: inicia sesión con un rol au

MSP Operations

Superadmin puede crear o vincular tenants gestionados; admin y superadmin pueden consultar el resumen MSP. La delegación no elimina el aislamiento de los recursos funcionales.

Consultas habituales:

  • MSP Tenants — Objetivo: Lista o resume Tenants del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin); accede a /api/v1/msp/tenants; consultar el recurso
  • MSP Summary — Objetivo: Lista o resume Summary del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin); accede a /api/v1/msp/summary; consultar el recurso

Integration Registry

Define tipo, nombre, endpoint y referencia de secreto. El registro es el plano de control: Core 2.1 no implementa conectores comerciales reales ni prueba su alcance externo automáticamente.

Consultas habituales:

  • Integrations — Objetivo: Lista o resume Integrations del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/integrations

Service Operations / Tickets

Crea tickets vinculables a otros recursos por tipo/id. El SLA se expresa en minutos y el estado inicial es open.

Consultas habituales:

  • Tickets — Objetivo: Lista o resume Tickets del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v1/tickets; consulta

Auditoría

Disponible para admin y superadmin. Incluye acción, recurso, identificador, detalle y fecha; la API devuelve hasta 200 registros recientes.

Consultas habituales:

  • Logs — Objetivo: Lista o resume Audit del tenant autenticado. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin); accede a /api/v1/audit; consultar el recurso o acción

Plataforma y Diagnóstico

Health informa versión y estado del proceso; Ready comprueba base de datos y Redis; Capabilities enumera módulos; Diagnostics verifica base de datos y recuerda que las integraciones externas requieren pruebas separadas.

Consultas habituales:

  • Estado de salud — Objetivo: Comprueba que el proceso de Core responde y devuelve la versión instalada. Procedimiento: inicia sesión con un rol autorizado (public); accede a /api/health; consultar el
  • Readiness — Objetivo: Comprueba acceso a la base de datos y disponibilidad de Redis; puede devolver DEGRADED si Redis no responde. Procedimiento: inicia sesión con un rol autorizado (public);
  • Capacidades instaladas — Objetivo: Devuelve versión, módulos disponibles, tenant y rol de la sesión. Procedimiento: inicia sesión con un rol autorizado (superadmin, admin, analyst, viewer); accede a /api/v
  • Diagnóstico de plataforma — Objetivo: Verifica conexión a base de datos y devuelve versión/tenant; no sustituye pruebas de conectores externos. Procedimiento: inicia sesión con un rol autorizado (superadmin,