Como registrar quase-incidentes de segurança na pequena empresa
O golpe que quase deu certo mostra onde sua empresa vai falhar da próxima vez. Registrar quase-incidentes, como o e-mail falso que alguém quase abriu ou o boleto adulterado barrado no último minuto, custa pouco e revela padrões antes do prejuízo. Basta um canal simples, um registro curto e a regra de que ninguém é punido por avisar.
O que é um quase-incidente de segurança?
É o problema que chegou perto de acontecer e parou a tempo. Um funcionário recebe um e-mail que imita o banco e percebe o golpe antes de digitar a senha. O financeiro recebe um boleto com dados bancários trocados e liga para o fornecedor antes de pagar. Alguém clica num link falso, mas o navegador bloqueia a página.
Nesses casos não houve prejuízo, e por isso quase ninguém comenta. O problema é que a falha que permitiu a quase-perda continua lá. Na próxima vez, a pessoa pode estar com pressa, e o golpe passa.
Por que a aviação registra quase-acidentes?
Porque o acidente grave costuma ser precedido por erros menores que ninguém relatou. Nos Estados Unidos, a NASA mantém o ASRS (Aviation Safety Reporting System), um sistema que recebe relatos voluntários de incidentes e situações de risco enviados por pilotos, controladores de voo e outros profissionais. O programa usa esses relatos para encontrar falhas no sistema e avisar quem pode corrigi-las.
O que faz as pessoas relatarem é a confiança. Segundo a página de confidencialidade do ASRS, os relatos são mantidos em sigilo e os nomes de pessoas e organizações são removidos antes de entrar na base. A FAA, autoridade de aviação civil americana, se comprometeu a não usar essas informações contra quem relata em processos de fiscalização.
Sua empresa não precisa de uma base nacional. Ela precisa da mesma lógica em escala pequena: as pessoas contam o que quase deu errado porque sabem que não serão punidas.
Por que o funcionário esconde o clique que quase deu errado?
Por medo e por vergonha. O NCSC, centro nacional de cibersegurança do Reino Unido, diz na orientação sobre phishing para organizações que a empresa deve evitar uma cultura de punição ou culpa em torno do phishing, porque funcionários com medo de perder o emprego não relatam erros. A mesma orientação pede um processo de relato claro, simples e rápido, e um retorno ágil para quem avisou sobre o que foi feito.
Na prática, o gestor que dá bronca no primeiro relato recebe silêncio nos seguintes. O gestor que agradece recebe avisos cedo, quando ainda dá para bloquear o remetente, alertar a equipe e trocar uma senha.
O que registrar e onde guardar?
Uma planilha compartilhada ou um formulário simples resolvem. O importante é que o registro seja curto o bastante para ser preenchido em dois minutos. Cada linha pode ter:
- Data e quem percebeu, ou "anônimo", se a pessoa preferir.
- O que aconteceu, em uma ou duas frases. Exemplo: "e-mail cobrando nota fiscal com anexo compactado, remetente parecido com o do fornecedor".
- Como foi percebido: desconfiança da pessoa, aviso do antivírus, bloqueio do navegador, ligação de confirmação.
- O que chegou a acontecer: nada, clique sem digitar senha, senha digitada e trocada em seguida.
- O que foi feito depois e quem ficou responsável.
Para facilitar, crie um endereço de e-mail ou um grupo de mensagens só para avisos de segurança. Combine que qualquer pessoa pode encaminhar ali um e-mail suspeito sem precisar explicar nada.
Como usar o registro para corrigir falhas?
O registro só vale se alguém ler. Reserve um momento por mês para revisar as entradas com quem cuida da tecnologia e com um gestor. Algumas perguntas ajudam:
- O mesmo tipo de golpe apareceu mais de uma vez? Então vale avisar a equipe inteira com o exemplo real.
- Alguma falha técnica ajudou o golpe? Senha fraca, conta sem MFA (autenticação em dois fatores), filtro de e-mail mal configurado.
- Algum processo facilitou o erro? Pagamento aprovado só por e-mail, troca de dados bancários sem ligação de confirmação.
- Quem relatou recebeu retorno? Se não recebeu, o próximo relato pode não vir.
Erros comuns de segurança na pequena empresa, como atualização atrasada, senha padrão em equipamento e falta de lista do que está ligado na rede, costumam aparecer primeiro como quase-incidentes. O registro mostra essas falhas antes que um atacante as use.
Quando o quase-incidente vira incidente de verdade?
Quando o golpe passa: alguém digitou a senha e ela foi usada, um pagamento saiu para a conta errada, dados de clientes foram acessados. Aí o registro serve de ponto de partida para a resposta. Se houver dado pessoal envolvido, o artigo 48 da LGPD determina que o controlador comunique à ANPD e ao titular o incidente de segurança que possa acarretar risco ou dano relevante aos titulares. Decidir se o caso se enquadra exige análise jurídica.
Se sua empresa pensa em se preparar para a ISO/IEC 27001, a norma de gestão de segurança da informação, um registro organizado de eventos, com data, descrição e ação tomada, tende a ser útil como evidência. Os requisitos exatos sobre relato de eventos devem ser conferidos no texto oficial da norma.
Por onde começar na sua empresa?
Comece pelo canal de aviso e pela regra de não punir quem relata. Na Conscientização com simulação de phishing, os analistas da CyberArmor fazem a primeira campanha em até 30 dias, mostram à equipe como reconhecer e relatar e-mails suspeitos e ajudam a montar o registro de quase-incidentes. Para empresas que querem alguém cuidando do assunto todo mês, o Gestor de segurança sob demanda (vCISO) conduz a revisão periódica do registro. Também há material sobre golpes de vaga falsa e sobre phishing por código de dispositivo no Microsoft 365 para usar nos treinamentos. Para começar, fale com um especialista.
Fontes