Padrões de resposta a incidentes
Saiba mais sobre Well-Architected Trust → Resposta a incidentes de segurança
Incidentes de segurança ocorrerão apesar das medidas preventivas. A arquitetura Trust requer design para detectibilidade, resposta rápida, investigação forense e recuperação gratificante. Esta página consolida os padrões de resposta a incidentes da seção Resposta a incidentes do pilar Trust, abrangendo a arquitetura de detecção, os procedimentos de resposta, as funcionalidades forenses e o aprendizado pós-incidente.
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Monitoramento de evento | ✅ Habilite o Monitoramento de evento capturando padrões de login, exportações de dados em massa, alterações de permissão e atividade de API com roteamento para plataformas SIEM para retenção excedendo limites de retenção nativos |
| Políticas de segurança da transação | ✅ Configure políticas que avaliam eventos em tempo real para bloquear ações suspeitas, exigir autenticação avançada ou acionar notificações com base em linhas de base comportamentais |
| Trilha de auditoria de configuração | ✅ Monitorar alterações de configuração administrativa permitindo a detecção de modificações não autorizadas com retenção de 180 dias |
| Registro de aplicativo personalizado | Implementar registro de evento relevante para a segurança no Apex capturando falhas de autenticação, recusas de autorização e padrões de entrada suspeitos |
| Monitoramento de verificação de integridade | ✅ Configure a detecção automatizada de desvio de configuração de linhas de base de segurança que podem indicar alterações não autorizadas |
| Integração de SIEM | ✅ Rotear registros de Monitoramento de evento para plataformas de SIEM corporativas para correlação com a análise comportamental e a telemetria de segurança corporativa |
| Regras de alerta | ✅ Projete regras de alerta detectando padrões suspeitos (acesso em massa fora do horário comercial, login de novas regiões geográficas, escalonamento rápido de permissões) com linhas de base comportamentais para minimizar falsos positivos |
| Análise comportamental | ✅ Estabelecer linhas de base comportamental habilitando a detecção de anomalia para volumes de acesso a dados incomuns, atividade administrativa fora das horas e padrões de consumo da API |
| Detecção de vários canais | ✅ Implementar a detecção por meio de Monitoramento de evento, Segurança da transação, Trilha de auditoria de configuração, registro personalizado e Verificação de integridade fornecendo vários sinais de detecção independentes |
| Armazenamento de log imutável | ✅ Encaminhe registros para armazenamento externo imutável que os invasores não podem modificar mesmo com acesso administrativo ao Salesforce, garantindo a integridade da evidência forense |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Somente retenção de registro nativa | ⚡️ Dependendo apenas de janelas nativas de retenção de trilha de auditoria do Salesforce (limites nativos de Monitoramento de evento, trilha de auditoria de configuração de 180 dias) sem arquivamento externo, descobrir logs expirados quando a investigação requer análise histórica |
| Sem linhas de base comportamental | ⚡️ Não ter linhas de base comportamentais para detecção de anomalia, gerando alertas falsos positivos excessivos que treinam equipes de segurança para ignorar notificações |
| Sem integração de SIEM | ⚡️ Falta de integração do SIEM corporativo, falta de oportunidades de correlação com a telemetria de segurança de outros sistemas que revelariam padrões de compromisso mais amplos |
| Revisão manual do registro | Dependendo da revisão periódica do registro manual em vez do alerta automatizado, descobrir incidentes semanas ou meses após a ocorrência quando o dano é extenso |
| Nenhuma política de segurança da transação | ⚡️ Sem políticas de Segurança da transação em tempo real, sem capacidade de bloquear ações suspeitas para evitar danos antes que eles ocorram |
| Cobertura incompleta | ⚡️ Monitorar apenas o subconjunto de eventos relevantes para a segurança (login, mas não acesso a dados, alterações de configuração, mas não modificações de permissão) criando pontos cegos |
| Alertar fadiga | Gerar alertas falsos positivos excessivos sem ajuste, treinar equipes para ignorar notificações, incluindo eventos de segurança legítimos |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Limites de isolamento | ✅ Projetar a arquitetura para que os componentes comprometidos possam ser isolados por meio da revogação do conjunto de permissões, alterações de restrição de IP ou encerramento da sessão sem interromper funções de negócios essenciais |
| Gerenciamento de sessão | ✅ Implementar recursos de encerramento rápido da sessão para contas comprometidas, incluindo forçar logout e invalidar sessão em todas as sessões ativas |
| Revogação da permissão | ✅ Conceda privilégios por meio de conjuntos de permissões em vez de perfis de linha de base para que a revogação seja rápida: remover a atribuição do conjunto de permissões revoga o acesso quando nenhum perfil ou outra atribuição concede independentemente a mesma permissão |
| Restrições de IP | ✅ Configure intervalos de IP de login em nível de perfil para contas privilegiadas para que logins de outros endereços sejam negados diretamente, permitindo o rápido isolamento em nível de rede para locais administrativos conhecidos |
| Congelar conta de usuário | ✅ Implementar procedimentos de congelamento de conta que impedem a autenticação enquanto preservam dados para investigação sem excluir a conta comprometida |
| Controles de acesso à API | ✅ Projete a autenticação da API com recursos de revogação de token que permitem o rápido isolamento de contas de integração comprometidas |
| Isolamento de várias organizações | ✅ Para ativos de alto valor, avalie a arquitetura de várias organizações fornecendo o isolamento mais forte para componentes críticos ao custo de maior complexidade operacional |
| Procedimentos de vidro de interrupção de emergência | ✅ Mantenha os procedimentos de acesso de vidro quebrado documentados para acesso administrativo de emergência com auditoria e validação pós-uso |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Sem limites de isolamento | ⚡️ Falta de limites de isolamento arquitetônico exigindo o desligamento completo do sistema para conter qualquer compromisso, interrompendo todas as funções de negócios |
| Acesso permissivo excessivo | ⚡️ Conceder amplas permissões Modificar todos os dados para evitar a revogação de privilégios granulares sem interromper vários processos comerciais |
| Contas de serviço compartilhado | ⚡️ Usar uma única conta compartilhada “Usuário da API” ou “Usuário de integração” em vários sistemas, evitando o isolamento de integração comprometida específica sem interromper todas as integrações |
| Sem restrições de IP | ⚡️ Sem permissão de IP para contas privilegiadas, sem recursos de contenção em nível de rede quando as contas são comprometidas |
| Sem gerenciamento de sessão | ⚡️ Falta de recursos de encerramento de sessão exigindo redefinição de senha como única maneira de forçar o logout, introduzindo atrasos durante janelas de resposta crítica |
| Sem procedimentos de emergência | ⚡️ Não ter procedimentos de acesso de emergência ou de vazamento documentados, improvisando decisões críticas sob pressão durante incidentes ativos |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Logs de monitoramento de evento | ✅ Capture registros de atividade detalhados, incluindo ações do usuário, chamadas à API, eventos de autenticação e padrões de acesso a dados com detalhes suficientes para análise forense |
| Trilha de auditoria de campo | ✅ Habilite a Trilha de auditoria de campo preservando o histórico de alterações de dados para campos Restrito e Confidencial com requisitos regulatórios de retenção correspondentes (dê suporte à retenção indefinida; confirme o período necessário em relação ao regulamento regulador) |
| Armazenamento imutável | ✅ Encaminhe registros para armazenamento imutável externo que os invasores não podem modificar, garantindo a integridade da evidência forense em toda a investigação |
| Trilha de auditoria de configuração | ✅ Preserve o histórico de alterações de configuração administrativa permitindo a investigação de modificações não autorizadas do sistema com retenção de 180 dias |
| Avaliação de escopo | ✅ Projetar modelos de permissão e controles de acesso a dados que permitem uma avaliação rápida do escopo da exposição de dados com base em privilégios de conta comprometidos |
| Correlação de alteração | ✅ Mantenha a correlação entre alterações de configuração da Trilha de auditoria de configuração e padrões de atividade de Monitoramento de evento que permitem a investigação de técnicas de invasores |
| Registro de acesso a dados | ✅ Registrar todo o acesso a dados Restrito e Confidencial permitindo a investigação de quais dados foram expostos durante o período de compromisso |
| Trilha de auditoria de integração | ✅ Capture padrões de autenticação, autorização e troca de dados da API para sistemas integrados que permitem a investigação de compromisso entre sistemas |
| Preservação de evidência | ✅ Encaminhe registros e trilhas de auditoria continuamente para armazenamento externo imutável para que a evidência forense seja preservada e disponível quando um incidente for investigado |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Armazenamento de log mutável | ⚡️ Armazenar registros apenas no Salesforce em que os invasores com acesso administrativo podem excluir ou modificar evidências forenses |
| Detalhe do registro insuficiente | ⚡️ Capturar eventos de alto nível sem detalhes suficientes para investigação (login registrado, mas não endereço IP, acesso a dados registrado, mas não registros específicos) |
| Sem registro de acesso a dados | ⚡️ Falta de registro detalhado do acesso a dados Restrito e Confidencial, não é possível avaliar o escopo da exposição de dados durante a notificação de violação |
| Trilha de auditoria de campo ausente | ⚡️ Não habilitar a Trilha de auditoria de campo para campos confidenciais, não é possível determinar quais valores de dados foram expostos durante o compromisso |
| Sem correlação de alteração | ⚡️ Não ter funcionalidade de correlação entre alterações de configuração da Trilha de auditoria de configuração e padrões de atividade de Monitoramento de evento subsequentes |
| Histórico de auditoria excluído | Permitir que o histórico de auditoria expire antes do mínimo de retenção regulatória definido pelas normas reguladoras para sua implantação, criando violações de conformidade |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Objetivos de tempo de recuperação | ✅ Defina e teste o Objetivo de tempo de recuperação (RTO) e o Objetivo de ponto de recuperação (RPO) para cenários de incidente de segurança, não apenas cenários de recuperação de desastres |
| Procedimentos de recuperação testados | ✅ Processos de recuperação de documentos para contas comprometidas, extração de dados em massa, implantações não autorizadas, escalonamento de privilégio e compromisso de pacote com testes trimestrais |
| Validação de backup | ✅ Valide a integridade do backup regularmente garantindo que os recursos de restauração funcionem durante incidentes de segurança, não apenas falhas operacionais |
| Recursos de reversão | ✅ Projetar pipelines de implementação com procedimentos de reversão testados para implantações de código não autorizadas ou alterações de configuração mal-intencionadas |
| Rotação da credencial | ✅ Implementar procedimentos de rotação rápida de credenciais para contas de integração comprometidas, usuários da API e credenciais nomeadas |
| Restauração de permissão | ✅ Procedimentos de documento para restaurar o acesso adequado após ações de isolamento excessivamente amplas durante a resposta ao incidente |
| Restauração de dados | ✅ Projetar recursos de recuperação de dados para lidar com a corrupção ou exclusão de dados resultantes de incidentes de segurança, diferentes da recuperação de desastres |
| Continuidade do serviço | ✅ Arquite soluções para que os procedimentos de resposta a incidentes de segurança mantenham a continuidade das funções críticas do negócio durante a investigação e a remediação |
| Validação de restauração | ✅ Testar os procedimentos de recuperação trimestralmente para validar se os sistemas restaurados funcionam corretamente e se o compromisso não persistiu durante a restauração |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Procedimentos não testados | ⚡️ Ter procedimentos de recuperação documentados que nunca foram testados por meio de exercícios, descobrir durante incidentes reais que os procedimentos estão incompletos ou incorretos |
| Sem RTO/RPO para segurança | ⚡️ Definir metas de tempo de recuperação apenas para recuperação de desastres sem considerar cenários de incidente de segurança que exigem diferentes procedimentos de recuperação |
| Sem capacidade de reversão | ⚡️ Falta de procedimentos de reversão de implementação para implantações de código não autorizadas, exigindo um novo desenvolvimento completo para remover alterações mal-intencionadas |
| Backups não validados | ⚡️ Nunca teste a restauração de backup, descobrindo durante incidentes que os backups estão corrompidos ou incompletos |
| Sem procedimentos de rotação de credenciais | ⚡️ Não ter procedimentos de rotação rápida de credenciais para contas de integração comprometidas, deixando as credenciais comprometidas ativas durante a investigação |
| Processos de recuperação manual | ⚡️ Dependendo inteiramente dos procedimentos de recuperação manual durante incidentes, introduzindo erros e atrasos quando a velocidade é crítica |
| Sem teste de restauração | ⚡️ Nunca validar se os sistemas restaurados funcionam corretamente após a recuperação, potencialmente reintroduzindo compromisso ou corrupção de dados |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Resposta da conta do usuário comprometida | ✅ Procedimentos de documento: congelar usuário, forçar a redefinição da credencial, revisar a Trilha de auditoria de configuração e os registros de acesso a dados para o período de compromisso, avaliar o escopo da exposição de dados, executar a notificação de violação se dados Restrito acessado |
| Resposta de extração de dados em massa | ✅ Procedimentos de documento: revogar sessão imediatamente, restringir permissões, identificar registros e níveis de classificação afetados, executar notificação de violação regulatória dentro da linha do tempo que os regulamentos regulatórios definem para sua implementação |
| Resposta de implementação de código não autorizada | ✅ Procedimentos de documento: implantação de reversão imediatamente, auditoria de todas as alterações da credencial comprometida, análise da segurança do pipeline para desvio de autorização, verificação do código implantado para backdoors persistentes |
| Resposta de escalação de privilégio | ✅ Procedimentos de documento: revogar privilégios escalonados imediatamente, auditar atividades realizadas com acesso aprimorado, investigar como a escalação ignorou controles de aprovação, implementar controles de compensação |
| Resposta de compromisso do pacote AppExchange | ✅ Procedimentos de documento: isolar permissões de pacote, avaliar dados acessados por pacote, avaliar opções de substituição de pacote, documentar lições aprendidas para critérios de avaliação de pacote |
| Sinais de detecção | ✅ Configure o monitoramento para detectar cada cenário: anomalias de login para contas comprometidas, volume de exportação de relatório para exfiltração, monitoramento de implementação para código não autorizado, monitoramento de alteração de permissão para escalação |
| Exercícios de mesa | ✅ Realizar exercícios de mesa testando procedimentos de resposta para cenários específicos da plataforma que validam a prontidão da equipe e a completude do procedimento |
| Automação de resposta | ✅ As políticas de segurança da transação em tempo real bloqueiam automaticamente ações suspeitas, exigem autenticação avançada ou notificam os respondentes sobre sinais de detecção de alta confiança, fornecendo contenção automatizada que reduz o tempo de resposta |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Somente planos de resposta genérica | ⚡️ Ter apenas procedimentos genéricos de resposta a incidentes sem orientação específica do Salesforce, improvisando ações específicas da plataforma durante incidentes ativos |
| Sem configuração de detecção | ⚡️ Não ter monitoramento configurado para detectar cenários específicos da plataforma (exportação em massa, escalonamento de privilégios, implantação não autorizada), descobrir incidentes por meio de relatórios de usuários ou auditorias |
| Sem exercícios de mesa | ⚡️ Nunca realizar exercícios de mesa para validar a familiaridade da equipe com procedimentos de resposta específicos da plataforma, descobrir lacunas do Knowledge durante incidentes reais |
| Sem automação | Resposta totalmente manual para todos os incidentes sem políticas de Segurança da transação em tempo real para contenção automatizada, introduzindo atrasos quando o bloqueio imediato pode reduzir o dano |
| Guias de respostas ausentes | ⚡️ Falta de manuais de resposta documentados para cenários comuns (conta de usuário comprometida, exfiltração de dados, implantação de código não autorizada) |
| Sem procedimentos de notificação de violação | ⚡️ Sem procedimentos para requisitos de notificação de violação regulatória, dificuldade para entender as obrigações durante incidentes reais quando as linhas do tempo são rígidas |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Comunicação fora da banda | ✅ Estabelecer canais de comunicação que não dependam de sistemas potencialmente comprometidos (arcas de telefone, plataformas de mensagens externas) para coordenar a resposta |
| Procedimentos de escalação | ✅ Caminhos de escalação de documentos da detecção inicial até a notificação executiva com informações de contato e critérios de escalação |
| Modelos de notificação | ✅ Mantenha modelos de notificação predefinidos para tipos de incidentes comuns que permitem uma comunicação rápida com partes interessadas, clientes e reguladores |
| Identificação da parte interessada | ✅ Identifique as partes interessadas que precisam de notificação para diferentes tipos de incidentes, incluindo executivos, legisladores, conformidade, usuários afetados e autoridades reguladoras |
| Linhas do tempo de notificação regulatória | ✅ Documente os requisitos de notificação regulatória de cada jurisdição, confirmados em relação ao regulamento regulatório para sua implantação, com procedimentos que garantem a conformidade oportuna |
| Coordenação interna | ✅ Projetar procedimentos de coordenação de incidentes especificando papéis e responsabilidades (comandante de incidentes, lead técnico, lead de comunicações, ligação legal) |
| Coordenação externa | ✅ Estabelecer procedimentos para coordenar com o Suporte do Salesforce, investigadores forenses externos, consultores jurídicos e agentes de imposição da lei conforme apropriado |
| Comunicação de status | ✅ Implemente o ritmo de comunicação de status regular durante incidentes ativos mantendo as partes interessadas informadas sem sobrecarregar a equipe de investigação |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Nenhuma comunicação fora da banda | ⚡️ Dependendo inteiramente de emails potencialmente comprometidos ou mensagens internas para coordenação de incidentes, perdendo a capacidade de comunicação quando os canais principais são comprometidos |
| Caminhos de escalação pouco claros | ⚡️ Não ter procedimentos de escalação documentados, causando atrasos e confusão sobre quem deve ser notificado e quando |
| Nenhum modelo de notificação | ⚡️ Melhorar as notificações de incidentes durante incidentes ativos sob pressão de tempo, resultando em comunicações incompletas ou incorretas |
| Listas de partes interessadas ausentes | ⚡️ Não ter listas de partes interessadas previamente identificadas, descobrir durante incidentes que partes críticas (legal, conformidade, executivos) não foram notificadas |
| Sem conhecimento de linha do tempo regulatória | ⚡️ Não estar ciente das linhas do tempo de notificação regulatória que se aplicam à sua implementação durante a resposta a incidentes, prazos ausentes e criação de violações adicionais de conformidade |
| Papéis ambíguos | ⚡️ Ter papéis e responsabilidades de resposta a incidentes não claros, causando confusão sobre quem tem autoridade para tomar decisões de contenção |
| Sem procedimentos de coordenação externos | ⚡️ Não ter relacionamentos ou procedimentos estabelecidos para engajar o Suporte do Salesforce, investigadores forenses ou a imposição da lei quando necessário |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Cultura sem culpa | ✅ Concentre análises pós-incidente em melhorias do sistema, em vez de culpas individuais, permitindo o aprendizado organizacional sem medo de repercussões |
| Documentação da linha do tempo do incidente | ✅ Documente a linha do tempo do incidente completa, incluindo compromisso inicial, detecção, ações de resposta e resolução com carimbos de data e hora precisos |
| Análise de falha do controle | ✅ Identificar quais controles preventivos e detetivos falharam para prevenir ou detectar o incidente, informando melhorias arquitetônicas |
| Documentação de deficiência arquitetônica | ✅ Fraquezas arquitetônicas do documento reveladas pelo incidente em Registros de decisão de arquitetura (ADRs) que capturam alterações de segurança |
| Priorização de remediação | ✅ Priorizar a remediação com base no potencial de redução de risco, abordando causas-raiz em vez de sintomas |
| Compartilhamento de aula | ✅ Compartilhe as lições aprendidas entre equipes e unidades de negócios para evitar incidentes semelhantes em outras partes da organização |
| Atualizações de regra de detecção | ✅ Atualizar regras de detecção e linhas de base comportamentais com base em técnicas de ataque observadas durante a investigação |
| Refinamento do procedimento de resposta | ✅ Atualize os procedimentos de resposta ao incidente com base no que funcionou e no que não funcionou durante a resposta real ao incidente |
| Rastreamento de métricas | ✅ Acompanhe o tempo médio para detectar (MTTD), o tempo médio para responder (MTTR) e o escopo do impacto ao longo do tempo, identificando tendências que exigem investimento arquitetônico |
| Revisar ritmo | ✅ Realize uma revisão pós-incidente oportuna enquanto os detalhes permanecem atualizados e o impulso para melhoria existe |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Revisões ignoradas | ⚡️ Ignorar revisões pós-incidente, passar diretamente para o próximo incidente sem capturar lições aprendidas ou melhorias arquitetônicas |
| Cultura da culpa | ⚡️ Focar revisões pós-incidente na culpa individual, em vez de melhorias do sistema, causando ocultação de incidentes e impedindo o aprendizado organizacional |
| Sem documentação arquitetônica | ⚡️ Falha em documentar alterações na arquitetura de segurança conduzidas por aprendizado de incidentes em Registros de decisão de arquitetura (ADRs) |
| Tratamento de sintomas | ⚡️ Lidar apenas com sintomas de incidentes (senha comprometida) sem corrigir as causas-raiz (sem MFA), permitindo o sucesso de ataques semelhantes |
| Sem compartilhamento de aula | ⚡️ Manter o aprendizado de incidentes na equipe de resposta em vez de compartilhar em toda a organização, permitindo incidentes semelhantes em outras unidades de negócios |
| Nenhuma atualização de detecção | ⚡️ Falha na atualização de regras de detecção ou linhas de base comportamentais com base em técnicas de ataque observadas, permanecendo vulnerável a ataques semelhantes |
| Sem rastreamento de métricas | ⚡️ Não rastrear o tempo médio para detectar (MTTD), o tempo médio para responder (MTTR) ou tendências de escopo, oportunidades ausentes para identificar fraquezas sistêmicas |
| Revisões atrasadas | Realizar análises pós-incidente meses após a resolução do incidente quando os detalhes forem esquecidos e o impulso de melhoria for perdido |
| Sem acompanhamento de remediação | ⚡️ Identificar melhorias durante a revisão pós-incidente, mas não implementá-las, permitindo a recorrência de incidentes semelhantes |