El Gobierno de Australia ha publicado una revisión de sus Guidelines for Cybersecurity Incidents dentro del Information Security Manual (ISM), con cambios relevantes en detección, registro, reporte y respuesta a incidentes. La página oficial fue actualizada el 4 de septiembre de 2025 y consolida controles específicos —con código y fecha de revisión— que las organizaciones pueden aplicar de forma inmediata.
La guía, autorizada por la administración australiana y mantenida por la Australian Signals Directorate (ASD), diferencia de forma clara evento y incidente, incorpora el concepto de ciberresiliencia y detalla tanto las fuentes de datos mínimas para detectar compromiso como los pasos de contención y erradicación ante malware, intrusiones o “data spills”. Además, refuerza la obligación de probar planes y políticas al menos una vez al año.
Qué considera la guía: evento, incidente y ciberresiliencia
- Evento de ciberseguridad: cualquier estado o suceso que apunte a una posible brecha de política, fallo de salvaguardas o situación desconocida relevante para la seguridad.
- Incidente de ciberseguridad: evento no deseado o inesperado —o cadena de eventos— que ha comprometido o tiene probabilidad significativa de comprometer las operaciones del negocio.
- Ciberresiliencia: capacidad de adaptarse a interrupciones manteniendo operaciones continuas, con foco en detectar, gestionar y recuperar.
Detección: los registros que no pueden faltar
La guía subraya que sin datos no hay investigación. Propone una lista de fuentes de logs para detección e forensics: aplicaciones de IA, CDS, bases de datos, DNS, email y web (servidores y proxies), gateways, móviles, MFDs, endpoints (SO), acceso remoto, productos de seguridad, aplicaciones de servidor y de usuario, y trazas de acceso al sistema. El objetivo es identificar código anómalo, comportamientos irregulares y tráfico sospechoso que sugiera explotación o compromiso.
Política y plan de gestión de incidentes (y por qué hay que ejercitarlos)
El ISM exige desarrollar, implementar y mantener una política de gestión de incidentes y su plan asociado. Debe definir responsabilidades, recursos y guías de triage; y, crucialmente, ejercitarse al menos una vez al año para comprobar que sigue siendo útil. Los controles ISM-0576 e ISM-1784 recogen estas obligaciones con fecha de actualización marzo de 2025.
Registro de incidentes: qué campos son obligatorios
La guía hace hincapié en un registro de incidentes mantenido y vivo (ISM-0125). Ese registro debe incluir, como mínimo, fecha del incidente, fecha de descubrimiento, descripción, acciones tomadas y a quién se reportó (ISM-1803). Más allá del seguimiento operativo, la guía recuerda que el histórico alimenta la gestión de riesgos y ayuda a proyectar costes de remediación.
Insider threat: programa específico (con asesoramiento legal)
Dado que las personas con acceso autorizado pueden ser difíciles de detectar cuando actúan maliciosamente, la guía recomienda un programa de mitigación de amenazas internas (ISM-1625/1626), con asesoría legal y monitoreo de señales como: copias excesivas de datos, uso no autorizado de medios extraíbles, conexiones de dispositivos de almacenamiento, accesos fuera de horario, descargas/impresiones inusuales, transferencias a servicios no autorizados o uso de VPN y redes de anonimato no aprobadas.
Datos y herramientas: habilitar la observabilidad desde el diseño
El control ISM-0120 insiste en que el personal de ciberseguridad disponga de fuentes de datos suficientes y herramientas —tanto manuales como automatizadas— para vigilar indicadores de compromiso. Esto debe incorporarse en el diseño y desarrollo de sistemas, no como parche a posteriori.
A quién y cuándo reportar: CISO, ASD, clientes y público
- Interno (CISO): los incidentes deben comunicarse lo antes posible al CISO o a su delegado para evaluar impacto y coordinar la respuesta (ISM-0123).
- Autoridad (ASD): la ASD usa los reportes para asistir, identificar tendencias y mejorar sus guías; además, dispone de una obligación de uso limitado: la información voluntaria reportada no se usa con fines regulatorios (ISM-0140). La guía detalla tipologías a reportar (p. ej., lockouts sospechosos, accesos remotos anómalos, uso irregular de cuentas de servicio, fuga de datos, DoS, ransomware, emails maliciosos o tampering de dispositivos).
- Clientes y público: si hay datos de clientes implicados, debe informarse con prontitud; incluso sin datos de clientes, se recomienda transparencia (ISM-1880/1881).
Respuesta: activar el plan y contener según el tipo de incidente
- Activar el plan: una vez identificado el incidente, se activa el plan de respuesta (ISM-1819).
- Data spill: informar a dueños de datos, restringir acceso y evaluar si apagar sistemas (cuidado: podría destruir evidencias útiles para forensics).
- Malware: aislar sistemas afectados, escanear medios conectados, intentar limpieza con antivirus y, si no es fiable, restaurar desde backup bueno o reinstalar. También se pide tratar el código malicioso de forma que se evite su ejecución accidental y analizarlo en entornos segregados (ISM-0917, ISM-1969, ISM-1970).
- Intrusiones: puede ser útil observar brevemente al actor para dimensionar el alcance, previo asesoramiento legal y de propietarios del sistema (ISM-0137, ISM-1609). La planificación debe hacerse en sistemas separados para no alertar al intruso y todas las acciones de remediación deben coordinarse en una ventana común (ISM-1731/1732). Tras la erradicación, capturar y analizar tráfico de red al menos durante 7 días para confirmar que no han vuelto.
Preservación de evidencias: cadena de custodia
La guía recuerda que la evidencia debe recopilarse y preservarse correctamente: documentar acciones, mantener cadena de custodia y seguir instrucciones de cuerpos competentes (ISM-0138). Si la ASD se va a involucrar, debe evitarse cualquier acción que afecte a la integridad de las pruebas.
Encaje con NIST SP 800-61 Rev. 3 (CSF 2.0)
La actualización australiana convive con la revisión de referencia de NIST SP 800-61 Rev.3 (abril de 2025), que integra la respuesta a incidentes en la gestión del riesgo alineada con NIST CSF 2.0 y redefine la práctica más allá del ciclo clásico. Para organizaciones globales, adoptar ISM y NIST 800-61r3 ofrece un marco complementario: controles verificables y trazabilidad (ISM), junto a resultados y funciones de CSF 2.0 (NIST).
Preguntas frecuentes
¿Qué campos debe incluir un registro de incidentes de ciberseguridad “listo para auditoría”?
Fecha del incidente y de descubrimiento, descripción, acciones realizadas y destinatarios del reporte (internos/externos). Mantenerlo actualizado es un control explícito del ISM (ISM-0125, ISM-1803).
¿Cada cuánto hay que probar el plan de respuesta a incidentes?
Al menos una vez al año. La guía exige ejercitar la política y el plan para validar su eficacia y ajustar roles, recursos y runbooks (ISM-1784).
¿Qué fuentes de logs son imprescindibles para detectar compromiso?
Registros de SO y aplicaciones (servidor/usuario), DNS, correo, web y proxies, gateways, acceso remoto, productos de seguridad, bases de datos, aplicaciones móviles, MFDs y, si aplica, aplicaciones de IA. La guía las enumera con el objetivo de encontrar actividad anómala o maliciosa.
¿Cómo encajar ISM de Australia con NIST 800-61 Rev. 3 en una empresa internacional?
Use ISM para aterrizar controles y evidencias (registro, reporte, preservación de pruebas, contención por tipo de incidente) y NIST 800-61r3 para orquestar la respuesta alineada con CSF 2.0 (preparación, detección-análisis, contención-erradicación-recuperación y post-incident). La combinación ofrece gobernanza, trazabilidad y mejora continua.
Fuentes: Guidelines for Cybersecurity Incidents del ISM (Gobierno de Australia) y NIST SP 800-61 Rev.3 (CSRC/NIST).
