El color es la severidad más alta y la intensidad, el volumen de alertas. En verde, las técnicas que cubre al menos una regla; el número es cuántas. Las grises son huecos que le decimos. Datos de ejemplo.
Sus equipos ya registran lo que pasa. Nadie lo está leyendo.
El firewall, el controlador de dominio y el ERP dejan rastro de todo. En la mayoría de las empresas nadie revisa esos registros hasta que algo deja de funcionar.
Nosotros los leemos por usted, investigamos lo que no cuadra y le contamos qué pasó y qué hicimos.
Lo que pasa en su red,
en una sola pantalla
Qué técnicas de ataque aparecen en sus registros, cuáles cubren nuestras reglas y de dónde viene el tráfico sospechoso. Los datos de esta sección son de ejemplo.
Simulación con datos de ejemplo. La integración con alertas reales sigue en desarrollo. La ubicación geográfica de una IP es aproximada y no demuestra la ubicación de quien opera el equipo.
Cuatro trabajos,
un solo vigilante
Del registro que produce su firewall a la acción que lo contiene, sin saltos ni cajas negras.
Lee lo que sus equipos ya producen
Syslog, SNMP, eventos de Windows, tráfico de red con Zeek y un agente para servidores. Sin cambios invasivos en firewalls ni switches.
Todo en un mismo idioma
Normaliza cada evento a un esquema común tipo ECS y lo enriquece con geolocalización e inteligencia de amenazas.
Alertas con evidencia
Reglas Sigma y correlación entre fuentes, mapeadas a MITRE ATT&CK.
Contiene lo urgente, consulta lo delicado
Los playbooks relacionan una alerta con acciones de respuesta. Las acciones de alto impacto requieren aprobación del analista del SOC. Propuesta, aprobación, envío y resultado son estados distintos.
Lo que nosotros hacemos
Usted no contrata analistas ni monta un SOC. Conectamos lo que ya tiene y nuestro equipo se encarga del resto.
Fuentes
Windows Server, Linux, bases de datos, firewalls y switches. Usamos lo que ya producen, sin cambios invasivos.
# lo que ya producen sus equipos
fw-borde deny 203.0.113.50 → 10.20.0.5:3389
DC01 4625 inicio de sesión fallido
srv-erp sshd: Failed password for root
Reglas abiertas,
no una caja negra
Sigma es un formato abierto para describir comportamientos maliciosos en los registros de un sistema. Lo mantiene la comunidad de seguridad y gran parte de los SIEM lo entienden. Nosotros también lo usamos.
-
1 · La comunidad
Una regla que cualquiera puede leer
Alguien describe un ataque una sola vez, en un archivo de texto. Conservamos su autoría y su licencia.
# regla Sigma (ejemplo) title: Posible inyección SQL logsource: category: webserver detection: selection: cs-uri-query|contains: - 'union select' - 'or 1=1' condition: selection level: high tags: [attack.t1190]
-
2 · Nuestro equipo
La adaptamos a sus datos y la revisamos
Traducimos la regla a lo que sus servidores realmente registran. Si a una regla le falta un dato, no la activamos para aparentar cobertura. Ninguna regla de la comunidad se activa sola: una persona la revisa antes.
-
3 · Su operación
Vigila y explica por qué
Cuando una regla coincide, la alerta dice cuál fue, qué evento la disparó y a qué técnica de MITRE ATT&CK corresponde.
# alerta (ejemplo) Alta · Posible inyección SQL en srv-web regla: sigma · inyección SQL técnica: T1190 evento: GET /pedidos?id=1+union+select… confianza: media
Las reglas de la comunidad provienen del proyecto SigmaHQ y se publican bajo la Detection Rule License 1.1. Las adaptamos a nuestro motor de detección y conservamos el nombre de su autor en cada una.
Datos, no gritos
La consola organiza severidad, contexto y evidencia para que el analista pueda investigar y decidir el siguiente paso.
- SeveridadCrítica, alta, media, baja o info
- Qué pasóUna frase con verbo
- Dónde y cuándoEquipo, IP y hora local con zona
- Qué tan seguros estamosConfianza alta, media o baja
- Qué hacerRevisar la evidencia y proponer o escalar una acción
- Dónde
- DC01 · 10.20.0.5
- Cuándo
- 24/09/2026 03:12:47 COT
- Técnica
- T1003.001 · robo de credenciales desde memoria
- Confianza
- Alta
- Detectada por la regla sigma win_lsass_access
- Nivel 1 reunió el evento original y el contexto del proceso
- Escalada al analista: bloquear una IP en DC01 requiere revisión
- Analista revisa la propuesta; aún no se ha enviado la acción
Un agente que no se cansa
y un analista que decide
El nivel 1 atiende y clasifica las alertas; el nivel 2 investiga lo escalado y aprueba lo que puede afectar su operación. Usted recibe el resultado.
Agente de triage
Clasifica alertas, reúne contexto y propone acciones según las políticas configuradas. Los casos que requieren revisión se escalan al analista.
Analistas del SOC
Investigan lo que escala el nivel 1, confirman o descartan y aprueban las acciones de alto impacto antes de ejecutarlas. Cada decisión queda en el registro de auditoría.
Usted recibe el parte, no la tarea
Consulta sus incidentes, la evidencia disponible y el estado de las acciones. El SOC gestiona las aprobaciones internas y coordina con su organización cuando la investigación requiere contexto operativo.
Lo que no negociamos
Sus datos, separados y a la vista
El acceso se organiza por cliente y por rol. El alcance de los datos y su tratamiento se revisan como parte de la configuración de cada piloto.
Respuesta con revisión
Las decisiones de investigar, contener o descartar deben conservar su justificación. Las acciones que pueden interrumpir su operación las aprueba primero un analista de nuestro SOC.
La evidencia a la vista
Cada alerta muestra la regla que la disparó y el evento original. Nada de "nuestra IA detectó algo".
Sin encierro tecnológico
Cada componente tiene una interfaz propia y una revisión de licencia. La selección técnica permite evaluar alternativas si cambia una dependencia.