Entender Sophos Incident Response, Readiness y evaluaciones

Ante un incidente de seguridad activo o sospechado, se inicia el proceso ya establecido. Un ataque en curso no es un proyecto de implementación ordinario. Se utiliza el contacto previsto en el plan de emergencia y el derecho al servicio confirmado, en lugar de contratar primero una evaluación o un nuevo retainer.

Digital Forensics and Incident Response (DFIR) combina investigación forense y respuesta a un incidente concreto. Readiness prepara a responsables y procedimientos. Security Testing y las evaluaciones examinan un alcance de seguridad definido previamente. Estos servicios producen resultados distintos y no se sustituyen entre sí.

Transferir correctamente un incidente

Sophos describe DFIR como apoyo para identificar y neutralizar amenazas activas, analizar causas, realizar Compromise Assessments y Threat Hunting. El trabajo real depende del servicio contratado y el derecho confirmado. La descripción de un equipo disponible a cualquier hora no es un compromiso individual sobre el inicio de intervención, presencia física o duración de recuperación.

Para la primera entrega se prepara un estado breve y trazable:

1. Contactos y autoridad de decisión: dirección técnica del incidente, responsables de negocio y canal de respuesta autorizado.
2. Observaciones en vez de suposiciones: hora y zona horaria, sistemas o identidades afectados, mensajes concretos y efectos visibles.
3. Medidas ya ejecutadas: por ejemplo aislamiento, restricciones de cuentas o restauraciones, con hora y persona responsable.
4. Evidencias disponibles: registros, identificadores de casos y copias existentes, con procedencia y ubicación. Se indica expresamente si se desconoce su integridad.
5. Derecho y alcance: cliente, contrato o retainer y área afectada conocida. No se presenta un derecho no confirmado como adquirido.

Esta lista es una recomendación Avanet para organizar la transferencia, no un procedimiento forense completo. Facilita la primera actuación sin perder información por cambios precipitados. No se reinstalan sistemas contaminados solo para crear una «base limpia». Los responsables del incidente deciden aislamiento, apagado, conservación de pruebas y recuperación según el caso.

Las evidencias pueden contener contraseñas, datos personales o información empresarial confidencial. Solo se transmite lo necesario por un canal seguro confirmado. Un ticket público, chat o enlace desprotegido no es una alternativa adecuada. Si las cuentas de comunicación pueden estar comprometidas, se acuerda antes un canal de retorno fiable.

Distinguir MDR y DFIR

MDR es el servicio gestionado continuo de búsqueda de amenazas, detección y respuesta acordada. DFIR atiende un incidente concreto dentro del alcance de investigación confirmado. Aunque el mismo proveedor ofrezca ambos, una alerta del producto no contrata automáticamente DFIR ni da derecho a una investigación ilimitada.

En un servicio MDR existente son decisivos los contactos y modo Threat Response, junto al responsable real del caso y la acción requerida al cliente. Un caso customer-managed no lo investiga automáticamente el equipo MDR por el mero hecho de disponer de una licencia Sophos. Las acciones del cliente abiertas necesitan un responsable y no desaparecen por un supuesto cambio de servicio.

El artículo Security Services Retainer explica Service Units y condiciones específicas de DFIR. Un saldo SU no es un plazo general de respuesta ni garantiza cerrar un incidente en cierto número de horas. Los derechos existentes se comprueban en los acuerdos concretos.

Readiness: practicar antes de un incidente

La preparación implica que responsabilidades, accesos y decisiones sean utilizables antes del incidente. Una Tabletop Exercise es una discusión guiada sobre un escenario: el equipo examina decisiones y transferencias sin lanzar un ataque real contra producción.

Se definen objetivo y participantes, por ejemplo la coordinación de IT, dirección y comunicación cuando se comprometen identidades administrativas. El ejercicio debe mostrar quién declara el incidente, quién autoriza la contención, cómo se comunica fuera de los sistemas potencialmente afectados y cómo se decide la recuperación. Produce observaciones documentadas y mejoras concretas con responsables y fechas.

Tener un plan de emergencia no demuestra por sí solo que la recuperación funcione o los contactos estén localizables. Avanet recomienda revisar la cadena de contactos y aprobaciones y un procedimiento de recuperación adecuado tras cambios relevantes. Una conversación no sustituye una prueba técnica de restauración planificada por separado.

Elegir evaluaciones y pruebas de seguridad

El External Penetration Testing examina el acceso desde fuera. Las pruebas internas pueden investigar qué resulta posible con acceso previo a la red. Las pruebas wireless abordan vías de ataque Wi-Fi; las Web Application Assessments examinan aplicaciones y problemas específicos. El nombre del servicio no garantiza incluir todas las sedes, aplicaciones o interfaces.

Una evaluación tampoco demuestra que el entorno esté completamente libre de intrusiones. Un Compromise Assessment busca indicios de intrusión dentro del alcance acordado; una prueba de penetración verifica vías de ataque seleccionadas. Ambos se distinguen de la operación continua de Managed Risk y de la respuesta a un incidente ya activo.

Antes de una prueba se documentan sistemas objetivo y exclusiones, permisos de sus propietarios, métodos permitidos, ventanas, acceso a datos y criterios de parada. En sistemas cloud o de terceros debe existir la correspondiente autorización de prueba. Se necesita un contacto localizable para detenerla; disponibilidad e impacto productivo se consideran expresamente. Sin autorización clara no se inicia ninguna prueba.

El resultado incluye hallazgos comprensibles con sistemas afectados, evidencias, impacto y correcciones priorizadas. Una repetición comprueba los puntos corregidos acordados; el presupuesto confirma si está incluida, cuándo y con qué alcance. Un informe no certifica invulnerabilidad futura. Ejecución y aceptación de mejoras siguen siendo tareas distintas y visibles.

Para cambios planificados después de los hallazgos, la distinción entre TAM, soporte y Deployment Services ayuda a convertir una recomendación en un encargo definido con traspaso técnico, en lugar de trasladar riesgos abiertos entre proveedores.