O fornecedor de uma fintech que atuava como operador de dados de pagamento detectou um incidente de segurança às 8h de uma segunda-feira: sua plataforma de EDR havia identificado atividade incomum de PowerShell em um servidor do cluster de processamento de pagamentos. O analista do SOC do fornecedor classificou o incidente como P2 com base nos indicadores iniciais: nenhum acesso a dados confirmado, escopo limitado da atividade anômala e uma avaliação preliminar de que a atividade poderia ser um script de automação mal configurado, e não um ataque. O procedimento de resposta P2 do fornecedor previa um período de investigação de doze horas antes do escalonamento para P1, se confirmado, e a notificação ao cliente no procedimento P2 ocorria em trinta e seis horas caso o incidente fosse confirmado como um evento de segurança real envolvendo dados de clientes. Na décima segunda hora, a investigação confirmou que a atividade era maliciosa: um ataque baseado em credenciais contra o servidor de pagamentos. O incidente foi escalonado internamente para P1, mas a notificação ao cliente continuou seguindo o cronograma do procedimento P2, porque o processo de reclassificação exigia uma aprovação da gerência que só foi concluída na trigésima hora. A notificação ao cliente ocorreu na trigésima sexta hora. A equipe regulatória da fintech, ao receber a notificação, percebeu imediatamente que sua obrigação de notificação de incidentes segundo o PCI-DSS estava correndo desde a detecção inicial pelo fornecedor, na hora zero. Restavam trinta e seis horas para concluir uma notificação que o PCI-DSS exigia em até setenta e duas horas após a “parte responsável” tomar conhecimento do incidente.
O que é, de fato, o problema do escalonamento de incidentes entre fornecedores?
O escalonamento de incidentes entre fornecedores é o desafio de garantir que os incidentes de segurança nos ambientes dos fornecedores que afetam dados do cliente sejam escalonados ao cliente, e às autoridades reguladoras, em prazos que atendam às obrigações regulatórias do cliente, e não apenas aos SLAs internos de gestão de incidentes do fornecedor. Os modelos de gestão de incidentes dos fornecedores classificam os incidentes por gravidade e atribuem SLAs de resposta calibrados às prioridades operacionais do fornecedor. Essas classificações e SLAs internos podem não estar alinhados com os prazos regulatórios de notificação que se aplicam aos dados do cliente.
O problema do desalinhamento de classificação é a falha central de escalonamento. As equipes de gestão de incidentes dos fornecedores classificam os incidentes com base no impacto operacional no ambiente do fornecedor: interrupção de serviço, disponibilidade dos sistemas e gravidade de uma violação de dados confirmada. Elas podem não classificar um incidente com base nas suas implicações para as obrigações de notificação regulatória do cliente, que podem ser acionadas por qualquer acesso a dados regulados, independentemente do impacto no serviço ou de exfiltração confirmada. Um incidente que o fornecedor classifica como P2 por ainda não ter confirmado a exfiltração de dados pode já ter iniciado a contagem do prazo de setenta e duas horas de notificação do GDPR do cliente, com o acesso não autorizado inicial a um sistema que contém dados pessoais de clientes.
O problema da notificação em cascata é a dimensão do prazo regulatório. O artigo 33 do GDPR exige a notificação à autoridade de controle em até setenta e duas horas após o controlador “tomar conhecimento” de uma violação de dados pessoais. O controlador normalmente toma conhecimento quando o operador o notifica. O operador toma conhecimento quando sua equipe de segurança detecta o incidente. O intervalo entre a detecção pelo operador e a notificação ao controlador, determinado pelos procedimentos internos de escalonamento e notificação do fornecedor, determina diretamente quanto da janela de setenta e duas horas resta quando o cliente recebe a notificação. Um fornecedor que notifica na trigésima sexta hora deixa ao cliente trinta e seis horas para uma notificação que exige revisão jurídica, avaliação do escopo e comunicação regulatória.
- Classificação do fornecedor que não aciona a notificação imediata do cliente: procedimentos de P2 com notificação tardia do cliente
- Prazo regulatório que começa na detecção pelo fornecedor: a obrigação do cliente corre durante a investigação do fornecedor
- Atrasos de reclassificação: processos internos de aprovação que retardam o escalonamento
- Sem participação do cliente na classificação de incidentes: o fornecedor define unilateralmente a prioridade da notificação
- Prazo regulatório do cliente ausente dos critérios de P1 do fornecedor: o fornecedor não sabe o que torna o incidente um P1 para o cliente
Por que isso importa
O escalonamento de incidentes entre fornecedores é importante para TPRM porque as obrigações regulatórias do cliente são determinadas por lei, e não pela classificação de incidentes do fornecedor. O GDPR, o PCI-DSS, a comunicação de incidentes no setor de serviços financeiros e os requisitos setoriais de notificação de violações estabelecem prazos de notificação a partir de eventos desencadeadores definidos, e esses prazos correm a partir do momento em que a parte relevante toma conhecimento, e não de quando o cliente recebe a notificação do fornecedor. Fornecedores cujos procedimentos internos de escalonamento atrasam a notificação ao cliente consomem a janela regulatória do cliente.
A lacuna de calibração contratual do SLA é a correção de governança. Contratos que exigem a notificação pelo fornecedor “em até setenta e duas horas após uma violação de dados confirmada” deixam a classificação de “confirmada” a critério do fornecedor, o que pode ocorrer muito depois do momento em que o prazo regulatório do cliente começou a correr. Contratos que exigem a notificação em até vinte e quatro horas após o fornecedor detectar qualquer acesso não autorizado a sistemas que contêm dados de clientes alinham o gatilho de notificação ao evento que inicia o prazo regulatório, e não à conclusão da investigação do fornecedor.
Onde a maioria das equipes erra
A falha mais recorrente é não compreender que o prazo regulatório de notificação do cliente começa na detecção pelo fornecedor, e não na notificação do fornecedor. SLAs de notificação que parecem generosos em termos absolutos podem ser inadequados quando consomem a maior parte da janela regulatória do cliente.
- Não compreensão de que o prazo regulatório do cliente começa na detecção pelo fornecedor
- SLA de notificação calibrado ao processo do fornecedor, e não ao prazo regulatório do cliente
- Gatilho de classificação não especificado: o que constitui P1 do ponto de vista regulatório do cliente
- Sem participação do cliente nos critérios de P1: o fornecedor define o escalonamento sem gatilhos regulatórios específicos do cliente
- SLA de notificação não testado em relação ao requisito regulatório mais rigoroso do cliente
Como é uma boa prática
Modelos de escalonamento maduros definem critérios de P1 que incorporam os gatilhos regulatórios do cliente (qualquer acesso não autorizado a sistemas que contêm dados regulados de clientes é automaticamente P1, independentemente de exfiltração confirmada) e incluem em contrato a notificação preliminar em horas, e não em dias, após a detecção.
- Gatilhos de P1 específicos do cliente: qualquer acesso não autorizado a sistemas que contêm dados regulados
- Notificação preliminar em horas, e não em dias, após a detecção
- Prazo regulatório incorporado ao SLA: a notificação deve deixar ao cliente tempo suficiente para cumprir a própria obrigação
- Nenhuma exigência de conclusão da investigação para o gatilho da notificação inicial
- Contexto regulatório do cliente fornecido ao fornecedor: o fornecedor sabe quais gatilhos são P1 para o cliente
Ferramentas
Gestão de incidentes: PagerDuty, ServiceNow Security Incident Response
Plataformas de gestão de incidentes com fluxos de notificação de clientes podem ser configuradas para acionar caminhos de escalonamento específicos de cada cliente quando são classificados incidentes que envolvem sistemas com dados de clientes. Para profissionais de TPRM, perguntar se a plataforma de gestão de incidentes do fornecedor tem configurações de escalonamento específicas por cliente é uma pergunta específica sobre o desenho do escalonamento.
Desafios de governança
O desafio de governança no escalonamento entre fornecedores é a autonomia de classificação do fornecedor. Os fornecedores não aceitarão que o cliente dite o seu sistema interno de classificação de incidentes. A abordagem contratual, que especifica gatilhos e prazos de notificação independentes da classificação do fornecedor, atinge o objetivo do cliente sem exigir que o fornecedor mude seu modelo interno de classificação.
- Definir o gatilho de notificação como um evento, e não como uma classificação: qualquer acesso não autorizado a dados regulados
- Especificar o SLA de notificação preliminar: horas, e não dias
- Calibrar o SLA ao requisito regulatório mais rigoroso do cliente
- Fornecer ao fornecedor os indicadores de P1 específicos do cliente: o que deve ser escalonado imediatamente para este cliente
- Testar o prazo de notificação em relação ao prazo regulatório, com margem
Se você faz parte de uma equipe pequena
Revise o seu requisito regulatório de notificação mais rigoroso: as setenta e duas horas do GDPR, o prazo de notificação do PCI-DSS ou a comunicação de incidentes no setor de serviços financeiros. Depois, revise o SLA de notificação do fornecedor. Calcule a diferença: se o fornecedor notificar no fim do seu SLA, quanto tempo resta ao cliente para a sua própria notificação regulatória? Se a resposta for menos de vinte e quatro horas para qualquer fornecedor de Nível 1, o SLA de notificação precisa ser renegociado.
- Calcular o tempo que resta ao cliente após o término do SLA de notificação do fornecedor
- Renegociar quando o tempo restante for insuficiente para a conformidade regulatória
- Definir o gatilho de notificação como um evento, e não como uma classificação: qualquer acesso não autorizado
- Fornecer ao fornecedor os gatilhos de escalonamento específicos do cliente
O que exigir
Pergunte diretamente:
“No seu processo atual de gestão de incidentes, se o seu SOC detectar um acesso não autorizado ao servidor que guarda os nossos dados de pagamento às 8h de segunda-feira, qual é o prazo até a nossa notificação, e esse prazo nos deixa tempo suficiente para cumprir a nossa obrigação regulatória de notificação em setenta e duas horas?”
O que esperar como evidência
- Critérios de classificação de incidentes para sistemas relevantes para o cliente
- Prazo de notificação preliminar a partir da detecção
- Confirmação de que o SLA de notificação está calibrado ao prazo regulatório do cliente
- Critérios de P1 específicos do cliente
Um fornecedor com SLAs de gestão de incidentes definidos deve receber a pergunta do cenário específico: detecção às 8h de segunda-feira, notificação ao cliente até quando? A resposta revela se o SLA deixa tempo suficiente para a resposta regulatória.
Como comprovar
- Registros de calibração ao prazo regulatório
- Análise da adequação do SLA de notificação
- Documentação dos critérios de P1 específicos do cliente
- Documentação contratual dos gatilhos de escalonamento
Principal conclusão
O prazo regulatório começa quando o fornecedor detecta o incidente. A obrigação de notificação do cliente corre a partir da detecção pelo fornecedor, e não do recebimento da notificação do fornecedor pelo cliente. Um fornecedor que notifica na trigésima sexta hora deixa ao cliente trinta e seis horas para uma notificação que exige revisão jurídica, avaliação do escopo e comunicação regulatória. O SLA que parece adequado isoladamente consome, na prática, a janela regulatória. Defina o gatilho de notificação como o evento: qualquer acesso não autorizado a dados regulados. Especifique o SLA de notificação preliminar em horas. Calibre-o ao tempo de que o cliente precisa após receber a notificação para cumprir a própria obrigação. Teste-o com o cenário: detecção na segunda-feira de manhã, comunicação regulatória do cliente até quando?