O playbook de resposta a incidentes de ransomware de um fornecedor de software para o varejo tinha trinta e duas páginas: abrangia todas as fases do incidente, árvores de decisão para escalonamento, modelos de comunicação e procedimentos de recuperação. O playbook havia sido desenvolvido pela equipe de segurança com contribuições das áreas de operações, jurídica e de comunicação, e era revisado anualmente. Quando um ransomware foi detectado às 2h de um sábado, o analista de plantão acionou o playbook e começou a executar as etapas. As etapas de um a três eram autossuficientes: descreviam ações que o analista podia executar diretamente. A etapa quatro, isolar os sistemas afetados, fazia referência ao “procedimento de isolamento por segmentação de rede no Apêndice C”. O Apêndice C era um documento de operações separado, mantido pela equipe de engenharia de redes em sua wiki interna. O analista de plantão não tinha acesso à wiki da equipe de redes. O analista ligou para o engenheiro de redes de plantão. O engenheiro de redes de plantão precisava acessar a wiki remotamente. O cliente de VPN dele tinha um certificado que havia expirado três dias antes. Trinta e oito minutos depois que o playbook direcionou o analista para a etapa quatro, o isolamento da rede foi executado. O ransomware continuou criptografando por trinta e oito minutos enquanto o procedimento era localizado. O playbook era abrangente, revisado e preciso. Ele fazia referência a um procedimento que não estava disponível para as pessoas que o executavam nas circunstâncias criadas pelo incidente.
O que são, de fato, as lacunas nos playbooks de incidentes?
As lacunas nos playbooks de incidentes são as deficiências nos procedimentos de resposta a incidentes específicos de cada cenário que impedem uma execução eficaz em condições reais de incidente: lacunas de completude, acessibilidade, precisão e especificidade operacional que causam atrasos, erros ou falhas quando os responsáveis tentam executar o playbook durante um incidente ativo. As lacunas nos playbooks nem sempre são evidentes na revisão documental: um playbook bem redigido que faz referência a procedimentos externos, contém contatos desatualizados, descreve ações que exigem acessos indisponíveis durante incidentes ou pressupõe ferramentas que não estão implantadas no ambiente afetado pode parecer abrangente na revisão e falhar na execução.
O problema da dependência de referências externas é a lacuna mais crítica dos playbooks do ponto de vista operacional. Playbooks que fazem referência a procedimentos, documentos ou sistemas externos (“consulte o Apêndice C”, “siga o procedimento de segmentação de rede”, “consulte o inventário de ativos”) criam dependências de recursos que podem não estar acessíveis durante um incidente, especialmente fora do horário comercial. O playbook só é tão completo quanto a sua dependência externa mais inacessível. Uma etapa que não pode ser executada porque o procedimento referenciado está indisponível bloqueia toda a sequência do playbook nesse ponto.
O problema da desatualização das informações de contato é a lacuna secundária. Manuais de resposta que contêm informações de contato (contatos de escalonamento, linhas de emergência de fornecedores, endereços para notificação regulatória) exigem atualizações regulares à medida que o pessoal muda, as funções se alteram e os dados de contato são atualizados. A revisão anual pode atualizar o texto do manual, mas deixar passar dados de contato específicos incorporados em modelos ou anexos. Uma ligação de escalonamento que cai em um número desativado ou em um funcionário que já saiu atrasa o escalonamento justamente quando a rapidez mais importa.
O problema dos pressupostos sobre ferramentas e acessos cria uma terceira categoria de lacunas nos playbooks. Playbooks desenvolvidos por engenheiros de segurança com acesso total às ferramentas podem descrever ações que exigem acesso a ferramentas, credenciais ou permissões de sistema específicas que o responsável de plantão (que pode ser júnior, estar em outro local ou usar um dispositivo pessoal) não tem. Uma ação que exige acesso ao console de um sistema específico, autenticação em uma ferramenta específica ou uma credencial específica guardada em um cofre que exige sua própria cadeia de autenticação cria uma barreira de execução que o processo de desenvolvimento do playbook não previu.
- Referências a procedimentos externos: o Apêndice C em uma wiki inacessível de outra equipe
- Informações de contato desatualizadas: mudanças de pessoal que invalidam os contatos de escalonamento
- Pressupostos de ferramentas e acesso: ações do manual que exigem credenciais ou acessos indisponíveis para o responsável de plantão
- Falhas de VPN e de ferramentas de acesso: expiração de certificados ou infraestrutura de acesso indisponível durante incidentes
- Revisão anual que confirma a atualização sem testar a executabilidade em condições de incidente
Por que isso importa
As lacunas nos manuais de resposta a incidentes importam para TPRM porque a qualidade da resposta de um fornecedor durante uma violação que afeta dados de clientes depende da eficácia com que seus manuais são executados em condições reais de incidente, que podem ser às 2h de um sábado, com um analista de plantão em seu dispositivo pessoal, sem acesso à wiki da equipe de rede. Um manual bem revisado que não pode ser executado sem ferramentas, acessos ou documentos externos indisponíveis durante incidentes não é um manual funcional para esses incidentes.
Onde a maioria das equipes erra
A falha mais recorrente é equiparar a abrangência do playbook à sua operabilidade. Um playbook abrangente que faz referência a procedimentos externos indisponíveis é abrangente no papel e incompleto na execução. O teste de operabilidade, que percorre o playbook em condições de incidente simuladas, revela as lacunas que a revisão documental não consegue revelar.
- Abrangência do playbook equiparada à operabilidade
- Referências a procedimentos externos sem validação de acessibilidade
- Contatos não testados: nenhuma ligação feita para confirmar que os contatos estão atualizados
- Pressupostos de ferramentas e acesso não validados: acesso do responsável aos sistemas necessários não confirmado
- Sem testes de operabilidade: nenhuma simulação de execução do playbook em condições de incidente simuladas
Como é uma boa prática
Programas maduros de manuais de resposta realizam testes anuais de operabilidade, percorrendo os manuais críticos em condições simuladas de incidente, com os responsáveis que de fato os executariam e com o acesso que teriam durante um incidente real, e corrigem as lacunas que os testes revelam antes que os incidentes as exijam.
- Teste anual de operabilidade: percurso do manual pelos responsáveis de plantão com o acesso disponível em condições de incidente
- Referências externas incorporadas: procedimentos críticos incluídos no manual, não apenas referenciados
- Informações de contato testadas: ligações de escalonamento feitas para confirmar que os contatos estão atualizados e acessíveis
- Acesso às ferramentas validado: confirmado o acesso do responsável de plantão a todas as ferramentas necessárias
- Lacunas dos playbooks acompanhadas e corrigidas: as constatações dos testes de operabilidade entram na lista de pendências de correção
Ferramentas
Gestão de playbooks: Confluence, ferramentas dedicadas a playbooks de IR, PagerDuty Runbooks
Plataformas dedicadas de gestão de runbooks e playbooks oferecem procedimentos autossuficientes e executáveis, que não exigem acesso a documentos externos ou a sistemas de wiki. Para profissionais de TPRM, perguntar se os playbooks de incidentes críticos são autossuficientes, com todos os procedimentos referenciados incorporados em vez de apenas vinculados, ou se dependem de documentos externos é uma pergunta específica sobre operabilidade.
Desafios de governança
O desafio de governança na operabilidade dos playbooks é o ônus da manutenção. Playbooks autossuficientes, que incorporam todos os procedimentos referenciados, são mais difíceis de manter que playbooks modulares com referências externas: quando um procedimento muda, um playbook autossuficiente precisa ser atualizado em todos os pontos em que o procedimento está incorporado. A solução de governança é identificar as etapas do caminho crítico em cada playbook, aquelas em que os atrasos têm as maiores consequências, e garantir que sejam totalmente autossuficientes, enquanto as etapas menos críticas podem fazer referência a documentos externos.
- Testar a operabilidade do manual anualmente: responsáveis de plantão, com o acesso disponível em condições de incidente
- Incorporar os procedimentos do caminho crítico: as etapas cujo atraso tem as maiores consequências devem ser autossuficientes
- Testar todos os contatos de escalonamento: ligações feitas, sem presumir que estejam atualizados
- Validar o acesso dos responsáveis às ferramentas, especificamente fora do horário de expediente e a partir de dispositivos pessoais
- Acompanhar as lacunas de operabilidade como lista de pendências de correção, com responsáveis e prazos
Se você faz parte de uma equipe pequena
Escolha o seu playbook de cenário mais crítico (ransomware costuma ser a escolha certa) e percorra-o às 14h de uma sexta-feira, como uma verificação de operabilidade de trinta minutos. Para cada etapa que faz referência a um documento em outro sistema, confirme que o analista de plantão tem acesso a esse sistema e consegue obter o documento em menos de dois minutos. Para cada contato de escalonamento do playbook, confirme que o contato está atualizado ligando para ele. Para cada ferramenta que o playbook exige, confirme que o analista de plantão tem acesso e credenciais. Essa verificação de trinta minutos na sexta-feira revelará as lacunas antes do incidente das 2h de sábado que as exigirá.
- Percorrer o playbook de ransomware em uma verificação de operabilidade de trinta minutos na sexta-feira
- Confirmar o acesso a cada procedimento referenciado externamente
- Ligar para cada contato de escalonamento para confirmar que está atualizado
- Confirmar o acesso do analista de plantão às ferramentas
O que exigir
Pergunte diretamente:
“No seu playbook de ransomware, vocês realizaram nos últimos doze meses um teste de operabilidade em que os responsáveis de plantão percorreram o playbook com os acessos e as ferramentas que realmente teriam durante um incidente às 2h da manhã? Que lacunas foram identificadas e resolvidas?”
O que esperar como evidência
- Data e método do teste de operabilidade
- Lacunas identificadas nos testes de operabilidade
- Correção das lacunas identificadas
- Desenho de procedimentos autossuficientes versus com referências externas
Um fornecedor que confirma ter manuais abrangentes contra ransomware deve ser questionado sobre o teste de operabilidade. A abrangência é a métrica de qualidade do documento. A operabilidade é a métrica de qualidade da execução. O cenário das 2h de sábado é o teste que revela a diferença.
Como comprovar
- Registros dos testes de operabilidade
- Registros de identificação e correção de lacunas
- Registros de testes dos contatos
- Registros de validação do acesso às ferramentas
Principal conclusão
Passo quatro: isolar conforme o Anexo C. Anexo C: wiki da equipe de rede. Wiki: exige VPN. Certificado da VPN: expirado havia três dias. Trinta e oito minutos depois: isolamento executado. Quarenta minutos de criptografia durante um passo que o manual descrevia corretamente, mas que não podia ser executado. O manual era abrangente. O teste de operabilidade que teria revelado a dependência do certificado da VPN não foi realizado. O teste de operabilidade é a verificação anual de trinta minutos, numa sexta-feira, que pergunta: o analista de plantão consegue executar este passo às 2h de um sábado com o acesso que realmente tem? A revisão anual confirma que o manual está atualizado. O teste de operabilidade confirma que ele pode ser executado.