El incidente de seguridad Grupo Caliche ocurrido en agosto de 2026 vuelve a recordar una realidad que afecta a organizaciones de cualquier tamaño: una buena estrategia de ciberseguridad no consiste únicamente en intentar impedir un ataque, sino también en estar preparados para detectar, contener, investigar y recuperar la actividad cuando algo ocurre.
Grupo Caliche confirmó públicamente que el 11 de agosto de 2026 sufrió un acceso no autorizado provocado, según la propia compañía, por la actuación maliciosa de una organización internacional.
Tras detectar el incidente, activó sus protocolos internos y organizó un equipo específico de respuesta junto con especialistas externos en análisis forense, su proveedor SOC, asesores de protección de datos y otros profesionales. Posteriormente comunicó que había recuperado su infraestructura tecnológica y que operaba de nuevo con normalidad y de forma segura.
A fecha 26 de agosto, la investigación continuaba abierta y la compañía indicaba que todavía no podía determinar con exactitud qué información concreta podía haberse visto comprometida.
Ese último punto es especialmente importante.
En un incidente real, muchas veces no se conocen todas las respuestas durante las primeras horas.
Y precisamente por eso disponer previamente de logs, procedimientos, profesionales especializados y capacidad de análisis puede marcar una gran diferencia.
¿Qué ocurrió en el incidente de seguridad Grupo Caliche?
La información pública disponible procede principalmente de la propia comunicación realizada por Grupo Caliche.
La compañía señala que sufrió un acceso no autorizado el 11 de agosto.
Después de detectarlo, activó sus procedimientos de respuesta y trabajó junto con:
- su equipo interno;
- especialistas externos en análisis forense;
- su proveedor SOC de ciberseguridad;
- asesores especializados en protección de datos;
- otros profesionales relacionados con la investigación.
También comunicó el incidente a organismos como la Agencia Española de Protección de Datos, INCIBE y Guardia Civil.
La empresa indicó posteriormente que su infraestructura tecnológica había sido recuperada y que la actividad se desarrollaba nuevamente con normalidad.
Lo que todavía no sabemos del incidente
También es importante explicar lo que no está confirmado.
A fecha 26 de agosto, Grupo Caliche indicó que todavía no era posible determinar exactamente qué información concreta podía haberse visto comprometida.
Por tanto, con la información pública disponible no deberíamos afirmar que:
- se haya producido un robo confirmado de determinados datos;
- toda la información de la empresa haya sido exfiltrada;
- exista ransomware;
- se conozca públicamente el vector inicial de acceso;
- se conozca el alcance definitivo del incidente.
Hacer estas distinciones es fundamental cuando hablamos de ciberseguridad.
Un acceso no autorizado es un incidente serio.
Sin embargo, no debemos convertir automáticamente una investigación abierta en afirmaciones que todavía no han sido demostradas.
Incidente de seguridad Grupo Caliche: la respuesta importa tanto como la prevención
Las empresas invierten habitualmente en medidas preventivas:
- firewall;
- antivirus;
- Endpoint / EDR;
- MFA;
- copias de seguridad;
- actualizaciones;
- segmentación.
Todas son necesarias.
Sin embargo, ningún sistema proporciona riesgo cero.
Por tanto, también necesitamos responder a otra pregunta:
¿Qué hacemos si un atacante consigue superar alguna de esas barreras?
Ahí entra la respuesta a incidentes.
Una organización preparada debería saber previamente:
- quién recibe la alerta;
- quién toma decisiones;
- qué sistemas deben aislarse;
- cómo se conservan las evidencias;
- cómo se mantiene la continuidad del negocio;
- qué proveedores deben intervenir;
- qué obligaciones legales deben evaluarse.
Improvisar todo esto durante un ataque consume un tiempo muy valioso.
El primer objetivo: contener el incidente
Cuando aparece una intrusión, una de las primeras prioridades es impedir que siga avanzando.
Dependiendo del escenario, puede ser necesario:
- aislar determinados equipos;
- bloquear comunicaciones;
- revocar sesiones;
- cambiar credenciales;
- limitar accesos;
- deshabilitar cuentas;
- separar segmentos de red.
Sin embargo, actuar demasiado rápido y sin metodología también puede destruir evidencias.
Por eso la respuesta debe equilibrar dos objetivos:
contener el daño y conservar información suficiente para investigar qué ocurrió.
INCIBE incluye precisamente la contención, la toma de evidencias y el análisis forense entre las actuaciones relevantes de una respuesta estructurada a incidentes.
¿Por qué es tan importante el análisis forense?
Después de contener un incidente empieza una de las preguntas más difíciles:
¿Qué ha ocurrido realmente?
El análisis forense intenta reconstruir la secuencia.
Por ejemplo:
- cuándo comenzó la actividad;
- qué usuario se utilizó;
- desde qué equipo;
- qué sistema fue el primero afectado;
- qué cuentas fueron utilizadas;
- qué procesos se ejecutaron;
- qué comunicaciones se produjeron;
- qué otros activos fueron alcanzados.
Esta investigación es importante no solo para conocer el pasado.
También permite identificar qué debemos corregir antes de volver completamente a la normalidad.
El problema de investigar sin logs
Imaginemos que sabemos que una cuenta fue utilizada de forma fraudulenta el día 20.
Entonces preguntamos:
¿Hubo actividad relacionada el día 10?
Después:
¿Y hace dos meses?
Si los registros ya han desaparecido, la investigación queda limitada.
Por eso una estrategia de ciberseguridad necesita decidir cuánto tiempo conservar determinadas evidencias y registros antes de que exista un incidente.
Los logs pueden proceder de:
- Windows;
- Linux;
- macOS;
- Microsoft 365;
- Entra ID;
- servidores;
- firewall;
- VPN;
- NAS;
- switches;
- puntos de acceso;
- Endpoint / EDR;
- antivirus.
Cuantas más fuentes relevantes podamos relacionar, mayor contexto tendremos.
400 días de logs: investigar también el pasado
En nuestros servicios de monitorización utilizamos una retención de hasta 400 días de logs.
Esto permite que, cuando se detecta una incidencia, podamos intentar responder preguntas como:
¿Esta IP ya apareció anteriormente?
¿Cuándo vimos por primera vez esta cuenta?
¿Hubo un inicio de sesión extraño hace seis meses?
¿Existieron conexiones anteriores desde el mismo origen?
¿Qué ocurrió antes del evento principal?
Mantener histórico no impide un ataque.
Pero puede mejorar enormemente nuestra capacidad para entenderlo posteriormente.
Puede conocer más sobre nuestro servicio de SIEM Wazuh para empresas.
Incidente de seguridad Grupo Caliche y el papel del SOC
Otro elemento que destaca en la comunicación pública de la compañía es la participación de su proveedor SOC durante la respuesta.
Un SOC no sustituye al firewall ni al antivirus.
Su función es diferente.
Las herramientas generan señales:
Firewall: conexiones y eventos de red.
Endpoint / EDR: actividad en los dispositivos.
Microsoft 365: inicios de sesión y cambios.
SIEM: centralización y correlación.
Después, el SOC analiza el contexto.
La diferencia es importante.
Una herramienta puede indicar:
“Inicio de sesión desde un nuevo dispositivo.”
Pero todavía necesitamos saber:
- si pertenece al usuario;
- si estaba previsto;
- desde dónde se produjo;
- si coincide con otros eventos;
- si posteriormente apareció actividad anómala.
Por eso nuestro SOC analiza los logs disponibles y determina qué situaciones requieren investigación o actuación.
Una alerta no es todavía una respuesta
Muchas empresas disponen de antivirus.
O tienen un firewall.
Quizá incluso reciben correos automáticos cuando algo ocurre.
Sin embargo, existe una pregunta clave:
¿Quién analiza la alerta cuando llega?
Un correo enviado a una bandeja que nadie revisa durante horas no constituye una respuesta a incidentes.
Una infraestructura necesita:
detección → análisis → decisión → actuación → verificación
Si uno de esos pasos no existe, el tiempo de exposición puede aumentar.
El tiempo importa durante un incidente de seguridad
Cuanto más tiempo permanece un atacante dentro de una infraestructura, más posibilidades tiene de:
- buscar información;
- descubrir otros sistemas;
- obtener credenciales;
- intentar elevar privilegios;
- moverse lateralmente;
- mantener persistencia.
Por tanto, detectar rápidamente una anomalía puede reducir el impacto.
Eso requiere visibilidad.
No podemos investigar aquello que nunca registramos.
Incidente de seguridad Grupo Caliche y recuperación de la infraestructura
Grupo Caliche señaló que, después de las actuaciones realizadas, recuperó su infraestructura tecnológica y volvió a operar normalmente y de forma segura.
La recuperación es otra fase fundamental.
No consiste únicamente en:
“encender los servidores otra vez”.
Antes de restaurar plenamente un entorno puede ser necesario comprobar:
- integridad de los sistemas;
- cuentas administrativas;
- credenciales;
- persistencia;
- configuraciones;
- vulnerabilidades;
- copias de seguridad;
- aplicaciones;
- comunicaciones.
Volver demasiado pronto a producción sin eliminar la causa puede permitir que el atacante continúe presente.
Las copias de seguridad también forman parte de la respuesta
Las copias son especialmente conocidas por su importancia frente al ransomware.
Sin embargo, también resultan útiles ante:
- corrupción;
- borrados;
- fallos de almacenamiento;
- errores humanos;
- determinados incidentes de seguridad.
Una estrategia empresarial debería contemplar:
- qué información se copia;
- frecuencia;
- retención;
- protección;
- ubicación;
- pruebas de restauración.
Porque disponer de una copia que nunca se ha probado no garantiza que pueda utilizarse cuando llegue una emergencia.
Copia de seguridad y logs son cosas diferentes
Conviene no confundirlos.
Una copia de seguridad permite recuperar información o sistemas.
Los logs permiten investigar qué ocurrió.
Necesitamos ambos.
Por ejemplo:
La copia puede permitir restaurar un servidor.
Pero quizá queramos saber:
¿cómo entró el atacante?
¿qué cuenta utilizó?
¿qué hizo antes de cifrarlo?
Para eso necesitamos evidencias y registros.
¿Qué ocurre si existe una posible brecha de datos personales?
Cuando un incidente puede afectar datos personales entra también en juego el RGPD.
La Agencia Española de Protección de Datos explica que una brecha de datos personales puede incluir, entre otras situaciones, un acceso no autorizado a los datos.
No todos los incidentes implican automáticamente la misma obligación.
La organización debe valorar el riesgo para los derechos y libertades de las personas.
Cuando resulte probable que exista riesgo, el artículo 33 del RGPD establece la obligación de notificar la brecha a la autoridad de control competente.
El plazo de 72 horas del RGPD
Uno de los puntos más conocidos es el plazo.
La AEPD indica que, cuando existe obligación de notificar, debe hacerse sin dilación indebida y, cuando sea posible, dentro de las 72 horas siguientes a que el responsable tenga constancia de la brecha.
Pero hay algo especialmente relevante:
no siempre es necesario disponer desde el primer momento de absolutamente toda la información.
La AEPD contempla que una notificación pueda completarse posteriormente cuando la complejidad del incidente impida determinar inicialmente todo su alcance.
Esto encaja con una realidad habitual en ciberseguridad:
durante las primeras horas sabemos que ha ocurrido algo, pero todavía estamos reconstruyendo exactamente qué.
¿Hay que avisar siempre a todos los afectados?
No automáticamente.
La AEPD establece que la organización debe evaluar el riesgo.
Cuando una brecha pueda entrañar alto riesgo para los derechos y libertades de las personas, puede ser necesario comunicar también lo ocurrido a los propios afectados.
Por tanto, cada incidente necesita una valoración técnica y jurídica.
Esta es una de las razones por las que resulta importante involucrar también a especialistas en protección de datos.
Ciberseguridad y protección de datos deben trabajar juntas
Un incidente puede comenzar siendo puramente técnico.
Por ejemplo:
acceso no autorizado detectado por el firewall o Endpoint / EDR.
Sin embargo, rápidamente aparecen cuestiones como:
- ¿había datos personales?
- ¿qué categorías?
- ¿se accedió realmente a ellos?
- ¿puede demostrarse?
- ¿qué riesgo existe?
- ¿hay que notificar?
- ¿hay que informar a afectados?
Por eso seguridad y protección de datos no deberían funcionar como áreas completamente independientes.
Durante una crisis necesitan compartir información.
Incidente de seguridad Grupo Caliche: por qué es importante no especular
La propia comunicación de Grupo Caliche indica que la investigación seguía en curso y que no quería realizar afirmaciones que fueran más allá de las conclusiones verificadas por los especialistas.
Esa forma de comunicar es importante.
Durante un incidente existe mucha presión por responder inmediatamente:
“¿Qué datos han robado?”
“¿Quién ha entrado?”
“¿Cómo lo hicieron?”
Pero una investigación forense necesita tiempo.
Dar una respuesta no verificada puede generar:
- información incorrecta;
- alarmismo;
- problemas legales;
- confusión entre clientes y empleados.
Por tanto, comunicar con transparencia no significa afirmar aquello que todavía no sabemos.
Transparencia no significa publicar todos los detalles técnicos
También existe el extremo contrario.
Una empresa no debería divulgar información que pueda:
- facilitar nuevos ataques;
- comprometer la investigación;
- revelar credenciales;
- exponer configuraciones internas.
Una comunicación responsable debe explicar aquello que los afectados necesitan conocer sin convertir el comunicado en una guía de la infraestructura interna.
Qué puede aprender una pyme del incidente de Grupo Caliche
Aunque una empresa sea mucho más pequeña que Grupo Caliche, las fases fundamentales son similares.
Una pyme también debería preguntarse:
¿Quién recibe las alertas de seguridad?
¿Tenemos un procedimiento si ocurre algo un viernes por la noche?
¿Sabemos cómo aislar un equipo?
¿Tenemos copias verificadas?
¿Conservamos logs?
¿Quién realiza el análisis forense?
¿Quién evalúa las obligaciones RGPD?
Estas preguntas deben responderse antes de sufrir el incidente.
Las administraciones de fincas también necesitan un plan
Una administración de fincas puede gestionar:
- datos personales;
- documentación;
- cuentas bancarias;
- proveedores;
- certificados;
- Microsoft 365.
Si se produce una intrusión, la incidencia puede afectar a numerosos clientes y comunidades.
Por tanto, además de proteger los equipos, conviene disponer de capacidad para investigar posteriormente qué ocurrió.
Asesorías laborales y contables
Las asesorías concentran una cantidad especialmente elevada de información sensible.
Por ejemplo:
- nóminas;
- DNI;
- datos bancarios;
- contratos;
- impuestos;
- certificados digitales.
Además, suelen intercambiar constantemente información por correo.
Por tanto, una cuenta comprometida o un endpoint infectado puede convertirse rápidamente en un problema más amplio.
Despachos de abogados
Los despachos jurídicos manejan documentación confidencial por definición.
Además, muchos utilizan:
- Microsoft 365;
- SharePoint;
- OneDrive;
- aplicaciones cloud;
- acceso remoto.
Una estrategia de respuesta debe contemplar tanto los equipos como las identidades y la información alojada en la nube.
Arquitectura, construcción e ingeniería
En estos sectores el activo crítico puede no ser únicamente un dato personal.
También pueden existir:
- proyectos;
- planos;
- propiedad intelectual;
- presupuestos;
- documentación técnica;
- BIM;
- diseños.
Por tanto, un incidente puede producir consecuencias económicas incluso aunque no exista una brecha masiva de datos personales.
El correo sigue siendo uno de los activos críticos
Muchas intrusiones comienzan o terminan afectando a la identidad.
Una cuenta de correo comprometida puede utilizarse para:
- leer conversaciones;
- buscar facturas;
- localizar proveedores;
- modificar reglas;
- enviar phishing;
- intentar fraude de pagos.
Por eso proteger Microsoft 365 requiere algo más que instalar Office.
Es recomendable combinar:
- MFA;
- Acceso Condicional;
- dispositivos gestionados;
- monitorización de inicios de sesión;
- auditoría.
Endpoint / EDR: saber qué ocurre dentro del dispositivo
El firewall puede ofrecer información sobre comunicaciones.
Pero no necesariamente explica qué proceso las generó.
Ahí entra la protección endpoint.
Un Endpoint / EDR puede aportar información relacionada con:
- procesos;
- archivos;
- conexiones;
- comportamiento;
- actividad sospechosa.
Cuando estos datos se relacionan con logs del firewall o Microsoft 365, el contexto mejora.
Puede conocer nuestras soluciones de Endpoint y firewall para empresas.
Firewall: controlar el perímetro sigue siendo necesario
Los firewalls siguen siendo una pieza fundamental.
Pueden:
- controlar conexiones;
- segmentar tráfico;
- aplicar reglas;
- ofrecer VPN;
- registrar eventos.
Sin embargo, un firewall no ve todo lo que ocurre dentro de Microsoft 365.
Tampoco sustituye al Endpoint / EDR.
Por eso la seguridad necesita diferentes capas.
SIEM: reunir las piezas
Imaginemos este escenario:
Entra ID: inicio de sesión extraño.
Firewall: conexión hacia una IP sospechosa.
Endpoint: proceso desconocido.
Antivirus: detección.
Por separado parecen eventos diferentes.
Un SIEM permite centralizarlos y aplicar reglas o correlaciones.
Después, un analista puede revisar si forman parte de la misma historia.
Incidente de seguridad Grupo Caliche: detectar no es suficiente
Podemos instalar herramientas excelentes.
Pero alguien tiene que atenderlas.
Esta diferencia parece pequeña, pero es fundamental.
Monitorización automática
recopila y clasifica.
SOC
revisa, contextualiza y toma decisiones.
En nuestros servicios de ciberseguridad empresarial buscamos precisamente combinar ambas capas.
¿Qué debería contener un plan de respuesta a incidentes?
Como mínimo, una empresa debería definir:
Contactos
Quién debe intervenir y cómo localizarlo.
Clasificación
Cómo determinar la gravedad.
Contención
Qué sistemas pueden aislarse.
Evidencias
Qué información debe conservarse.
Recuperación
Cómo restaurar la actividad.
Comunicación
Quién informa internamente y externamente.
Protección de datos
Quién evalúa si existe una posible brecha.
Revisión posterior
Qué medidas deben adoptarse para evitar que vuelva a ocurrir.
INCIBE dispone además de servicios de soporte de respuesta a incidentes para empresas y entidades privadas en España.
El peor momento para diseñar el procedimiento es durante el ataque
Imaginemos una empresa un viernes a las 19:00.
Un servidor presenta una actividad extraña.
Surgen inmediatamente preguntas:
¿Apagamos el servidor?
¿Desconectamos Internet?
¿Restauramos una copia?
¿Llamamos al proveedor?
¿Hay que notificar a la AEPD?
Si nunca se han definido responsabilidades, cada decisión consume tiempo.
Por eso un procedimiento básico preparado previamente puede resultar enormemente útil.
¿Debemos apagar inmediatamente todos los equipos?
No existe una respuesta universal.
Dependiendo del tipo de incidente, apagar un sistema puede:
- detener determinada actividad;
- pero también eliminar información volátil útil para una investigación.
Por eso en incidentes importantes es recomendable contar con profesionales que puedan valorar las actuaciones.
Lo importante es evitar improvisaciones que destruyan evidencias innecesariamente.
La vuelta a la normalidad también debe monitorizarse
Supongamos que todos los sistemas han sido restaurados.
El trabajo todavía no ha terminado.
Durante los días posteriores conviene aumentar la atención sobre:
- nuevas conexiones;
- cuentas;
- autenticaciones;
- cambios;
- procesos;
- alertas;
- comportamiento de red.
¿Por qué?
Porque necesitamos comprobar que la amenaza realmente ha desaparecido.
Después del incidente llega la fase de aprendizaje
Una respuesta profesional debería terminar con preguntas como:
¿Qué ocurrió?
¿Qué funcionó bien?
¿Qué falló?
¿Qué podríamos haber detectado antes?
¿Qué control debemos cambiar?
Puede ser necesario:
- cerrar un servicio;
- aplicar MFA;
- modificar permisos;
- actualizar un sistema;
- añadir telemetría;
- reforzar segmentación;
- aumentar retención de logs;
- modificar procedimientos.
Así, el incidente se utiliza también para mejorar la seguridad futura.
No existe una empresa demasiado pequeña para sufrir un incidente
Un error frecuente es pensar:
“¿Quién va a querer atacarnos a nosotros?”
Muchos ataques actuales son automatizados.
Bots analizan continuamente Internet buscando:
- servicios expuestos;
- VPN vulnerables;
- credenciales;
- servidores;
- aplicaciones desactualizadas.
No necesariamente existe una persona que haya elegido manualmente a cada empresa.
Por eso una pyme también puede convertirse en objetivo.
Pero tampoco debemos convertir cada incidente en alarmismo
Ciberseguridad no significa afirmar que todas las empresas están siendo atacadas constantemente por grupos altamente sofisticados.
Una comunicación responsable debe diferenciar:
- intento;
- alerta;
- acceso;
- compromiso;
- exfiltración;
- impacto.
En el caso de Grupo Caliche existe confirmación de un acceso no autorizado.
La investigación sobre la posible información afectada continuaba abierta en el momento de la comunicación pública.
Esa es la información que debemos utilizar.
Incidente de seguridad Grupo Caliche: cinco enseñanzas para empresas
El caso permite extraer cinco conclusiones especialmente útiles.
1. Hay que tener un plan antes del incidente
No durante.
2. Necesitamos evidencias
Sin logs resulta mucho más difícil reconstruir lo ocurrido.
3. SOC y análisis forense cumplen funciones diferentes
Uno ayuda a detectar y contextualizar.
El otro profundiza en la reconstrucción técnica del incidente.
4. Ciberseguridad y RGPD están relacionados
Cuando existen datos personales, también deben evaluarse obligaciones legales.
5. Recuperar la actividad no termina la investigación
La causa, el alcance y las medidas correctivas deben continuar analizándose.
Qué puede hacer una empresa antes de sufrir un incidente
Una estrategia razonable puede empezar con:
- MFA en Microsoft 365;
- Endpoint / EDR;
- firewall correctamente administrado;
- copias verificadas;
- sistemas actualizados;
- dispositivos gestionados;
- separación de cuentas administrativas;
- SIEM;
- SOC;
- procedimiento de respuesta.
No todas las empresas necesitan exactamente las mismas herramientas.
La arquitectura debe adaptarse al riesgo, tamaño y funcionamiento de la organización.
¿Está tu empresa preparada para investigar un incidente?
Podemos plantear un ejercicio sencillo.
Imagina que mañana detectas un acceso no autorizado.
¿Podrías responder:
qué usuario entró?
desde qué IP?
qué equipo utilizó?
qué otros sistemas tocó?
qué hizo durante las últimas semanas?
qué información pudo consultar?
qué logs conservas?
Si la respuesta a varias de estas preguntas es “no lo sabemos”, existe margen para mejorar la visibilidad.
Conclusión: el incidente de Grupo Caliche demuestra por qué hay que prepararse antes
El incidente de seguridad Grupo Caliche comenzó con un acceso no autorizado detectado el 11 de agosto de 2026.
La empresa respondió activando sus protocolos y coordinándose con profesionales de análisis forense, SOC y protección de datos. Además, comunicó el incidente a AEPD, INCIBE y Guardia Civil y posteriormente confirmó la recuperación de su infraestructura tecnológica.
A 26 de agosto, sin embargo, la investigación todavía no permitía establecer con exactitud qué información concreta podía haberse visto comprometida.
Y ahí aparece una de las principales lecciones del caso.
Un incidente puede detectarse en minutos, pero comprender completamente lo ocurrido puede necesitar días o semanas.
Por eso las empresas deberían preparar antes:
prevención + detección + logs + SOC + respuesta + recuperación
En GHM Soluciones Informáticas ayudamos a empresas a mejorar su seguridad mediante ciberseguridad empresarial, Endpoint / EDR, firewalls administrados, Microsoft 365, monitorización SOC y SIEM Wazuh con conservación de logs para investigaciones posteriores.
Porque la pregunta importante no es únicamente:
“¿Podemos evitar todos los incidentes?”
También debemos preguntar:
“Si mañana ocurre uno, ¿tendremos información suficiente para saber qué pasó y actuar con rapidez?”
Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre el incidente de seguridad Grupo Caliche
¿Cuándo ocurrió el incidente de seguridad de Grupo Caliche?
Grupo Caliche indica que el acceso no autorizado tuvo lugar el 11 de agosto de 2026.
¿Qué ocurrió exactamente?
La compañía confirmó un acceso no autorizado provocado, según su comunicado, por la actuación maliciosa de una organización internacional. La investigación sobre su alcance continuaba abierta el 26 de agosto.
¿Se sabe qué datos fueron robados?
No se había determinado públicamente. Grupo Caliche afirmó que todavía no era posible precisar qué información concreta podía haberse visto comprometida.
¿Fue un ataque de ransomware?
La comunicación pública utilizada como fuente no confirma que el incidente fuera ransomware. Por tanto, no debería afirmarse sin nuevas evidencias.
¿La empresa recuperó sus sistemas?
Sí. Grupo Caliche indicó el 26 de agosto que había recuperado su infraestructura tecnológica y que operaba con normalidad y de forma segura.
¿Intervino un SOC?
Sí. La compañía señala que durante la respuesta trabajó con su proveedor SOC junto con especialistas en análisis forense, protección de datos y otros profesionales.
¿Se comunicó el incidente a las autoridades?
Grupo Caliche indica que puso el incidente en conocimiento de la AEPD, INCIBE y Guardia Civil.
¿Todas las brechas deben notificarse a la AEPD?
No automáticamente. La AEPD indica que debe evaluarse el riesgo para los derechos y libertades de las personas y que la notificación es obligatoria cuando resulte probable que exista dicho riesgo.
¿Cuál es el plazo para notificar una brecha de datos?
Cuando exista obligación de notificar, el RGPD establece que debe hacerse sin dilación indebida y, cuando sea posible, dentro de las 72 horas desde que la organización tiene constancia de la brecha.
¿Por qué son importantes los logs durante un incidente?
Porque permiten reconstruir actividad anterior, buscar relaciones entre diferentes sistemas y disponer de evidencia para análisis técnico y auditorías.
¿Qué diferencia existe entre SIEM y SOC?
El SIEM recopila, procesa y correlaciona información procedente de diferentes fuentes. El SOC utiliza esa información y otras evidencias para analizar los eventos y decidir cuáles requieren investigación o actuación.
¿Por qué conservar 400 días de logs?
Porque algunas intrusiones se descubren mucho después de haberse iniciado. Un histórico amplio permite investigar actividad de meses anteriores y buscar señales relacionadas.
¿Qué debería revisar una pyme después de conocer este tipo de incidentes?
Como mínimo, copias de seguridad, MFA, protección endpoint, firewall, actualizaciones, permisos, monitorización, retención de logs y un procedimiento básico de respuesta a incidentes.
