A resposta a incidentes de um fornecedor de análise de dados de saúde identificou o indicador inicial de comprometimento, uma credencial de conta de serviço comprometida, por meio da análise dos logs de autenticação, que mostravam a conta se autenticando a partir de um endereço IP fora de sua faixa histórica no terceiro dia do que acabou sendo uma violação de vinte e dois dias. A descoberta, no vigésimo segundo dia, veio de um alerta de DLP sem relação com o caso, sobre uma operação de preparação de dados anormalmente grande. A investigação retrospectiva confirmou o comprometimento da conta de serviço no terceiro dia, identificou sete eventos de autenticação adicionais nos dezenove dias seguintes e estabeleceu que a conta de serviço tinha permissões para três ambientes de dados distintos que guardavam dados de análise de clientes diferentes. A investigação não conseguiu confirmar, com os logs disponíveis, quais recursos de dados específicos a conta de serviço havia acessado em suas sessões autenticadas: o token de autenticação da conta de serviço foi registrado, mas as chamadas de API e as consultas a dados específicas executadas em cada sessão não foram capturadas no log de autenticação. A plataforma de API do fornecedor registrava as execuções de consultas separadamente, e esses logs tinham um período de retenção de trinta dias. Os dias três a um do comprometimento estavam dentro da janela de retenção; os logs de execução de consultas dos dias três a oito haviam sido excluídos. Os indicadores de comprometimento informaram aos investigadores que a conta de serviço foi usada. Os logs de consultas excluídos deixaram desconhecido o caminho específico de acesso aos dados nos primeiros oito dias. A notificação aos clientes informou que os dados podem ter sido acessados, e não que o acesso foi confirmado, para seis dos três clientes cujos ambientes a conta de serviço podia alcançar.
O que são, de fato, os indicadores de comprometimento de fornecedores?
Os indicadores de comprometimento de fornecedores são as evidências técnicas (eventos de autenticação, conexões de rede, alterações no sistema de arquivos, modificações no registro e execuções de processos) que demonstram a presença de um atacante no ambiente de um fornecedor. Os indicadores de comprometimento confirmam que houve acesso. Nem sempre confirmam para que esse acesso foi usado, especificamente quais dados foram acessados, quais comandos foram executados e quais alterações foram feitas durante o período de acesso não autorizado. A distinção entre saber que houve um comprometimento e saber o que o comprometimento alcançou é a lacuna entre a confirmação dos indicadores e a compreensão das consequências.
A lacuna entre indicador e consequência é o desafio fundamental da investigação de violações de fornecedores. Uma credencial de conta de serviço comprometida é um indicador de comprometimento claro: demonstra o uso não autorizado de uma credencial legítima. A consequência desse uso (o que o atacante acessou, consultou e exfiltrou) exige outra categoria de evidências: logs de chamadas de API, logs de execução de consultas, logs de acesso a bancos de dados e capturas de tráfego de rede. Esses logs no nível das consequências podem ter períodos de retenção, configurações de captura e requisitos de acesso diferentes dos logs de autenticação que revelam o indicador.
O problema da completude dos logs cria a limitação específica da investigação. Investigações que conseguem confirmar os indicadores, mas não as consequências (porque os logs no nível das consequências não foram retidos, não foram capturados ou não estão acessíveis), deixam clientes e investigadores na posição de saber que houve acesso sem saber o que foi acessado. Isso produz o pior resultado possível para a notificação: a obrigação de notificar porque o acesso não pode ser descartado, combinada com a impossibilidade de limitar a notificação aos registros comprovadamente expostos. A incerteza leva a decisões conservadoras de notificação que podem superestimar a exposição para cumprir o requisito regulatório de notificar quando não é possível descartar o acesso.
- Confirmação dos indicadores sem confirmação das consequências: houve acesso, consequências desconhecidas
- Logs de execução de consultas não retidos ou com retenção mais curta do que os logs de autenticação
- Logs de chamadas de API separados dos logs de autenticação, com retenção diferente
- Escopo das permissões das contas de serviço superior aos requisitos reais de acesso a dados
- Notificação forçada pela incerteza: a impossibilidade de descartar o acesso leva a uma notificação conservadora
Por que isso importa
Os indicadores de comprometimento de fornecedores são importantes para TPRM porque a avaliação do risco de violação pelo cliente, e a sua decisão sobre notificação regulatória, depende de entender não apenas que um fornecedor foi comprometido, mas o que o comprometimento alcançou em relação aos dados que o cliente compartilha com esse fornecedor. Um fornecedor cujos indicadores de comprometimento são claros, mas cujos logs de consequências estão ausentes ou incompletos, deixa o cliente sem condições de definir o escopo de sua exposição com a especificidade que o HIPAA, o GDPR e o PCI-DSS exigem para as decisões de notificação.
Onde a maioria das equipes erra
A falha mais recorrente é não distinguir entre evidências de indicadores e evidências de consequências nas avaliações de violações de fornecedores. Confirmar que um indicador de comprometimento foi identificado não confirma que a investigação consegue determinar o que o atacante alcançou com o acesso que o indicador representa.
- Confirmação dos indicadores equiparada à confirmação das consequências
- Retenção dos logs de consequências não avaliada: logs de consultas e de API separados dos de autenticação
- Escopo das permissões das contas de serviço não avaliado em relação ao acesso a dados do cliente
- Incerteza quanto ao escopo da notificação não tratada em contrato
- Registro de consequências não aprimorado após a violação para evitar incertezas futuras
Como é uma boa prática
Programas maduros de indicadores de comprometimento mantêm uma retenção alinhada entre as categorias de logs de indicadores e de consequências, limitam o escopo das permissões das contas de serviço para restringir os dados que a conta pode alcançar e preveem em contrato direitos de acesso aos logs de consequências que permitem aos clientes definir de forma independente o escopo de sua exposição.
- Retenção de logs alinhada: logs de autenticação e de consequências retidos pelo mesmo período
- Permissões mínimas necessárias para contas de serviço, limitando o raio de impacto do comprometimento de credenciais
- Direitos de acesso aos logs de consequências: acesso do cliente aos logs de consultas e de API para definir o escopo de violações
- Registro aprimorado após a violação: registro de consequências ampliado após a descoberta
- SLA de confirmação do escopo da notificação: prazo para confirmar ou descartar o acesso aos dados
Ferramentas
Registro em log de API e de consultas: eventos de dados do AWS CloudTrail, logs de auditoria de bancos de dados, logs do API Gateway
O registro no nível das consequências para chamadas de API e consultas a bancos de dados exige ativação explícita: os provedores de nuvem nem sempre ativam por padrão o registro de eventos de dados, devido às implicações de custo e volume. Para profissionais de TPRM, perguntar se o fornecedor tem o registro em log de API no nível dos dados ativado, capturando o que foi acessado, e não apenas que houve autenticação, é uma pergunta específica sobre o registro de consequências.
Desafios de governança
O desafio de governança do registro de consequências é o custo e o volume do registro em log de API e de consultas no nível dos dados. Registrar cada chamada de API e cada consulta ao banco de dados gera volumes de log significativamente maiores do que o registro apenas da autenticação. A solução de governança é o registro seletivo no nível dos dados para ambientes de alta sensibilidade, especificamente os ambientes que guardam dados regulados ou de alto valor.
- Perguntar se o registro em log de API no nível dos dados está ativado nos ambientes de dados do cliente
- Perguntar sobre a retenção dos logs de consequências: logs de consultas e de API versus logs de autenticação
- Perguntar sobre o escopo das permissões das contas de serviço: acesso mínimo necessário
- Prever em contrato o acesso aos logs de consequências para definir o escopo de violações
- Exigir o aprimoramento dos logs de consequências após qualquer violação, como parte da remediação
Se você faz parte de uma equipe pequena
Para o seu fornecedor de maior risco, faça duas perguntas sobre a arquitetura de registro em log. Primeira: quando uma conta de serviço se autentica no ambiente que guarda os seus dados, as chamadas de API e as consultas a dados específicas executadas durante essa sessão são registradas e retidas, e por quanto tempo? Segunda: se essa conta de serviço fosse comprometida, a investigação conseguiria confirmar especificamente quais dados foram acessados durante o período de comprometimento, ou apenas confirmar que a conta se autenticou? Essas duas perguntas revelam se o fornecedor consegue confirmar consequências ou apenas indicadores.
- Perguntar se as chamadas de API e as consultas a dados executadas durante as sessões são registradas
- Perguntar por quanto tempo os logs de execução de consultas e de chamadas de API são retidos
- Perguntar se a investigação do comprometimento de uma conta de serviço conseguiria confirmar os dados acessados
- Perguntar sobre o escopo das permissões das contas de serviço
O que exigir
Pergunte diretamente:
"Se uma conta de serviço com acesso aos nossos dados fosse comprometida, a sua investigação conseguiria confirmar especificamente quais dados essa conta acessou durante o período de comprometimento, ou vocês só conseguiriam confirmar que a conta foi usada? E por quanto tempo os logs de chamadas de API e de execução de consultas são retidos?"
O que esperar como evidência
- Confirmação dos logs de API e de consultas no nível dos dados
- Período de retenção dos logs de consequências
- Escopo das permissões das contas de serviço
- Capacidade de investigação para confirmar as consequências do acesso aos dados
A um fornecedor que confirma ter capacidade de detecção de comprometimentos deve-se perguntar se o seu registro em log permite confirmar as consequências, e não apenas detectar indicadores. O indicador informa aos investigadores que houve acesso. O log de consequências informa para que o acesso foi usado.
Como comprovar
- Documentação da retenção dos logs de consequências
- Confirmação do registro em log de API no nível dos dados
- Registros do escopo das permissões das contas de serviço
- Documentação dos direitos de acesso aos logs de consequências
Principal conclusão
Conta de serviço comprometida no terceiro dia. Detectada no vigésimo segundo dia. Dezenove dias de sessões autenticadas em três ambientes de dados de clientes. Logs de execução de consultas dos dias três a oito: excluídos. Dados acessados nesses oito dias: desconhecidos. Notificação exigida porque o acesso não pode ser descartado. Escopo da notificação: incerto. O indicador de comprometimento é claro. A consequência não pode ser confirmada em oito dos dezenove dias. O registro em log no nível dos dados, com as chamadas de API e as execuções de consultas capturadas junto com a autenticação, teria resolvido a incerteza. Uma retenção dos logs de consequências alinhada à retenção dos logs de autenticação teria evitado a exclusão. O indicador diz que a porta foi aberta. O log de consequências diz o que foi levado da sala.