Patrones de respuesta ante incidentes
Obtenga más información acerca de Well-Architected Confide → Respuesta ante incidentes de seguridad
Los incidentes de seguridad se producirán a pesar de las medidas preventivas. Trust architecture requiere el diseño para la detectabilidad, la respuesta rápida, la investigación forense y la recuperación elegante. Esta página consolida los patrones de respuesta ante incidentes desde la sección Respuesta ante incidentes del pilar Trust, que abarca la arquitectura de detección, los procedimientos de respuesta, las funciones forenses y el aprendizaje posterior al incidente.
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Monitoreo de eventos | ✅ Activar Monitoreo 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 retención que superan los límites de retención nativos |
| Políticas de seguridad de transacciones | ✅ Configurar políticas evaluando eventos en tiempo real para bloquear acciones sospechosas, requerir autenticación de pasos o desencadenar notificaciones basándose en líneas base de comportamiento |
| Configuración del seguimiento de auditoría | ✅ Monitorear 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 |
| Monitoreo de comprobación de estado | ✅ Configurar la detección automatizada de desviación de configuración desde líneas base de seguridad que podrían indicar cambios no autorizados |
| Integración de SIEM | ✅ Enrutar registros de Monitoreo de eventos a plataformas SIEM de compañía para su correlación con telemetría de seguridad de compañía y 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 permiten 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 Monitoreo de eventos, Seguridad de transacciones, Configuración del 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 de Salesforce nativos (límites nativos de Monitoreo 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 capacitan a los equipos de seguridad para ignorar notificaciones |
| Sin integración SIEM | ⚠️ Falta de integración de SIEM de compañía, pérdida de oportunidades de correlación con la 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 de registros 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 evitando daños antes de que se produzcan |
| Cobertura incompleta | ⚠️ Monitoreo solo de subconjuntos de eventos relevantes para la seguridad (acceso de inicio de sesión pero no de datos, cambios de configuración pero no modificaciones de permisos) creando puntos ciegos |
| Alertar de fatiga | ⚠️ 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é 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 terminación de sesión sin interrumpir funciones de negocio críticas |
| Gestión de sesiones | ✅ Implementar funciones de terminación de sesión rápida para cuentas comprometidas incluyendo el cierre de sesión forzado y la invalidación de sesión entre 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: La eliminación de 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 | ✅ Configurar 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, permitiendo un aislamiento rápido a nivel de red en ubicaciones administrativas conocidas |
| Inmovilización de cuentas de usuario | ✅ Implementar procedimientos de inmovilización de cuentas que evitan la autenticación preservando al mismo tiempo 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 costo de una complejidad operativa aumentada |
| Procedimientos de vidrio 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 de negocio |
| Acceso demasiado permisivo | ⚠️ Otorgar permisos amplios Modificar todos los datos evitando la revocación granular de privilegios sin interrumpir múltiples procesos de negocio |
| Cuentas de servicio compartidas | ⚠️ Utilización de una única cuenta compartida de “Usuario de API” o “Usuario de integración” 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 listas 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 acceso de emergencia o rotura de vidrio, improvisar decisiones críticas bajo presión durante incidentes activos |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Registros de monitoreo 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 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 coincide con requisitos reguladores (admite retención indefinida; confirme el periodo requerido en 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 |
| Configuración del seguimiento de auditoría | ✅ Preservar el historial de cambios de configuración administrativa permitiendo 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 Monitoreo 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 permitiendo la investigación de 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 las pruebas forenses se mantengan y estén disponibles cuando se investiga un incidente |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Almacenamiento de registros mutable | ⚠️ Almacenamiento de registros solo en 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 (registro de inicio de sesión pero no dirección IP, registro de acceso a datos pero no registros específicos) |
| Sin registro de acceso a datos | ⚠️ Falta de registro detallado del acceso a datos restringidos y confidenciales, incapaz de 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 activa 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 Monitoreo de eventos posteriores |
| Historial de auditoría eliminado | ⚠️ Permitir que el historial de auditoría caduque antes del mínimo de retención regulatoria que establece la regulación vigente para su implementación, creando infracciones de cumplimiento |
Patrones
| Dónde buscar | Qué 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 | ✅ Validar la integridad de la copia de seguridad regularmente garantizando que las funciones de restauración funcionan 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 ante incidentes |
| Restauración de datos | ✅ Diseñar funciones de recuperación de datos abordando la corrupción o eliminación de datos resultante de incidentes de seguridad, distinta de la recuperación de desastres |
| Continuidad de servicio | ✅ Soluciones de arquitecto para que los procedimientos de respuesta ante incidentes de seguridad mantengan la continuidad crítica de las funciones de negocio durante la investigación y la solución |
| Validación de restauración | ✅ Pruebe procedimientos de recuperación trimestralmente validando que los sistemas restaurados funcionan correctamente y que no persistió el compromiso 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 tener en cuenta 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 remodelación completa para eliminar cambios malintencionados |
| 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, la introducción de 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é 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 de normativa dentro del plazo que la normativa vigente establece para su implementación |
| Respuesta de implementación de código no autorizado | ✅ Procedimientos de documentos: implementación de reversión inmediatamente, audite todos los cambios desde credenciales comprometidas, revise la seguridad de oportunidades en curso para omitir la autorización, explore 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 el monitoreo detectando cada escenario: anomalías de inicio de sesión para cuentas comprometidas, volumen de exportación de reportes para exfiltración, monitoreo de implementación para código no autorizado, monitoreo de cambio de permisos para distribución |
| Ejercicios de sobremesa | ✅ Realizar ejercicios de sobremesa probando procedimientos de respuesta para escenarios específicos de plataforma validando la preparación del equipo y la integridad 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 de respuesta ante incidentes genéricos sin directrices específicas de Salesforce, improvisando acciones específicas de plataforma durante incidentes activos |
| Sin configuración de detección | ⚠️ No tener ningún monitoreo configurado para detectar escenarios específicos de plataforma (exportación masiva, distribución de privilegios, implementación no autorizada), descubrir incidentes a través de reportes de usuario o auditorías |
| Sin ejercicios de sobremesa | ⚠️ 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 los requisitos de notificación de incumplimiento normativo, se afanan en comprender las obligaciones durante incidentes reales cuando las cronologías son ajustadas |
Patrones
| Dónde buscar | Qué 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 permitiendo una comunicación rápida con 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ías de notificación reglamentaria | ✅ Documente los requisitos de notificación regulatoria de cada jurisdicción, confirmados con la regulación vigente 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 incidente, líder técnico, líder de comunicaciones, enlace legal) |
| Coordinación externa | ✅ Establecer procedimientos para coordinar con el Servicio de asistencia de Salesforce, investigadores forenses externos, asesores legales y agentes del orden según corresponda |
| Comunicación de estado | ✅ Implementar una cadencia de comunicación de estado regular durante incidentes activos manteniendo informadas a las partes interesadas sin abrumar al equipo de investigación |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Sin comunicación fuera de banda | ⚠️ Dependiendo completamente del email 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 causa 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 identificadas previamente, descubrir durante incidentes que partes críticas (legales, cumplimiento, ejecutivos) no fueron notificadas |
| Sin conocimiento de cronología regulatoria | ⚠️ Desconociendo los plazos de notificación regulatorios que se aplican a su implementación durante la respuesta ante incidentes, incumpliendo plazos y creando infracciones de cumplimiento adicionales |
| Funciones ambiguas | ⚠️ Tener funciones y responsabilidades de respuesta ante incidentes poco claras, causando 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é aspecto tiene |
|---|---|
| Cultura sin culpa | ✅ Centrar 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 de incidentes completa incluyendo compromisos iniciales, detección, acciones de respuesta y 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 arquitectónicas 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 basándose en el potencial de reducción de riesgos, abordando causas raíz en vez de síntomas |
| Colaboración de lecciones | ✅ Compartir lecciones aprendidas entre equipos y unidades de negocio 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 ante incidentes basándose en lo que funcionó y lo que no durante la respuesta ante incidentes real |
| Seguimiento de mediciones | ✅ Realizar un seguimiento del tiempo medio para detectar (MTTD), el tiempo medio para responder (MTTR) y el ámbito de impacto a lo largo del tiempo identificando tendencias que requieren inversión arquitectónica |
| Revisar cadencia | ✅ Realizar una revisión oportuna posterior al incidente mientras los detalles permanecen actualizados y existe impulso para la mejora |
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 la cultura | ⚠️ Centrar las revisiones posteriores a incidentes en la culpa individual en vez de mejoras del sistema, causando ocultación 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 | ⚠️ Solucionar 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 el aprendizaje de incidentes en el equipo de respuesta en vez de compartir entre organizaciones, permitiendo incidentes similares en otras unidades de negocio |
| Sin actualizaciones de detección | ⚠️ Fallo en la actualización de reglas de detección o líneas base de comportamiento basadas en técnicas de ataque observadas, permaneciendo 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 solución | ⚠️ Identificar mejoras durante la revisión posterior al incidente pero no implementarlas, permitiendo que se repitan incidentes similares |