Patrones de respuesta a incidentes

Obtenga más información acerca de Well-Architected Confide → Respuesta de incidentes de seguridad

Los incidentes de seguridad se producirán a pesar de las medidas preventivas. Trust architecture requiere un diseño para la detectabilidad, la respuesta rápida, la investigación forense y la recuperación elegante. Esta página consolida patrones de respuesta a incidentes desde la sección Respuesta a incidentes del pilar Trust, que cubre la arquitectura de detección, los procedimientos de respuesta, las funciones forenses y el aprendizaje posterior a incidentes.

Patrones

Dónde buscar	Qué buen aspecto tiene
Supervisión de eventos	✅ Active Supervisión de eventos capturando patrones de inicio de sesión, exportaciones de datos masivas, cambios de permisos y actividad de API con enrutamiento a plataformas SIEM para la retención que superan los límites de retención nativos
Políticas de seguridad de transacciones	✅ Configure políticas que evalúan eventos en tiempo real para bloquear acciones sospechosas, requerir autenticación de pasos o desencadenar notificaciones basándose en líneas base de comportamiento
Seguimiento de auditoría de configuración	✅ Supervisar cambios de configuración administrativa que permiten la detección de modificaciones no autorizadas con retención de 180 días
Registro de aplicación personalizado	✅ Implementar el registro de eventos relevantes para la seguridad en Apex capturando fallos de autenticación, denegaciones de autorización y patrones de entrada sospechosos
Supervisión de comprobación de estado	✅ Configurar la detección automatizada de desviación de configuración desde líneas base de seguridad que podría indicar cambios no autorizados
Integración de SIEM	✅ Enrutar registros de Supervisión de eventos a plataformas SIEM empresariales para su correlación con la telemetría de seguridad empresarial y el análisis de comportamiento
Reglas de alerta	✅ Diseñar reglas de alerta detectando patrones sospechosos (acceso masivo fuera del horario de oficina, inicio de sesión desde nuevas geografías, distribución rápida de permisos) con líneas de base de comportamiento para minimizar falsos positivos
Análisis de comportamiento	✅ Establecer líneas base de comportamiento que permitan la detección de anomalías para volúmenes de acceso a datos inusuales, actividad administrativa fuera de horario y patrones de consumo de API
Detección de múltiples canales	✅ Implemente la detección a través de Supervisión de eventos, Seguridad de transacciones, Configuración Seguimiento de auditoría, registro personalizado y Comprobación de estado proporcionando múltiples señales de detección independientes
Almacenamiento de registros inmutable	✅ Enrutar registros a almacenamiento externo inmutable que los atacantes no pueden modificar incluso con acceso administrativo a Salesforce, garantizando la integridad de las pruebas forenses

Antipatrones

Dónde buscar	Aspecto negativo
Solo retención de registro nativo	⚠️ Basándose únicamente en plazos de retención de seguimiento de auditoría nativos de Salesforce (límites nativos de Supervisión de eventos, 180 días Configuración Seguimiento de auditoría) sin archivado externo, descubriendo que los registros caducaron cuando la investigación requiere análisis histórico
Sin líneas base de comportamiento	⚠️ No tener líneas base de comportamiento para la detección de anomalías, generando alertas de falsos positivos excesivas que entrenan a los equipos de seguridad para ignorar notificaciones
Sin integración SIEM	⚠️ Falta de integración de SIEM empresarial, pérdida de oportunidades de correlación con telemetría de seguridad de otros sistemas que revelarían patrones de compromiso más amplios
Revisión de registro manual	⚠️ Dependiendo de la revisión manual periódica del registro en vez de alertas automatizadas, descubrir incidentes semanas o meses después de producirse cuando el daño es extenso
Sin políticas de seguridad de transacciones	⚠️ No tener políticas de Seguridad de transacciones en tiempo real, carecer de capacidad para bloquear acciones sospechosas que evitan daños antes de que se produzcan
Cobertura incompleta	⚠️ Supervisión solo de subconjuntos de eventos relevantes para la seguridad (inicio de sesión pero no acceso a datos, cambios de configuración pero no modificaciones de permisos) creando puntos ciegos
Fatiga de alerta	⚠️ Generación de alertas de falsos positivos excesivas sin ajuste, entrenamiento de equipos para ignorar notificaciones incluyendo eventos de seguridad legítimos

Patrones

Dónde buscar	Qué buen aspecto tiene
Límites de aislamiento	✅ Arquitectura de diseño de modo que los componentes comprometidos puedan aislarse a través de la revocación de conjuntos de permisos, cambios de restricción de IP o finalización de sesión sin interrumpir funciones comerciales críticas
Gestión de sesiones	✅ Implementar funciones de terminación rápida de sesiones para cuentas comprometidas, incluyendo el cierre de sesión forzado y la invalidación de sesiones en todas las sesiones activas
Revocación de permisos	✅ Otorgue privilegios a través de conjuntos de permisos en vez de perfiles de línea base de modo que la revocación sea rápida: eliminar la asignación de conjunto de permisos revoca el acceso cuando ningún perfil u otra asignación otorga independientemente el mismo permiso
Restricciones de IP	✅ Configure intervalos de direcciones IP de inicio de sesión a nivel de perfil para cuentas privilegiadas de modo que se denieguen directamente los inicios de sesión desde otras direcciones, lo que permite un aislamiento rápido a nivel de red en ubicaciones administrativas conocidas
Inmovilización de cuenta de usuario	✅ Implementar procedimientos de congelación de cuentas que evitan la autenticación preservando los datos para la investigación sin eliminar la cuenta comprometida
Controles de acceso de API	✅ Autenticación de API de diseño con funciones de revocación de tokens que permiten el aislamiento rápido de cuentas de integración comprometidas
Aislamiento de múltiples organizaciones	✅ Para activos de alto valor, evalúe la arquitectura de múltiples organizaciones proporcionando un aislamiento más sólido para componentes críticos a costa de una mayor complejidad operativa
Procedimientos de vidrio roto de emergencia	✅ Mantener procedimientos de acceso de vidrio roto documentados para acceso administrativo de emergencia con auditoría y validación posteriores al uso

Antipatrones

Dónde buscar	Aspecto negativo
Sin límites de aislamiento	⚠️ Falta de límites de aislamiento arquitectónico que requieren el apagado completo del sistema para contener cualquier compromiso, interrumpiendo todas las funciones comerciales
Acceso demasiado permisivo	⚠️ Otorgar permisos amplios Modificar todos los datos evitando la revocación de privilegios granulares sin interrumpir múltiples procesos comerciales
Cuentas de servicio compartidas	⚠️ Uso de una cuenta de “Usuario de API” o “Usuario de integración” compartida única entre múltiples sistemas evitando el aislamiento de una integración comprometida específica sin interrumpir todas las integraciones
Sin restricciones de IP	⚠️ No tener lista de admisión de direcciones IP para cuentas privilegiadas, carecer de funciones de contención a nivel de red cuando las cuentas están comprometidas
Sin gestión de sesión	⚠️ Falta de funciones de terminación de sesión que requieren restablecimiento de contraseña como única forma de forzar el cierre de sesión, introduciendo retrasos durante plazos de respuesta críticos
Sin procedimientos de emergencia	⚠️ No tener procedimientos documentados de rotura de vidrio o acceso de emergencia, improvisar decisiones críticas bajo presión durante incidentes activos

Patrones

Dónde buscar	Qué buen aspecto tiene
Registros de supervisión de eventos	✅ Capturar registros de actividad detallados incluyendo acciones de usuario, llamadas de API, eventos de autenticación y patrones de acceso a datos con suficiente detalle para el análisis forense
Seguimiento de auditoría de campo	✅ Activar Seguimiento de auditoría de campo conservando el historial de cambios de datos para campos Restringido y Confidencial con retención que coincida con los requisitos normativos (admite retención indefinida; confirme el periodo requerido con la regulación vigente)
Almacenamiento inmutable	✅ Enrutar registros a almacenamiento externo inmutable que los atacantes no pueden modificar, garantizando la integridad de las pruebas forenses durante la investigación
Seguimiento de auditoría de configuración	✅ Preservar el historial de cambios de configuración administrativa activando la investigación de modificaciones del sistema no autorizadas con retención de 180 días
Evaluación de ámbito	✅ Diseñar modelos de permisos y controles de acceso a datos que permitan una evaluación rápida del ámbito de exposición de datos basándose en privilegios de cuenta comprometidos
Cambiar correlación	✅ Mantener la correlación entre los cambios de configuración del Seguimiento de auditoría de configuración y los patrones de actividad de Supervisión de eventos que permiten la investigación de técnicas de atacantes
Registro de acceso a datos	✅ Registrar todo el acceso a datos restringidos y confidenciales que permiten investigar qué datos se expusieron durante el periodo de compromiso
Seguimiento de auditoría de integración	✅ Capturar patrones de autenticación, autorización e intercambio de datos de API para sistemas integrados que permiten la investigación de compromisos entre sistemas
Preservación de pruebas	✅ Enrutar registros y seguimientos de auditoría continuamente a almacenamiento externo inmutable de modo que la evidencia forense se mantenga y esté disponible cuando se investiga un incidente

Antipatrones

Dónde buscar	Aspecto negativo
Almacenamiento de registros mutable	⚠️ Almacenamiento de registros solo dentro de Salesforce donde los atacantes con acceso administrativo pueden eliminar o modificar pruebas forenses
Detalle de registro insuficiente	⚠️ Captura de eventos de alto nivel sin detalles suficientes para la investigación (inicio de sesión registrado pero no dirección IP, acceso a datos registrado pero no registros específicos)
Sin registro de acceso a datos	⚠️ Falta de registro detallado del acceso a datos restringidos y confidenciales, no se puede evaluar el ámbito de exposición de datos durante la notificación de infracción
Falta el seguimiento de auditoría de campo	⚠️ No se puede activar Seguimiento de auditoría de campo para campos confidenciales, no se puede determinar qué valores de datos se expusieron durante el compromiso
Sin correlación de cambios	⚠️ No tener capacidad de correlación entre los cambios de configuración de Seguimiento de auditoría de configuración y los patrones de actividad de Supervisión de eventos posteriores
Historial de auditoría eliminado	⚠️ Permitir que el historial de auditoría caduque antes del mínimo de retención reguladora que establece la regulación reguladora para su implementación, creando infracciones de cumplimiento

Patrones

Dónde buscar	Qué buen aspecto tiene
Objetivos de tiempo de recuperación	✅ Definir y probar Objetivo de tiempo de recuperación (RTO) y Objetivo de punto de recuperación (RPO) para escenarios de incidentes de seguridad, no solo escenarios de recuperación de desastres
Procedimientos de recuperación probados	✅ Procesos de recuperación de documentos para cuentas comprometidas, exfiltración masiva de datos, implementaciones no autorizadas, distribución de privilegios y compromiso de paquetes con pruebas trimestrales
Validación de copia de seguridad	✅ Valide la integridad de la copia de seguridad regularmente garantizando que las funciones de restauración funcionen durante incidentes de seguridad, no solo fallos operativos
Funciones de reversión	✅ Diseñar oportunidades en curso de implementación con procedimientos de reversión probados para implementaciones de código no autorizadas o cambios de configuración maliciosos
Rotación de credenciales	✅ Implementar procedimientos de rotación de credenciales rápidos para cuentas de integración comprometidas, usuarios de API y credenciales nombradas
Restauración de permisos	✅ Documentar procedimientos para restaurar el acceso apropiado después de acciones de aislamiento demasiado amplias durante la respuesta a incidentes
Restauración de datos	✅ Diseñar funciones de recuperación de datos que aborden la corrupción o eliminación de datos resultante de incidentes de seguridad, distinta de la recuperación de desastres
Continuidad del servicio	✅ Soluciones de arquitecto para que los procedimientos de respuesta a incidentes de seguridad mantengan la continuidad crítica de la función comercial durante la investigación y la solución
Validación de restauración	✅ Pruebe los procedimientos de recuperación trimestralmente validando que los sistemas restaurados funcionan correctamente y que el compromiso no persistió a través de la restauración

Antipatrones

Dónde buscar	Aspecto negativo
Procedimientos no probados	⚠️ Habiendo documentado procedimientos de recuperación nunca probados a través de ejercicios, descubriendo durante incidentes reales que los procedimientos son incompletos o incorrectos
Sin RTO/RPO para seguridad	⚠️ Definición de objetivos de tiempo de recuperación solo para la recuperación de desastres sin considerar escenarios de incidentes de seguridad que requieren diferentes procedimientos de recuperación
Sin capacidad de reversión	⚠️ Falta de procedimientos de reversión de implementación para implementaciones de código no autorizadas, lo que requiere una redesarrollo completo para eliminar cambios maliciosos
Copias de seguridad no validadas	⚠️ Nunca probar la restauración de copias de seguridad, descubrir durante incidentes que las copias de seguridad están dañadas o incompletas
Sin procedimientos de rotación de credenciales	⚠️ No tener procedimientos de rotación de credenciales rápidos para cuentas de integración comprometidas, dejando credenciales comprometidas activas durante la investigación
Procesos de recuperación manuales	⚠️ Dependiendo completamente de los procedimientos de recuperación manual durante incidentes, introduciendo errores y retrasos cuando la velocidad es crítica
Sin pruebas de restauración	⚠️ Nunca validar que los sistemas restaurados funcionan correctamente después de la recuperación, posiblemente reintroduciendo compromisos o daños en los datos

Patrones

Dónde buscar	Qué buen aspecto tiene
Respuesta de cuenta de usuario comprometida	✅ Procedimientos de documentos: inmovilizar usuario, forzar restablecimiento de credenciales, revisar Configuración Seguimiento de auditoría y registros de acceso a datos para periodo de compromiso, evaluar ámbito de exposición de datos, ejecutar notificación de infracción si se accede a datos restringidos
Respuesta de exfiltración de datos masiva	✅ Procedimientos de documentos: revocar sesión de inmediato, restringir permisos, identificar registros afectados y niveles de clasificación, ejecutar notificación de incumplimiento normativo dentro del plazo que establece la regulación reguladora para su implementación
Respuesta de implementación de código no autorizado	✅ Procedimientos de documentos: implementación de reversión inmediata, audite todos los cambios desde credenciales comprometidas, revise la seguridad de oportunidades en curso para omisión de autorización, explore el código implementado para puertas traseras persistentes
Respuesta de distribución de privilegios	✅ Procedimientos de documentos: revocar privilegios distribuidos inmediatamente, auditar actividades realizadas con acceso elevado, investigar cómo la distribución omitió controles de aprobación, implementar controles de compensación
Respuesta de compromiso de paquete AppExchange	✅ Procedimientos de documentos: aislar permisos de paquetes, evaluar datos a los que se accede por paquete, evaluar opciones de sustitución de paquetes, documentar lecciones aprendidas para criterios de evaluación de paquetes
Señales de detección	✅ Configure la supervisión detectando cada escenario: anomalías de inicio de sesión para cuentas comprometidas, volumen de exportación de informes para exfiltración, supervisión de implementación para código no autorizado, supervisión de cambio de permisos para distribución
Ejercicios de mesa	✅ Realizar ejercicios de mesa probando procedimientos de respuesta para escenarios específicos de plataforma validando la preparación del equipo y la completitud del procedimiento
Automatización de respuestas	✅ Las políticas de Seguridad de transacciones en tiempo real bloquean automáticamente acciones sospechosas, requieren autenticación de pasos o notifican a los respondedores sobre señales de detección de alta confianza, proporcionando contención automatizada que reduce el tiempo de respuesta

Antipatrones

Dónde buscar	Aspecto negativo
Solo planes de respuesta genéricos	⚠️ Tener solo procedimientos genéricos de respuesta a incidentes sin directrices específicas de Salesforce, improvisando acciones específicas de plataforma durante incidentes activos
Sin configuración de detección	⚠️ No tener ninguna supervisión configurada para detectar escenarios específicos de plataforma (exportación masiva, distribución de privilegios, implementación no autorizada), descubrir incidentes a través de informes de usuario o auditorías
Sin ejercicios de mesa	⚠️ Nunca realizar ejercicios de sobremesa validando la familiaridad del equipo con procedimientos de respuesta específicos de plataforma, descubriendo brechas de Knowledge durante incidentes reales
Sin automatización	⚠️ Respuesta completamente manual para todos los incidentes sin políticas de Seguridad de transacciones en tiempo real para la contención automatizada, introduciendo retrasos cuando el bloqueo inmediato podría reducir los daños
Libros de jugadas de respuesta que faltan	⚠️ Falta de manuales de respuesta documentados para escenarios comunes (cuenta de usuario comprometida, exfiltración de datos, implementación de código no autorizado)
Sin procedimientos de notificación de infracción	⚠️ Al no tener procedimientos para requisitos de notificación de incumplimiento normativo, tratar de comprender obligaciones durante incidentes reales cuando las cronologías son ajustadas

Patrones

Dónde buscar	Qué buen aspecto tiene
Comunicación fuera de banda	✅ Establecer canales de comunicación que no dependan de sistemas potencialmente comprometidos (árboles telefónicos, plataformas de mensajería externa) para coordinar la respuesta
Procedimientos de distribución	✅ Rutas de distribución de documentos desde la detección inicial hasta la notificación ejecutiva con información de contacto y criterios de distribución
Plantillas de notificación	✅ Mantener plantillas de notificación redactadas previamente para tipos de incidentes comunes que permiten una comunicación rápida a partes interesadas, clientes y reguladores
Identificación de partes interesadas	✅ Identificar partes interesadas que requieren notificación para diferentes tipos de incidentes, incluyendo ejecutivos, legales, de cumplimiento, usuarios afectados y autoridades reguladoras
Cronología de notificaciones reglamentarias	✅ Documente los requisitos de notificación reguladora de cada jurisdicción, confirmados con respecto a la regulación reguladora para su implementación, con procedimientos que garantizan el cumplimiento oportuno
Coordinación interna	✅ Diseñar procedimientos de coordinación de incidentes especificando funciones y responsabilidades (comandante de incidentes, líder técnico, líder de comunicaciones, enlace jurídico)
Coordinación externa	✅ Establecer procedimientos para coordinar con el Servicio de Asistencia de Salesforce, los investigadores forenses externos, los asesores jurídicos y las fuerzas del orden, según proceda
Comunicación de estado	✅ Implementar la cadencia de comunicación de estado regular durante incidentes activos manteniendo a las partes interesadas informadas sin abrumar al equipo de investigación

Antipatrones

Dónde buscar	Aspecto negativo
Sin comunicación fuera de banda	⚠️ Dependiendo completamente del correo electrónico o la mensajería interna potencialmente comprometidos para la coordinación de incidentes, perder capacidad de comunicación cuando los canales principales están comprometidos
Rutas de distribución poco claras	⚠️ No tener procedimientos de distribución documentados, lo que provoca retrasos y confusión sobre quién debe ser notificado y cuándo
Sin plantillas de notificación	⚠️ Mejorar las notificaciones de incidentes durante incidentes activos bajo presión de tiempo, dando como resultado comunicaciones incompletas o incorrectas
Faltan listas de partes interesadas	⚠️ Al no tener listas de partes interesadas preidentificadas, descubrir durante incidentes que las partes críticas (legales, de cumplimiento, ejecutivos) no fueron notificadas
Sin conocimiento de cronología reguladora	⚠️ Desconociendo los plazos de notificación reguladora que se aplican a su implementación durante la respuesta a incidentes, incumpliendo plazos y creando infracciones de cumplimiento adicionales
Funciones ambiguas	⚠️ Tener funciones y responsabilidades de respuesta ante incidentes no claras, lo que provoca confusión sobre quién tiene autoridad para tomar decisiones de contención
Sin procedimientos de coordinación externos	⚠️ No tener relaciones o procedimientos establecidos para implicar al Servicio de asistencia de Salesforce, los investigadores forenses o las fuerzas del orden cuando sea necesario

Patrones

Dónde buscar	Qué buen aspecto tiene
Cultura sin culpa	✅ Centrar las revisiones posteriores a incidentes en mejoras del sistema en vez de culpa individual, permitiendo el aprendizaje organizacional sin temor a repercusiones
Documentación de cronología de incidentes	✅ Documente la cronología completa del incidente incluyendo el compromiso inicial, la detección, las acciones de respuesta y la resolución con marcas de tiempo precisas
Análisis de fallos de control	✅ Identificar qué controles preventivos y de detective fallaron en prevenir o detectar el incidente, informando mejoras arquitectónicas
Documentación de debilidad arquitectónica	✅ Debilidades de arquitectura de documentos reveladas por el incidente en Registros de decisiones de arquitectura (ADR) capturando cambios de seguridad
Priorización de rehabilitación	✅ Dar prioridad a la remediación basada en el potencial de reducción de riesgos, abordando las causas raíz en vez de los síntomas
Colaboración de lecciones	✅ Compartir lecciones aprendidas entre equipos y unidades comerciales evitando incidentes similares en otras partes de la organización
Actualizaciones de reglas de detección	✅ Actualizar reglas de detección y líneas base de comportamiento basándose en técnicas de ataque observadas durante la investigación
Refinamiento de procedimiento de respuesta	✅ Actualizar procedimientos de respuesta a incidentes basándose en lo que funcionó y lo que no durante la respuesta a incidentes real
Seguimiento de mediciones	✅ Realizar un seguimiento del tiempo medio de detección (MTTD), el tiempo medio de respuesta (MTTR) y el ámbito de impacto a lo largo del tiempo identificando tendencias que requieren inversión arquitectónica
Revisar cadencia	✅ Realizar un examen oportuno después del incidente mientras los detalles permanecen actualizados y existe un impulso para mejorar

Antipatrones

Dónde buscar	Aspecto negativo
Reseñas omitidas	⚠️ Omitir revisiones posteriores a incidentes, pasando directamente al siguiente incidente sin capturar lecciones aprendidas o mejoras arquitectónicas
Culpar a Cultura	⚠️ Centrar las revisiones posteriores a incidentes en la culpa individual en vez de mejoras del sistema, causando ocultamiento de incidentes e impidiendo el aprendizaje organizacional
Sin documentación arquitectónica	⚠️ Fallo al documentar cambios de arquitectura de seguridad dirigidos por aprendizajes de incidentes en registros de decisiones de arquitectura (ADR)
Tratamiento de síntomas	⚠️ Tratar solo síntomas de incidentes (contraseña comprometida) sin solucionar causas raíz (falta de MFA), permitiendo que ataques similares tengan éxito
Sin colaboración de lecciones	⚠️ Mantener los aprendizajes de incidentes dentro del equipo de respuesta en vez de compartir entre organizaciones, permitiendo incidentes similares en otras unidades comerciales
Sin actualizaciones de detección	⚠️ No actualizar reglas de detección o líneas base de comportamiento basándose en técnicas de ataque observadas, manteniéndose vulnerable a ataques similares
Sin seguimiento de mediciones	⚠️ No realizar un seguimiento del tiempo medio para detectar (MTTD), el tiempo medio para responder (MTTR) o las tendencias de ámbito, perdiendo oportunidades para identificar debilidades sistémicas
Revisiones demoradas	⚠️ Realización de revisiones posteriores a incidentes meses después de la resolución de incidentes cuando se olvidan los detalles y se pierde el impulso de mejora
Sin seguimiento de la rehabilitación	⚠️ Identificación de mejoras durante la revisión posterior al incidente pero sin implementarlas, permitiendo que incidentes similares se repitan