Security Monitor

Plataforma de seguridad M365 en producción

Security Monitor v2 es un servicio Python que consume la Graph Security API (alertas e incidentes Defender), enriquece con contexto de usuario y dispositivo, y notifica a través de SISAlerts y Jira.

Arquitectura del flujo de seguridad

El scheduler gestiona el polling de la Graph Security API y el informe de protección en el mismo proceso Python. Comparten DB, config y servicios de notificación.

Pipeline detallado: alerta Defender → Jira + SISAlerts

Cada ciclo de 120 segundos el scheduler obtiene alertas e incidentes nuevos, los enriquece, los persiste en SQLite y los notifica según los filtros de severidad configurados.

# notifier.py — flujo simplificado de process_new_alert()
def process_new_alert(alert, severity_filter, cfg):
    # 1. Notificar SISAlerts si procede
    if severity_filter['notify_sisalerts'] and not already_notified(alert_id, 'sisalerts'):
        sisalerts_client.ingest_security_alert(alert, severity_filter)
        log_notification(alert_id, 'sisalerts')

    # 2. Crear ticket Jira proyecto 1
    if severity_filter['create_jira'] and not already_notified(alert_id, 'jira_create'):
        key1 = jira_client.create_ticket(alert, severity_filter, project='key_1')
        log_notification(alert_id, 'jira_create', detail=key1)

    # 3. Crear ticket Jira proyecto 2 (si configurado)
    if severity_filter.get('jira_project_key_2') and not already_notified(alert_id, 'jira_create_2'):
        key2 = jira_client.create_ticket(alert, severity_filter, project='key_2')
        log_notification(alert_id, 'jira_create_2', detail=key2)

Filtros de severidad y doble proyecto Jira

Los filtros de severidad son la pieza central de configuración del flujo Security API. Determinan qué alertas notificar, con qué prioridad y a qué proyectos Jira.

4.1 Campos del filtro de severidad

4.2 Doble proyecto Jira (Dual Project)

4.3 Configuración global Jira

4.4 Contenido del ticket Jira (alerta)

Informe mensual de postura de seguridad M365

El scheduler dispara automáticamente un informe HTML de postura M365 los días 1 y 15 de cada mes. También se puede generar bajo demanda desde la UI de administración.

5.1 Ventana temporal y ejecución

5.2 Tabla de auditoría protection_report_runs

5.3 Endpoints Graph usados por el informe

Esquema SQLite — 6 tablas

SQLite en modo WAL. Auto-migraciones al arrancar (columnas nuevas se añaden sin recrear tablas). Bootstrap admin configurado en app-config.json.

Organización del repositorio

Backend Python modular con servicios desacoplados. Frontend Jinja2 + Vanilla JS, sin frameworks ni build step. Entry point único que arranca Flask + scheduler.

security-monitor/
  config/
    app-config.json              — Config local (gitignored)
    app-config.example.json      — Plantilla documentada con todos los campos
  db/
    database.py                  — SQLite WAL, auto-migraciones, bootstrap admin
    schema.sql                   — Tablas base (9 tablas)
  services/
    graph_security.py            — fetch_alerts(), fetch_incidents(), fetch_alert_by_id()
    graph_auth.py                — MSAL singleton — cert store Windows o fichero PFX/PEM
    graph_enrich.py              — enrich_alert() — usuario + dispositivo, cache TTL 5min
    graph_protection.py          — Fetchers para informe de protección (signIns, risks, alerts, risky_users)
    jira_client.py               — create_ticket(), add_comment(), link_issues(), add_attachment()
    notifier.py                  — process_new_alert(), process_new_incident(), update_incident_ticket()
    protection_report.py         — run_protection_report(), render_html(), load_assets()
    sisalerts_client.py          — ingest_security_alert() — POST a SISAlerts /api/ingest
  assets/                        — Chart.js + topojson (gitignored, descargados al primer arranque)
  webapp/
    app.py                       — Flask app, blueprints, init DB
    auth.py                      — SSO App Proxy (X-MS-CLIENT-PRINCIPAL-NAME)
    routes/
      admin.py                   — CRUD severity_filters, settings, test-jira-pipeline, ingest-alert
      api.py                     — /api/test-jira, /api/poll-security-now, /api/status
      dashboard.py               — Stats Security API (alertas, incidentes)
    templates/
      base.html                  — Layout con navbar, theme toggle
      dashboard.html             — Dashboard: incidentes + alertas recientes, poll manual
      admin_severity.html        — CRUD filtros severidad + drag&drop + badge segundo proyecto
      admin_settings.html        — Config + Jira defaults + informe protección on-demand
  scheduler.py                 — Loop polling Security API + protection report scheduler
  run_webapp.py                — Entry point: Flask + scheduler en background thread
  security-monitor-service.xml — Descriptor WinSW
  deploy.ps1                   — git pull + pip install + restart servicio

Panel de administración y herramientas

UI completa para gestionar filtros de severidad, probar la integración Jira, importar alertas manualmente y generar el informe de protección bajo demanda.

Badges de severidad y estado usados en el dashboard.

Referencia de app-config.json

Todos los parámetros de configuración del sistema, organizados por categoría.

Security API

Jira

Graph API

Informe de Protección

General

// app-config.example.json — estructura completa
{
  "port": 8083,
  "bootstrap_admin": "[email protected]",
  "security_polling_enabled": false,
  "security_polling_interval_seconds": 120,
  "min_severity_global": "medium",
  "enrich_alerts": true,
  "security_retention_days": 90,
  "graph": {
    "tenant_id": "d78b7929-c2a3-4897-ae9a-7d8f8dc1a1cf",
    "client_id": "250c7cb4-...",
    "auth_mode": "certificate",
    "certificate_thumbprint": "..."
  },
  "sisalerts": { "url": "http://sisalerts-server:8082", "api_key": "..." },
  "default_jira_project": "MESA",
  "default_jira_issue_type": "Alertas 365",
  "default_jira_incident_type": "Incidente 365",
  "default_jira_project_2": "SOS",
  "default_jira_issue_type_2": "Alertas 365",
  "default_jira_incident_type_2": "Incidente 365",
  "jira": {
    "base_url": "https://idealista.atlassian.net",
    "user_email": "...",
    "api_token": "..."
  },
  "protection_report": {
    "enabled": true,
    "auto_dismiss": false
  },
  "sso": { "dev_bypass_upn": "" }
}

Permisos Graph API (250c7cb4)

App Registration en Entra ID con autenticación por certificado (thumbprint en config). Permisos de tipo Application (sin usuario interactivo).

Producción en Windows Server

WinSW como servicio Windows. Entra ID App Proxy para acceso externo con SSO. Deploy automático vía deploy.ps1.

Decisiones de diseño y problemas resueltos

Los principales retos de implementación del sistema, con la solución adoptada en cada caso.

Dependencias y tecnologías