Em resumo: uma lista de contactos de emergência de TI indica, para cada função, uma pessoa com substituto, a disponibilidade também fora do horário de expediente, o motivo pelo qual é informada e os dados que é preciso ter à mão na chamada. Existe em papel e num dispositivo separado, é testada com regularidade e inclui também as autoridades com prazos de notificação. Assim, numa emergência, não se perde tempo a procurar.
O número que ninguém tem
Uma sexta-feira à noite, a loja mostra redirecionamentos estranhos, o administrador tem uma suspeita. E agora? Telefonar ao fornecedor de alojamento, mas que número vale fora do horário de expediente e que número de cliente é preciso? A agência, mas quem tem lá acesso ao servidor? A seguradora, mas onde está o número da apólice? E quem decide se a loja sai do ar?
Muitas empresas conhecem estes momentos, e a semana do PHP2Shell multiplicou-os. O plano de emergência existe, no melhor dos casos, mas a lista de contactos que ele contém é muitas vezes o elo mais fraco: desatualizada, incompleta ou guardada apenas em formato digital precisamente no sistema que, naquele momento, não está disponível. Como o plano é estruturado no seu conjunto, descreve-o Criar um plano de emergência de TI para servidores web. Aqui trata-se da própria lista.
Quem deve constar da lista de contactos de emergência?
A tabela seguinte ordena os contactos típicos segundo o motivo por que são informados e indica o que convém ter à mão no primeiro contacto.
| Contacto | Quando informar | O que ter à mão |
|---|---|---|
| Direção de emergência (muitas vezes a gerência) | perante qualquer suspeita de incidente | breve ponto da situação, primeira avaliação |
| Responsáveis de TI e administradores | de imediato, para verificação técnica | sistemas afetados segundo o inventário |
| Fornecedor de alojamento (canal de emergência) | perante suspeita no servidor, para desligar ou obter registos | número de cliente, número de contrato, palavra-passe do suporte |
| Agência ou programador | quando a aplicação é afetada | nome do projeto, acessos, interlocutores |
| Prestador de serviços de segurança informática | em caso de intrusão confirmada ou provável | observações até ao momento, horas |
| Encarregado da proteção de dados | logo que dados pessoais possam estar afetados | tipos de dados, período, sistemas |
| Ciberseguro | segundo as condições da apólice, em regra cedo | número da apólice, via de participação do sinistro |
| Aconselhamento jurídico | em caso de obrigações de notificação, extorsão, questões de responsabilidade | ponto da situação, passos já dados |
| Autoridade de controlo de proteção de dados | em violação de dados sujeita a notificação, se possível no prazo de 72 horas | dados nos termos do Art. 33, n.º 3, do RGPD |
| Ponto de contacto central para o cibercrime (ZAC) | ao apresentar queixa por uma infração penal | provas, cronologia |
| BSI (Gabinete Federal Alemão para a Segurança da Informação) | em caso de obrigação de notificação nos termos da NIS2 | segundo as indicações do BSI |
| Comunicação | antes de qualquer informação para o exterior | factos acordados |
O ponto de contacto central para o cibercrime (Zentrale Ansprechstelle Cybercrime, ZAC, da polícia alemã) competente encontra-se através da polícia do seu estado federado alemão; como decorre a queixa, vê-se em Apresentar queixa: pontos de contacto centrais para o cibercrime. Que prazos e deveres as seguradoras costumam impor, descreve-o Ciberseguro: o que conta em caso de sinistro.
O que cada entrada tem de conter
Um nome e um número de telefone não bastam. Uma entrada completa responde a seis perguntas:
- Função: de que é a pessoa responsável, o que pode decidir?
- Nome e substituto: quem entra em ação quando a primeira pessoa não está contactável?
- Disponibilidade: telefone, também móvel, e uma segunda via. O número vale também à noite e ao fim de semana?
- Gatilho: em que ocorrência esta pessoa é informada?
- Legitimação: número de cliente, número de contrato, palavra-passe do suporte, para que a chamada não falhe na verificação de identidade.
- Estado: quando foi a entrada verificada pela última vez?
O ponto 5, em especial, é muitas vezes subestimado. Os fornecedores de alojamento e os registadores verificam ao telefone se quem liga está autorizado, e com razão. Quem tem de procurar primeiro a palavra-passe de cliente perde tempo precioso. Guarde estes dados em segurança, mas de forma a que a direção de emergência lhes possa aceder numa emergência.
Retire os números de telefone dos prestadores de serviços do contrato ou do site oficial, nunca de um e-mail. Os burlões gostam de aproveitar situações de segurança conhecidas para enviar mensagens falsas com «números de emergência».
A sequência numa emergência
Nem todos os contactos são necessários ao mesmo tempo. Um procedimento escalonado revelou-se eficaz: primeiro, a direção de emergência e a área técnica, para que surja uma primeira avaliação e se possa decidir sobre a contenção. Depois, o fornecedor de alojamento, a agência e o prestador de serviços de segurança para o trabalho técnico. Logo que dados pessoais possam estar afetados, o encarregado da proteção de dados, pois a partir do momento em que se toma conhecimento de uma violação de dados corre o prazo do Art. 33 do RGPD. A seguradora e o aconselhamento jurídico seguem-se cedo, antes de serem tomadas decisões importantes. A comunicação para o exterior vem em último lugar e só com factos acordados.
Os passos que se seguem ao primeiro alerta resume-os a Lista de verificação após um ataque informático. Esta página dá indicações gerais; esclareça as obrigações de notificação e as questões jurídicas com o encarregado da proteção de dados e com um advogado.
Planeie também uma segunda via de comunicação. Se o servidor de correio for afetado ou houver suspeita de que um atacante lê caixas de correio internas, a coordenação deve decorrer por um canal separado, por exemplo por telefone ou num grupo criado antecipadamente noutro serviço. Defina este canal de antemão e inclua-o na lista. Procurar um novo caminho numa emergência custa tempo e gera incerteza sobre qual mensagem é autêntica.
Manter a lista viva
As listas de contactos desatualizam-se em silêncio. Os colaboradores mudam, os prestadores de serviços alteram os números de emergência, os contratos caducam. Planeie por isso duas datas de verificação fixas por ano e uma data pontual em cada mudança. Uma breve chamada de teste fora do horário de expediente mostra da forma mais fiável se um canal de emergência funciona mesmo. Pergunte então também se a pessoa sabe que consta da lista e o que se espera dela numa emergência.
Como ajuda concretamente a PHP SOS?
- Elaboramos consigo a lista dos contactos técnicos de emergência e verificamos se os fornecedores de alojamento e as agências têm de facto um canal de emergência.
- Definimos que dados têm de estar à mão para cada contacto, para que uma chamada tenha efeito imediato.
- Acompanhamos um teste de alerta e incorporamos as lacunas na sua documentação.
- Numa emergência, constamos da sua lista como interlocutor técnico através da resposta a incidentes.
Conclusão: uma boa lista de contactos é curta, completa e testada. Decide se as primeiras horas de um incidente se passam a agir ou a procurar.
Perguntas frequentes
Quem deve constar de uma lista de contactos de emergência de TI?
Internamente, a gerência, a TI, o encarregado da proteção de dados e a comunicação; externamente, o fornecedor de alojamento, a agência, o prestador de serviços de segurança informática, o ciberseguro, o aconselhamento jurídico, a autoridade de controlo de proteção de dados competente e o ponto de contacto central para o cibercrime (ZAC) do seu estado federado alemão e, se a NIS2 for obrigatória, também o BSI.
Onde guardo os contactos de emergência?
Em pelo menos dois locais, dos quais um acessível sem a própria TI, por exemplo impresso no dossiê de emergência e num dispositivo separado. Uma lista que só está na caixa de correio ou no servidor afetado não está disponível numa emergência.
Com que frequência se deve verificar a lista?
Pelo menos duas vezes por ano e após qualquer mudança de pessoal ou de prestador de serviços. Uma breve chamada de teste mostra se os números estão certos e se as pessoas sabem que constam da lista.
A autoridade de controlo de proteção de dados tem sempre de ser informada?
Não em todos os incidentes. O Art. 33 do RGPD exige uma notificação em caso de violação da proteção de dados pessoais, se possível no prazo de 72 horas, exceto se for provável que não resulte num risco para os titulares dos dados. A avaliação faz-se com o encarregado da proteção de dados; esta página não constitui aconselhamento jurídico.