Tema: incident-response
-
Um segredo foi commitado: por que apagar o arquivo não basta e qual é a ordem de resposta
Uma credencial enviada a um repositório Git permanece no histórico, em forks, clones, caches e logs de CI. Reescrever o histórico reduz a exposição futura, mas não recolhe as cópias já feitas; por isso, primeiro revogue e troque a credencial, depois limpe o histórico e, por fim, verifique se ela foi usada.
-
Cisco Secure Email Gateway e SD-WAN Manager: verificar correções e preservar evidências de comprometimento
Mantenha registros de remediação separados para o scanner de e-mail e o SD-WAN Manager. Verifique as correções efetivamente instaladas, preserve evidências antes de uma recuperação que altere o estado do sistema e siga o procedimento de investigação específico de cada produto.
-
Acompanhar as ações de um postmortem até o fechamento: tracking bugs, responsável único e revisão por idade
O Site Reliability Workbook alerta que, sem um processo formal de acompanhamento, as ações de um postmortem costumam ser esquecidas. Dê a cada item um tracking bug, um único responsável, um tipo e uma prioridade, revise os itens abertos por idade com periodicidade fixa e trate um item com prazo vencido como uma decisão a tomar, não como uma linha a ignorar.
-
Após a chegada de um relatório de vulnerabilidade: confirmar, avaliar, corrigir em privado e divulgar
Quando um relatório chega ao contato de segurança do projeto, o trabalho segue uma sequência com datas: confirmar o recebimento rapidamente, classificar (comportamento esperado, bug, pedido de funcionalidade ou vulnerabilidade), combinar um embargo com quem reportou, desenvolver a correção em privado, obter um identificador CVE e então lançar a versão e publicar um aviso que indique as versões afetadas e corrigidas e dê crédito a quem reportou. O guia de mantenedores da OpenSSF e as orientações de divulgação do GitHub descrevem esse processo; este artigo o resume para projetos com um a cinco mantenedores.
-
Após corrigir um dispositivo de borda que teve uma vulnerabilidade explorada: evidências, recuperação e verificações para retorno à operação
Proposta de procedimento operacional para investigar um dispositivo de borda que esteve exposto a uma vulnerabilidade explorada. Preserve evidências, documente se é necessário reconstruir o ambiente conforme orientação do fornecedor, substitua o material de confiança exposto e verifique a recuperação separadamente da instalação da correção.
-
Quando um provedor invadido armazenava suas chaves de API: contenção, substituição e conferência de cobranças
Revogue as chaves expostas no emissor, restabeleça o acesso dos consumidores legítimos por sistemas confiáveis e investigue o uso e as cobranças. Trate os alertas de orçamento e a entrega das chaves substitutas como controles separados que precisam ser verificados.
-
Resposta a incidentes de segurança para uma equipe pequena: um procedimento mínimo
Uma equipe de duas pessoas não consegue manter um centro de operações de segurança, mas pode preparar de antemão uma lista de contatos, um checklist de contenção e uma regra para preservar evidências. A NIST SP 800-61 Rev. 3 situa a resposta a incidentes dentro da gestão contínua de riscos, e este procedimento é o mínimo que torna previsível a primeira hora.
-
Ivanti Connect Secure: corrigir CVE-2026-104935 e investigar comprometimentos anteriores
Separe a correção da falha que permite contornar a autenticação da recuperação de um comprometimento: escolha uma versão corrigida compatível, preserve evidências forenses e combine verificações de integridade com análises de rede e memória.
-
Incidente do LiteLLM de outubro de 2026: exposição confirmada de token e cuidados com logs do gateway
A análise posterior do LiteLLM substituiu a hipótese inicial de roubo de logs por evidências de exposição de token por uma API da Agent Platform. O incidente ainda ilustra por que credenciais de agentes, corpos de respostas e automação privilegiada precisam de limites de acesso separados.
-
Postmortems sem atribuição de culpa: registrar a sequência dos fatos, as causas e as ações corretivas
Um postmortem descreve o que aconteceu durante um incidente, quem foi afetado e por quanto tempo, que circunstâncias o tornaram possível e que ações tornam uma repetição menos provável. A ausência de culpa não é questão de cortesia, e sim a condição para que os envolvidos relatem fatos em vez de se defender.
-
Correlação versus causalidade em dados de incidentes e de operações
Um coeficiente de correlação mede como duas séries variam em conjunto; não diz qual delas influencia a outra, se um terceiro fator, como o tráfego, afeta ambas, nem se os dados foram selecionados pelo resultado. Primeiro visualize os dados, controle as causas comuns evidentes, verifique a ordem temporal e confirme com uma intervenção, como uma flag ou um canary, antes de agir.
-
Como ler um aviso de violação de um provedor: verifique o remetente, o escopo e os indicadores
Transforme a notificação de violação de um provedor em um registro de ações verificado: confirme a autenticidade, identifique os ativos afetados e os fatos ainda não esclarecidos e avalie os indicadores nos logs preservados antes de tirar conclusões.
-
Um primeiro game day: um experimento de caos com hipótese, raio de impacto e regra de interrupção
Execute um primeiro exercício de injeção de falhas como experimento agendado e anunciado: defina o estado estável como uma saída mensurável, formule a hipótese de que ele se mantém diante de uma falha específica, limite o raio de impacto, fixe uma condição de interrupção, injete a falha e registre o que o sistema e as pessoas fizeram; os Principles of Chaos Engineering dão os quatro passos e o livro Google SRE descreve o role-play de desastres como ritual semanal.
-
PAN-OS CVE-2026-0322: verificar correções por linha de manutenção e recuperar o plano de gerenciamento
Uma falha na interface de gerenciamento, explorável por usuários autenticados, afeta firewalls PAN-OS e o Panorama. Identifique a versão de manutenção completa, restrinja o acesso de gerenciamento e siga o procedimento de recuperação do fornecedor para hardware ou appliances virtuais quando houver suspeita de comprometimento.
-
Runbooks para operação: guias que uma pessoa de fora consegue executar de madrugada
Um runbook por serviço responde, nesta ordem: o que o serviço faz, como saber em um minuto se está saudável, quais falhas conhecidas existem (com sintoma, comando de diagnóstico e contramedida), quais ações são seguras ou perigosas e quem escalar e quando; a revisão é feita por alguém que não o escreveu.
-
Equipes com poucos dashboards vinculados a alertas diagnosticam incidentes mais rápido do que equipes com muitos dashboards sem responsável
Hipótese: em serviços de porte comparável, o tempo entre o acionamento do alerta e a identificação de uma causa provável é menor quando a equipe mantém poucos dashboards com responsável, para os quais os alertas apontam diretamente, do que quando mantém muitos dashboards copiados ou gerados automaticamente, que os respondentes precisam percorrer. Propõe-se uma comparação com base em linhas do tempo de incidentes e inventários de dashboards.
-
Como manter uma página de status pública com honestidade: componentes, automação e histórico
Uma página de status só conquista confiança quando fica vermelha no momento em que os usuários veem vermelho: hospede-a fora da infraestrutura que ela monitora, liste componentes que os usuários reconhecem, deixe todos os de plantão publicar sem aprovação, atualize em intervalos fixos durante incidentes e mantenha o histórico visível.
-
Após uma violação do provedor de login: redefinições direcionadas, recuperação de sessões e verificação de senhas vazadas
Recupere as contas de usuários afetadas sem tratar todo vazamento em terceiros como prova de comprometimento local. Combine redefinições e invalidação de sessões baseadas em evidências com monitoramento de credential stuffing e verificação de senhas que preserve a privacidade.
-
Reinicializar NTP, DNS e DHCP após uma queda total da rede: reinício ordenado por dependências
Metodologia proposta: após uma queda que derrubou NTP, DNS e DHCP ao mesmo tempo, restabelecer primeiro o horário, depois o DNS e por fim o DHCP, porque verificações de certificados e de Kerberos exigem hora correta, a maioria dos serviços se localiza por nome e o DHCP pode depender dos dois. Ressalva: um servidor NTP que usa hostnames como upstream também precisa de DNS.
-
NetScaler ADC e Gateway: distinguir as correções de setembro e outubro antes da recuperação
CVE-2026-88771 e CVE-2026-88772 têm builds mínimos corrigidos diferentes dos da falha de negação de serviço SAML CVE-2026-88779. Confira cada boletim, investigue comprometimentos e decida de forma deliberada sobre o encerramento de sessões.
Legível por máquina: JSON