Há uma grande diferença entre o que você vê durante um incidente de TI e a experiência de seus clientes. Para você, pode começar com um alerta da ferramenta de monitoramento e terminar com um e-mail sobre a correção. Mas para seus clientes, pode começar com pânico e terminar em perda de confiança. É por isso que você precisa de um plano sólido de comunicação de incidentes para garantir que os incidentes sejam tratados sem problemas.
No entanto, você não deve cair na armadilha de pensar que a comunicação de incidentes é apenas enviar um e-mail bem escrito aos usuários afetados. Trata-se de garantir que seu mecanismo de resposta a incidentes funcione sem problemas e ajude tanto os funcionários que lidam com isso quanto os usuários do lado receptor.
Ao longo de algumas décadas, nós da ManageEngine internalizamos esse aprendizado e criamos uma estrutura para comunicação eficaz durante um incidente.
Escolhendo a categoria certa
Cobrimos detalhadamente nosso processo de gerenciamento de incidentes em nosso manual de gerenciamento de incidentes e acreditamos que a comunicação começa desde a própria fase de análise. Anunciamos publicamente como entrar em contato conosco para relatar incidentes e também anunciamos isso dentro da organização. Garantimos que todos os funcionários estejam cientes disso durante o treinamento. Quando estamos cientes de um incidente, primeiro o categorizamos com base em seu tipo e impacto.
Uma abordagem que funciona bem para nós é categorizar os incidentes e respondê-los com base na estrutura de segurança cibernética do NIST. Depois de categorizar o incidente, usamos um modelo de comunicação adequado para essa categoria.
Criando modelos para uma melhor comunicação
Um motivo comum pelo qual as empresas lidam mal com a comunicação de incidentes é a falta de clareza. Um desenvolvedor pode não saber a quem chamar para um determinado tipo de incidente. Um operador de data center ou um administrador de rede pode ficar confuso sobre usar um bate-papo em grupo ou enviar um e-mail ao lidar com um problema específico. Um coordenador pode perder alguns detalhes no e-mail que precisa enviar aos usuários finais. Ter modelos para cada categoria elimina essas incertezas.
Também é importante fornecer uma distinção clara entre comunicação interna (entre equipes) e externa (para usuários fora da organização).
Veja o que um de nossos modelos normalmente cobre:
|
|
Incidentes de disponibilidade |
Incidentes de segurança |
Incidentes de privacidade |
|
O quê? |
Externo: Tempo de inatividade esperado, trabalhos em andamento e medidas alternativas para usuários e a causa raiz do tempo de inatividade. |
Externo: detalhes sobre o bug ou ataque, a causa raiz do incidente, a gravidade e a extensão do impacto que os usuários finais podem esperar, medidas imediatas tomadas por nossas equipes, qualquer ação necessária a ser tomada pelos usuários e outras informações relevantes para o usuário final. |
Externo: A natureza dos dados envolvidos, quaisquer leis de privacidade violadas, detalhes que exigimos dos usuários para determinar a gravidade e o impacto dos incidentes, o motivo do incidente e um pedido de desculpas se causado por nós. |
|
Interno: Detalhes dos serviços afetados (da ferramenta de monitoramento), a causa raiz do incidente e as medidas preventivas a serem tomadas |
Interno: Equipes responsáveis pelo incidente, detalhes do incidente, possível impacto, ação imediata a ser tomada pelas equipes, causa raiz do incidente e medidas preventivas a serem tomadas |
Interno: Equipes responsáveis pelos dados envolvidos, medidas a serem tomadas pelas equipes internas para auxiliar a equipe de privacidade, a causa raiz do incidente e medidas preventivas a serem tomadas |
|
|
Como? |
Externo: notificações por e-mail e no aplicativo |
Externo: E-mail e fóruns relacionados |
Externo: Email |
|
Interno: grupos Zoho Connect e canais Cliq |
Interno: grupos Zoho Connect e canais Cliq |
Interno: canais Cliq |
|
|
Quem? |
Externo: Administradores da organização |
Externo: Administradores da organização e agentes de segurança, se necessário |
Externo: Administradores da organização e responsáveis pela proteção de dados, se necessário |
|
Interno: Gerentes de equipe, membros apropriados da equipe, a equipe de segurança e o chefe de TI |
Interno: A equipe de segurança, o gerente da equipe e os membros das equipes apropriadas. |
Interno: A equipe de privacidade, a equipe de segurança, os membros apropriados da equipe e o responsável pela proteção de dados |
|
|
Quando? |
Externo: Atualizações imediatamente após o reconhecimento do incidente, quando o incidente for resolvido e se o tempo necessário para resolver aumentar inesperadamente |
Externo: Atualizações imediatamente após o reconhecimento do incidente, quando o incidente é resolvido e após o incidente ser resolvido. |
Externo: Atualizações imediatamente após o reconhecimento do incidente, quando a natureza e a gravidade do incidente são determinadas e se ações adicionais precisam ser tomadas para minimizar o impacto. |
|
Interno: Comunicação imediatamente após o reconhecimento do incidente, durante a correção do incidente, imediatamente após a resolução do tempo de inatividade e após a resolução do incidente |
Interno: Comunicação imediatamente após o reconhecimento do incidente, durante a implementação de soluções, após a resolução do incidente |
Interno: Comunicação imediatamente após o reconhecimento do incidente e após a resolução do incidente |
Digamos que nossa ferramenta de monitoramento, Site 24×7, nos alertou sobre o tempo de inatividade em um de nossos produtos ManageEngine, o AssetExplorer. Esses alertas são publicados automaticamente em nossa ferramenta de gerenciamento de incidentes. Uma postagem é então criada no Zoho Connect, nossa plataforma de colaboração em equipe. O processo de gerenciamento de incidentes seria o seguinte:
Internamente, marcamos os gerentes (Quem?) da equipe em questão no post (Como?), e damos detalhes sobre o tempo de inatividade. Descobrimos que podemos manter o tempo de inatividade abaixo de 30 minutos, então categorizamos o incidente de acordo com o impacto médio.
Os coordenadores de incidentes (Quem?) da equipe verificam as possíveis causas nos logs do aplicativo e na ferramenta de monitoramento. A equipe trabalha na aplicação de uma correção imediata. Simultaneamente (Quando?), enviamos um e-mail (Como?) aos usuários preocupados sobre o tempo de inatividade e o motivo (O quê?).
Enquanto trabalha na correção, a equipe envolve coordenadores de incidentes e outros especialistas necessários (Quem?) criando um grupo Cliq separado para o incidente (Como?). A equipe aplica uma correção e resolve o problema. Os detalhes da correção (O quê?) são comunicados à equipe do incidente.
Imediatamente (Quando?) informamos os usuários sobre a correção por e-mail (Como?).
Uma vez resolvido o problema, trabalhamos na criação de um documento de análise de causa raiz (RCA). O modelo RCA (O quê?) é preenchido para o incidente e enviado por e-mail (Como?) aos usuários para maior clareza.
Implementamos medidas preventivas e atualizamos os detalhes (O quê?) na ferramenta de gestão de incidentes (Como?). Enviamos e-mail (Como?) aos usuários sobre as medidas preventivas adotadas.
Para um incidente de tempo de inatividade mais longo, talvez precisemos nos comunicar com mais frequência com os usuários. Para um incidente de segurança como uma vulnerabilidade sendo explorada, podemos precisar de mais comunicação interna por meio de grupos de bate-papo e reuniões. Dependendo da sua organização, você pode criar mais categorias e modelos para atender às suas necessidades.
Implementando uma estrutura baseada em modelo
Embora os modelos funcionem, eles são tão bons quanto a forma como são executados. Para executá-los bem, você precisa de uma certa disciplina e estrutura organizacional que possa auxiliar seus funcionários. Veja o que fazemos para garantir que executamos bem os modelos:
1. Estabeleça os modelos em um repositório central:
Temos um portal de governança, risco e controle (GRC) que toda a organização pode acessar. Além disso, usamos o Zoho Connect para informar a todos sobre as atualizações no portal GRC. Você deve escolher um portal que funcione bem como um repositório central de modelos de comunicação para sua organização.
2. Nomeie um coordenador de incidentes para cada equipe:
Um coordenador de incidentes é necessário para mais do que apenas comunicação, mas eles tornam a comunicação muito mais fácil porque podem assumir a responsabilidade por toda a comunicação dentro dessa equipe.
3. Crie conscientização:
Incluímos esses modelos no treinamento de segurança e privacidade de nossos funcionários para conscientizá-los.
4. Teste e melhore:
Em última análise, testar e melhorar é a única maneira de saber se nossos modelos estão se tornando as melhores versões deles mesmos. Após cada incidente, nossa equipe de incidentes reflete sobre como os modelos funcionaram e como podemos melhorá-los antes do próximo incidente.
Abordamos a parte de comunicação do gerenciamento de incidentes neste artigo. Uma boa comunicação dará mais frutos quando você tiver uma estrutura sólida de gerenciamento de incidentes para guiá-lo durante todo o processo. Se você estiver procurando por uma estrutura assim, confira nosso manual de gerenciamento de incidentes.
