Checklist de seguridad al recibir un cliente de otro MSP

Respuesta corta: Trata un hallazgo de seguridad durante el cambio de MSP primero como incidente y después como pregunta sobre el desempeño del proveedor anterior. Protege al cliente, conserva evidencia, establece la cronología de responsabilidad y documenta solo lo que puedes demostrar. No contactes al MSP anterior ni nombres productos sin un propósito operativo autorizado por el cliente.

Un hallazgo cambia la prioridad del onboarding

Un cliente nuevo rara vez llega como entorno limpio. El primer despliegue puede revelar malware, un administrador desconocido, un agente de acceso remoto abandonado, una exclusión insegura o un equipo que nunca estuvo cubierto por el servicio de seguridad anterior.

Ese descubrimiento crea dos problemas distintos:

1. Un incidente de seguridad que puede requerir contención e investigación inmediatas.
2. Una pregunta de transición sobre lo que existía antes de que el nuevo MSP asumiera responsabilidad.

No permitas que el segundo problema retrase el primero. El cliente necesita una respuesta coordinada, no un debate sobre cuál vendor, herramienta o proveedor debió ver la actividad.

El hallazgo tampoco demuestra negligencia. El servicio anterior pudo excluir el equipo, operar con otro alcance, alertar sin autoridad para remediar, conservar evidencia que el cliente no ha solicitado o haber empezado después del compromiso original. Esas posibilidades no son excusas. Son desconocidos que deben separarse de los hechos.

Conecta esta guía con la checklist de onboarding de clientes. El onboarding normal puede continuar después de que el responsable del incidente decida qué debe pausarse, qué evidencia debe conservarse y cuáles sistemas son seguros para intervenir.

Establece la línea de entrega antes de cambiar controles

Registra la transición lo antes posible:

• Fecha y hora en que el nuevo MSP recibió autoridad administrativa.
• Fecha y hora de instalación de cada agente o control nuevo.
• Fecha y hora de retiro de cada agente o acceso anterior.
• Equipos en línea, apagados, no disponibles o excluidos intencionalmente.
• Servicios de seguridad que el cliente dice haber contratado con el proveedor anterior.
• Alertas, tickets abiertos, excepciones y aceptaciones de riesgo entregadas.
• Personas autorizadas para aprobar aislamiento, recolección de evidencia, restauración y comunicación externa.

Esto no es un documento para repartir culpas. Es un registro operativo. Sin él, las conversaciones posteriores dependen de memoria: el MSP anterior dice que el equipo estaba fuera de alcance, el cliente dice que estaba cubierto y el MSP nuevo no puede demostrar cuándo comenzó su responsabilidad.

Cuando sea posible, evita retirar el stack anterior antes de registrar presencia de agentes, estado de políticas, alertas recientes y cobertura de equipos. No accedas al portal ni a los datos de otro proveedor sin autorización. Registra solo lo que sea legítimamente visible en el entorno del cliente o entregado durante la transición.

Contén sin destruir la evidencia necesaria

Sigue el plan aprobado de respuesta a incidentes del cliente y la dirección de personal capacitado. Ante una amenaza activa confirmada o creíble, el primer objetivo es evitar daño adicional mientras se conserva evidencia suficiente para comprender el alcance.

Reglas prácticas:

• Coordina el aislamiento de red en lugar de improvisar acciones de remediación sin relación.
• Conserva alerta original, timestamps, identidad del equipo, usuarios conectados y acciones ya ejecutadas.
• Recolecta logs relevantes de endpoint, identidad, firewall, DNS, proxy, autenticación y acceso remoto antes de que expire la retención.
• Registra cada acción de contención y remediación con hora, operador, motivo y resultado.
• No reinstales, borres, elimines cuentas o desinstales controles solo para que desaparezca la alerta.
• Evita apagar el equipo cuando eso destruya evidencia volátil, salvo que aislar no sea posible o lo indique el responsable de respuesta.
• Usa un canal fuera de banda si la amenaza puede estar observando las comunicaciones normales.

La checklist de respuesta a ransomware de CISA enfatiza aislamiento coordinado y conservación de evidencia volátil. La secuencia técnica exacta depende de la amenaza y los recursos disponibles, pero el principio operativo se mantiene: contención y preservación deben planearse juntas.

Abre un solo registro del incidente y construye la cronología

Los equipos pequeños pierden el control cuando la evidencia queda repartida entre chat, correo, portales de seguridad y notas técnicas. Crea un solo registro que sea dueño de la cronología.

Registra:

• Quién reportó o detectó el evento.
• Primera hora observada y actividad relacionada más antigua conocida.
• Contexto de equipo, cuenta, tenant, sitio y red.
• Fuente de detección y nivel de confianza.
• Indicadores y comportamientos, no solo una etiqueta de malware.
• Sistemas o cuentas que podrían compartir la misma exposición.
• Acciones solicitadas, aprobadas, ejecutadas, fallidas o diferidas.
• Ubicación de evidencia y fechas límite de retención.
• Contactos del cliente, seguro, legal, privacidad y regulación cuando aplique.
• Decisión que cierra la contención y autoriza recuperación.

No edites en silencio observaciones anteriores cuando nueva evidencia cambie la historia. Agrega una corrección fechada. La cronología debe mostrar cómo evolucionó el entendimiento.

NIST SP 800-61 Rev. 3 coloca la respuesta a incidentes dentro de la gestión continua de riesgo cibernético y no como evento técnico aislado. Para un MSP pequeño, esto significa que el registro debe conectar respuesta técnica, decisiones del cliente, comunicación, recuperación y lecciones aprendidas. Consulta la guía vigente de respuesta a incidentes de NIST.

Separa hechos, inferencias y preguntas abiertas

Usa tres etiquetas en el registro.

Hecho confirmado

La evidencia respalda directamente la afirmación.

Ejemplos:

• Un equipo específico ejecutó un proceso sospechoso a una hora registrada.
• Una cuenta administrativa inició sesión desde un origen registrado.
• Había un agente de seguridad instalado cuando llegó el nuevo MSP.
• Una acción de contención terminó correctamente.

Inferencia de trabajo

La evidencia sugiere la afirmación, pero existen alternativas.

Ejemplos:

• La actividad podría ser anterior a la transición.
• Una cuenta local desconocida podría haberse usado para persistencia.
• Una política o exclusión podría haber reducido la respuesta automática.

Pregunta abierta

La respuesta requiere evidencia todavía no disponible.

Ejemplos:

• ¿El endpoint estaba incluido en el alcance de seguridad anterior?
• ¿El proveedor anterior recibió una alerta?
• ¿El cliente rechazó un control recomendado?
• ¿El acuerdo anterior incluía autoridad de remediación?

Un agente instalado es un hecho. Lo que incluía el contrato es una pregunta. Una detección nueva es un hecho. Por qué el flujo anterior no remedió es una inferencia hasta contar con alertas y políticas.

El cliente controla la decisión de comunicación externa

El primer deber de comunicación del nuevo MSP es con el cliente y el responsable designado del incidente. El MSP anterior no tiene derecho automático a conocer detalles, y el nuevo MSP no debe revelar información de seguridad del cliente solo por cortesía profesional.

Antes de contactar a un tercero, confirma:

• El cliente autoriza el contacto y la información que se compartirá.
• El contacto tiene un propósito definido de respuesta al incidente.
• Los procesos legales, del seguro, de privacidad o regulatorios no requieren otro canal.
• El mensaje no expone credenciales, indicadores sensibles, datos personales o detalles innecesarios.
• Una persona es responsable del seguimiento y registra la respuesta.

Las consideraciones de CISA sobre riesgo relacionado con MSP recomiendan protocolos claros para divulgación de vulnerabilidades, notificación de incidentes y comunicación con terceros. Esos protocolos deben decidirse antes de enviar un mensaje emocional.

Cuándo puede ayudar contactar al MSP anterior

El contacto puede ser útil cuando:

• El proveedor anterior conserva logs necesarios para establecer alcance o cronología.
• Su acceso o agente debe permanecer temporalmente para contención o exportación de evidencia.
• Es dueño de un caso con vendor, backup, control de red o relación cloud necesaria para recuperar.
• El cliente necesita confirmar manejo previo de alertas, exclusiones o aceptación de riesgo.
• Una credencial compartida o práctica repetible confirmada podría crear riesgo fuera de un solo cliente.
• El cliente quiere un registro coordinado en lugar de narrativas en competencia.

El contacto normalmente no ayuda cuando:

• El propósito es avisar que el nuevo MSP tiene mejor stack.
• La evidencia solo demuestra que una herramienta detectó lo que otra no.
• El cliente no autorizó la divulgación.
• El mensaje especula sobre negligencia, competencia o calidad de producto.
• La información no cambiará contención, investigación, recuperación o riesgo más amplio.

Un riesgo sistémico merece escalación más fuerte que un hallazgo aislado sin explicación. Aun así, usa un canal documentado y limitado, y comparte solo la evidencia necesaria para describir el riesgo.

Usa una plantilla neutral de comunicación

Con autorización del cliente, el mensaje puede decir:

Durante la transición autorizada de nuestro cliente en común identificamos un evento de seguridad que podría incluir actividad anterior al inicio de nuestra responsabilidad. No conocemos el alcance de su contrato, configuración de políticas ni historial completo de alertas, por lo que no estamos atribuyendo causa o responsabilidad. El cliente nos autorizó preguntar si conservan alertas, logs, excepciones o información de casos sobre el sistema y periodo afectados que pueda apoyar la contención y revisión de la cronología. Por favor utilicen el canal seguro acordado para cualquier evidencia o detalle sensible.

No incluyas nombres de equipos, indicadores públicos, usuarios, capturas o reportes completos innecesarios en el primer mensaje. Primero establece quién es el destinatario autorizado y el método seguro de transferencia.

Ejecuta una revisión de seguridad de transición

El primer hallazgo puede ser aislado o revelar un problema más amplio de ownership. Revisa el entorno de forma sistemática.

Identidad y acceso privilegiado

• Inventaría administradores con nombre, cuentas compartidas, cuentas de emergencia, identidades de servicio y acceso delegado.
• Deshabilita accesos no autorizados o innecesarios después de preservar evidencia relevante.
• Rota credenciales privilegiadas, claves API, secretos de acceso remoto y credenciales compartidas de administrador local con una secuencia documentada.
• Revisa cambios privilegiados recientes y anomalías de autenticación.

Cobertura de endpoints

• Compara el inventario del cliente con la cobertura activa de seguridad y administración.
• Identifica equipos apagados, duplicados, obsoletos, no administrados o excluidos.
• Verifica asignación de políticas y enrutamiento de alertas, no solo agentes instalados.
• Busca indicadores relacionados en la flota cubierta.

Control de red y cloud

• Revisa firewall, VPN, Wi-Fi, DNS, correo, identidad, backup y rutas de administración cloud.
• Confirma qué parte es dueña de cada control y dónde se conservan logs.
• Elimina integraciones y accesos de vendors obsoletos solo después de entender su papel en el incidente.

Evidencia y documentación

• Exporta registros de entrega, riesgos abiertos, tickets pendientes y excepciones conocidas.
• Registra la evidencia no disponible en lugar de fingir que la revisión estuvo completa.
• Asigna a cada riesgo residual un responsable, decisión y fecha de revisión.

La guía de logging de CISA para empresas pequeñas y medianas recomienda asignar roles de incidente y conservar registros útiles de sistemas de negocio. La visibilidad solo ayuda cuando alguien es responsable de revisar y responder.

Define un piso de seguridad para cada cliente administrado

La transición puede revelar un problema de empaquetado. Si un cliente administrado puede rechazar todos los controles de visibilidad y respuesta mientras el MSP conserva la expectativa de detectar y resolver incidentes, el acuerdo crea responsabilidad sin evidencia.

Define el piso mínimo necesario para entregar servicio administrado de forma segura:

• Acceso administrativo con nombre y autenticación fuerte.
• Inventario de endpoints y cobertura mínima de monitoreo.
• Ownership central de alertas y escalación.
• Expectativas de parches, backups y ruta de restore.
• Disponibilidad de logs adecuada al entorno soportado.
• Proceso documentado de excepciones y aceptación de riesgo.
• Límites de autoridad para contención y acciones de emergencia.

Respuesta avanzada, cumplimiento formal, investigación forense y reportes regulatorios pueden permanecer como alcance separado. El piso mínimo no afirma que cada cliente recibe todos los servicios de seguridad. Es la visibilidad y control que el MSP necesita para cumplir su propia promesa.

Usa la base de seguridad para MSP pequeños para definir controles recurrentes después de estabilizar el incidente de transición.

Completa una revisión posterior al incidente

Después de contención y recuperación, revisa tanto el incidente como la transición.

Pregunta:

• ¿Qué evidencia estuvo disponible inmediatamente?
• ¿Qué logs expiraron o no estaban accesibles?
• ¿El equipo sabía quién podía aprobar aislamiento?
• ¿Se retiraron herramientas antes de exportar evidencia?
• ¿Se coordinaron comunicaciones con cliente, seguro, legal y proveedores?
• ¿Sobrevivió inesperadamente alguna cuenta, agente o integración compartida?
• ¿Qué checklist o límite contractual debe cambiar?

Asigna cada mejora a un responsable y fecha. No cierres con “se recordó al técnico”. Cambia la checklist, automatización, acuerdo, modelo de acceso o cadencia que permitió la brecha.

Checklist de recepción segura

Antes de cerrar la revisión de transición, confirma:

• El incidente tiene un responsable y una cronología fechada.
• Los sistemas afectados se contuvieron mediante el proceso aprobado.
• Evidencia y logs relevantes se conservaron antes de acciones destructivas.
• Hechos, inferencias y preguntas abiertas están separados.
• Las fechas de responsabilidad y cambio de herramientas están registradas.
• El cliente aprobó cualquier contacto con el proveedor anterior.
• Los accesos privilegiados y compartidos se revisaron y rotaron.
• La cobertura de endpoints, red, cloud, backup y acceso remoto está conciliada.
• Excepciones y evidencia no disponible están documentadas.
• Los riesgos residuales tienen decisión del cliente y fecha de revisión.
• Las decisiones de recuperación y regreso a servicio están registradas.
• Las checklists de onboarding, offboarding e incidentes se actualizaron con lo aprendido.

Error común

El error común es convertir el descubrimiento en argumento de venta. “Nuestra herramienta encontró lo que la suya no” parece simple, pero ignora alcance, configuración, tiempo, autoridad de respuesta y decisiones del cliente. También puede impulsar una remediación prematura que destruya evidencia necesaria.

Deja que hable el registro operativo: qué se encontró, cuándo, qué estuvo afectado, qué hizo el equipo, qué sigue desconocido y cuál decisión protege al cliente ahora.

Cuándo cambiar de nivel

Involucra respuesta especializada, legal, seguro, privacidad o regulación cuando el evento pueda incluir movimiento lateral, compromiso de cuentas privilegiadas, exposición de datos sensibles, interrupción material, varios clientes o deberes de notificación fuera de la competencia o autoridad del MSP.

Fortalece el proceso de recepción cuando credenciales, agentes, logs, ownership o excepciones de seguridad llegan sin documentar repetidamente. Una transición no debe depender de que el técnico nuevo descubra el entorno una sorpresa a la vez.