Nas primeiras horas de um incidente de segurança, não consegue ter uma visão técnica completa do que aconteceu. A sua equipa pode ainda estar a tentar perceber qual foi a conta comprometida, que dados foram acedidos, até onde chegou o atacante ou se o incidente ainda está ativo.
A par da investigação, a pressão para agir começa de imediato. Os colaboradores ouvem fragmentos e precisam de saber o que fazer. Entretanto, os clientes podem notar uma interrupção do serviço, atividade suspeita ou pedidos invulgares de reposição de palavra-passe. Os parceiros comerciais podem perguntar se os seus sistemas ou dados estão envolvidos, e a liderança precisa de decidir quem fala, o que pode ser confirmado e quando o silêncio se torna um risco por si só.
A comunicação de incidentes de segurança é difícil porque uma empresa tem de ser transparente antes de ter todas as respostas, mas suficientemente informada para não fazer suposições. As comunicações enviadas demasiado cedo podem gerar confusão, mas se forem enviadas demasiado tarde podem prejudicar a confiança, atrasar ações de proteção e levantar questões regulatórias.
É pouco provável que as pequenas e médias empresas tenham criado ou ensaiado o seu plano de resposta a incidentes, e isto pode causar caos adicional. Mesmo nas empresas maiores com um plano, os passos técnicos podem estar documentados: conter o incidente, repor o acesso, preservar provas, restaurar sistemas. A comunicação pode ficar para depois, até que, de repente, o incidente escala ou muda.
Parte da preparação para um incidente passa por saber quem precisa de ouvir a sua empresa, o que precisa de saber, quem aprova a mensagem e como comunicar os factos com clareza enquanto a investigação ainda está em curso.
O planeamento da comunicação faz parte da resposta a incidentes
A estrutura de duas vias para a sua resposta
Comece pelo público, não pelo anúncio
Como notificar os clientes de um incidente
Quando notificar as entidades reguladoras
Prepare as mensagens antes de precisar delas
Como o Proton Pass for Business pode ajudar
O planeamento da comunicação faz parte da resposta a incidentes
A resposta a incidentes é frequentemente descrita como um processo técnico, mas um incidente real torna-se rapidamente transversal. As equipas de TI podem conter a ameaça, mas a liderança, o departamento jurídico, o apoio ao cliente, os recursos humanos, a comunicação e as operações precisam todos de saber o que está a acontecer e o que estão autorizados a dizer.
As orientações do NCSC sobre comunicações eficazes num incidente cibernético(nova janela) — boas práticas gerais que se aplicam muito para além do Reino Unido — deixam este ponto claro: as organizações tendem a dar prioridade à resposta técnica e a deixar a comunicação para segundo plano, mesmo que a comunicação determine a forma como os colaboradores, os clientes, as partes interessadas e os meios de comunicação social percecionam a organização durante uma crise.
Nem todos os incidentes exigem uma declaração pública. Mas a empresa deve saber antecipadamente quem decide o que comunicar, quem aprova as mensagens externas, quem fala com os clientes e quem trata do reporte regulatório.
Um bom plano de resposta a incidentes de dados tem de incluir uma camada de comunicação. Este deve incluir detalhes práticos:
- Listas de contactos
- Modelos de rascunho
- Fluxos de aprovação
- Revisão jurídica
- Pontos de conversa para o apoio ao cliente
- Responsabilidades de notificação às entidades reguladoras
- Registos do que foi enviado, quando e a quem.
A estrutura de duas vias para a sua resposta
A resposta a incidentes precisa de duas vias: a resposta técnica e a resposta de comunicação. Funcionam em paralelo e o responsável pelo incidente ou pela resposta liga as duas.
| Via esquerda: resposta técnica | Via direita: resposta de comunicação |
| Conter o incidente | Atualizar a equipa interna |
| Proteger as contas afetadas | Notificar os clientes ou parceiros afetados |
| Preservar provas | Avaliar a notificação às entidades reguladoras |
| Restaurar sistemas | Manter as mensagens consistentes à medida que os factos mudam |
Isto permite-lhe estruturar a sua resposta e garantir que a colaboração continua à medida que os membros da equipa assumem tarefas diferentes.
Comece pelo público, não pelo anúncio
A comunicação de incidentes de segurança falha quando uma única mensagem tenta servir todos. Os colaboradores, os clientes, os parceiros e as entidades reguladoras precisam de diferentes níveis de detalhe porque têm decisões diferentes a tomar.
A sua equipa interna precisa primeiro de clareza
Não precisam de todos os detalhes — sobretudo enquanto a investigação está em curso — mas precisam de clareza sobre o que está confirmado, o que fazer de imediato e quem lidera a resposta. Isto significa saber que sistemas ou contas devem evitar, que ação tomar imediatamente e que questões continuam em aberto.
Os colaboradores também precisam de saber o que não fazer. Por exemplo:
- Não discutir o incidente publicamente
- Não repor credenciais fora do processo aprovado
- Não contactar os clientes com explicações improvisadas
- Não encaminhar mensagens suspeitas sem orientação.
Os clientes e parceiros precisam de saber como são afetados
Querem saber se os seus dados, acessos, pagamentos, serviços ou operações são afetados. Uma boa notificação ao cliente deve explicar:
- O que se sabe
- Que tipo de dados podem estar envolvidos
- O que a empresa está a fazer
- O que os clientes devem fazer agora, se for caso disso
- Onde podem obter atualizações.
O tom deve ser simples e direto. O cliente também não precisa de detalhes forenses, só precisa de informação suficiente para se proteger.
As entidades reguladoras precisam de um registo factual
Uma notificação de incidente ao abrigo do RGPD à autoridade de controlo competente (a ICO(nova janela) no Reino Unido, a autoridade nacional de proteção de dados em cada Estado-Membro da UE) não é uma mensagem de marketing nem uma nota de tranquilização para os clientes. Em vez disso, tem de ser um registo factual do que aconteceu, de quem foi afetado e do que está a fazer a esse respeito. Abordamos exatamente o que incluir na secção sobre notificar as entidades reguladoras mais abaixo.
O que comunicar internamente
Os colaboradores fazem parte da resposta, mesmo quando não integram a equipa de incidentes. Uma equipa confusa pode criar mais ruído sem querer, partilhar informação incorreta ou atrasar a contenção. Por outro lado, uma equipa bem informada pode ajudar a proteger contas, encaminhar os clientes para o canal certo e evitar que cresçam especulações.
Um anúncio interno de incidente de segurança deve abranger:
- Um resumo claro do que já foi confirmado até ao momento, em linguagem simples
- Que sistemas, contas, equipas ou dados podem estar potencialmente afetados
- O que a empresa está a fazer agora
- O que os colaboradores devem fazer de imediato
- Quem está autorizado a comunicar para o exterior
- Onde serão publicadas as atualizações
- Como comunicar atividade suspeita relacionada
Há aspetos que não devem ser incluídos: os vetores de ataque, a análise da causa raiz e as vulnerabilidades específicas geralmente não são partilhados internamente enquanto o incidente está em curso, e muitas vezes nem depois, uma vez que esses detalhes podem ajudar outros atacantes, criar exposição legal ou revelar lacunas que ainda não foram fechadas.
A primeira mensagem interna não precisa de responder a todas as perguntas, precisa de criar ordem. Por exemplo, os colaboradores podem ter de repor as palavras-passe apenas através de um processo aprovado, evitar usar um determinado sistema, preservar e-mails suspeitos ou deixar de usar credenciais partilhadas até a equipa de resposta concluir a revisão.
Avaliar os controlos de acesso existentes à luz das boas práticas de gestão de palavras-passe também é essencial. Durante um incidente, a partilha de credenciais desatualizada ou informal pode dificultar a compreensão do que ficou exposto.
Os guias da Proton sobre proteção contra incidentes de dados e prevenção de incidentes de dados para empresas explicam como os controlos em camadas reduzem a exposição antes de ocorrer um incidente. Uma gestão segura de credenciais é uma dessas camadas, porque ajuda a empresa a saber que contas existem, quem lhes pode aceder e o que tem de ser alterado rapidamente.
Como notificar os clientes de um incidente
Uma notificação de incidente de dados aos clientes é mais difícil, porque tem peso reputacional e legal. As pessoas podem estar preocupadas com o roubo de identidade, a apropriação de contas, a fraude financeira ou a exposição de informação privada. Também podem estar frustradas por a empresa não ter evitado o incidente.
Uma boa mensagem ao cliente deve ser honesta sem ser alarmante. Deve evitar o jargão técnico, mas ser clara. Os clientes precisam de compreender que dados estiveram envolvidos, que risco isso cria e o que devem fazer a seguir.
Uma estrutura útil é a seguinte:
- O que aconteceu, com um nível de detalhe adequado aos clientes
- Quando a empresa tomou conhecimento
- Que informações ou serviços podem estar afetados
- Que medidas a empresa tomou
- O que os clientes devem fazer agora
- Como a empresa irá fornecer atualizações
- Com quem os clientes podem falar para colocar questões
Quando a investigação ainda está em curso, isso deve ser divulgado. A precisão e a transparência ajudam a restaurar a confiança. Ser aberto quanto ao impacto não exige divulgar detalhes técnicos que poderiam ajudar alguém a repetir o ataque.
Em incidentes graves, os clientes podem precisar de instruções práticas: alterar uma palavra-passe, ativar a MFA, estar atentos a e-mails de phishing, contactar o banco e ignorar mensagens que afirmem ser da empresa, a menos que cheguem através de um canal oficial. A notificação deve tornar esses passos fáceis de compreender.
Quando e como notificar as entidades reguladoras
Nem todos os incidentes de segurança têm de ser comunicados às autoridades de controlo. Um incidente suscetível de notificação ao abrigo do RGPD do Reino Unido e da UE depende de saber se um incidente de dados pessoais é suscetível de resultar num risco para os direitos e liberdades das pessoas.
As orientações da ICO sobre incidentes de dados pessoais(nova janela) refletem um requisito comum ao RGPD do Reino Unido e da UE: as organizações devem comunicar um incidente suscetível de notificação sem demora injustificada e o mais tardar 72 horas após tomarem conhecimento do mesmo. Uma comunicação tardia exige justificação para o atraso.
Esse prazo de 72 horas pode criar pressão, sobretudo quando a investigação ainda não está concluída. O RGPD reconhece que as organizações podem não ter todos os detalhes nas primeiras 72 horas, pelo que a informação pode ser fornecida por fases, desde que sejam dadas atualizações adicionais sem demora injustificada.
Uma notificação à autoridade de controlo competente (a ICO no Reino Unido, ou a autoridade nacional de proteção de dados na UE) deve normalmente incluir:
- A natureza do incidente de dados pessoais
- As categorias e o número aproximado de titulares de dados afetados
- As categorias e o número aproximado de registos de dados pessoais afetados
- O nome e os detalhes de contacto do DPO ou de outro ponto de contacto
- As prováveis consequências do incidente
- As medidas tomadas ou propostas para o resolver
A ICO também disponibiliza uma página central para comunicar um incidente(nova janela) e encaminhar as organizações para o processo de comunicação adequado.
Para os titulares de dados afetados, o limiar é diferente. Quando um incidente de dados pessoais é suscetível de resultar num risco elevado para os direitos e liberdades das pessoas, estas devem ser informadas sem demora injustificada. Trata-se de uma situação em que as equipas jurídica, de privacidade e de liderança devem ser envolvidas desde cedo, mesmo numa pequena empresa.
Prepare as mensagens antes de precisar delas
A pior altura para conceber um processo de comunicação é durante um incidente. Não é útil emitir declarações ou orientações que precisem de ser atualizadas e alteradas.
É por isso que é útil preparar a estrutura das suas mensagens antes de precisar delas. Não o texto final, porque cada incidente será diferente, mas a estrutura: quem tem de aprovar a mensagem, que detalhes devem ser incluídos, onde serão registadas as atualizações e quem é responsável por cada público.
Um kit de comunicação simples é o suficiente para tornar a primeira hora menos caótica. Pode incluir:
- Um modelo de anúncio interno de incidente
- Um modelo de notificação ao cliente
- Um modelo de atualização para parceiros ou fornecedores
- Pontos de conversa para o apoio ao cliente
- Uma lista de verificação para a notificação à autoridade de supervisão
- Uma lista de porta-vozes aprovados
- Contactos de escalonamento para as áreas jurídica, de TI, de privacidade, de liderança e de comunicação
- Um local para registar todas as atualizações e decisões
A preparação dá à equipa um ponto de partida seguro quando a rapidez e a precisão são igualmente importantes. Um modelo preparado deixa mais atenção livre para os factos do incidente: o que aconteceu, quem foi afetado, o que já foi feito e o que as pessoas precisam de fazer a seguir.
Como o Proton Pass for Business pode ajudar
A comunicação de um incidente de segurança depende dos factos. Quanto mais claramente uma empresa gere os acessos antes de um incidente, mais fácil se torna explicar o que aconteceu, o que pode ter sido afetado e o que foi alterado.
Um gestor de palavras-passe empresarial como o Proton Pass for Business ajuda as equipas a reduzir a exposição relacionada com credenciais. Os colaboradores podem gerar palavras-passe fortes, guardá-las em cofres de palavras-passe encriptados, usar o preenchimento automático, partilhar credenciais em segurança, gerir chaves de acesso e usar a autenticação de dois fatores integrada. Os administradores podem aplicar políticas de palavras-passe, consultar registos de atividade, gerir acessos com controlos baseados em funções e apoiar o aprovisionamento através de integrações SCIM e SSO.
Durante um incidente, estas funcionalidades podem ajudar as empresas a agir com mais confiança. Se a conta de um colaborador for comprometida, os administradores podem rever os acessos, identificar credenciais partilhadas que possam precisar de rotação, impor uma autenticação mais forte e reduzir a dependência de palavras-passe copiadas através de chats ou folhas de cálculo.
Esteja pronto para responder antes de ocorrer um incidente com um gestor de palavras-passe empresarial.
