Respondendo a um incidente de segurança

As diretrizes neste artigo são destinadas a proprietários corporativos, proprietários de organizações, gerentes de segurança e equipes de segurança. No entanto, você precisará ter a função de proprietário da empresa para executar várias das ações descritas neste artigo. Algumas etapas podem exigir coordenação com proprietários da organização ou administradores de repositório.

Introduction

Este guia explica como responder a um incidente de segurança, delineando as GitHub superfícies que você pode usar para validar e investigar uma ameaça e as ferramentas que você pode usar para contê-la e corrigi-la.

Pré-requisitos

Idealmente, você tem o streaming de log de auditoria e a visibilidade do endereço IP de origem já habilitados para a empresa (transmitindo os dados para um sistema siem (gerenciamento de eventos e informações de segurança) e você tem acesso a esses dados. Consulte Como transmitir o log de auditoria para sua empresa.

Ao longo de sua resposta

À medida que você progride com sua resposta, verifique se você:

• Preservar evidências: tire capturas de tela de atividades suspeitas, exporte logs ou resultados da consulta e salve cópias de arquivos ou código afetados antes da limpeza.
• Mantenha um registro: documente suas descobertas (por exemplo, horas, datas, Indicadores de Comprometimento (IoCs), repositórios afetados) e registre cada decisão tomada.
• Comunique-se: notifique os stakeholders relevantes (como clientes potenciais de segurança e gerentes de engenharia, bem como equipes legais e de privacidade se os dados confidenciais estiverem em risco) e mantenha-os atualizados.

Etapa 1: Avaliar o sinal e validar rapidamente

O objetivo é determinar rapidamente se o sinal que você está vendo provavelmente será uma ameaça real e ativa.

1. Identificar

Tente identificar a natureza do sinal que você está vendo. Por exemplo, o sinal dá indicações de:

• Comprometimento de credenciais (alerta para um segredo vazado, relatórios de credenciais encontradas em um site externo)
• Acesso não autorizado ou comprometimento da conta (relatórios de logons suspeitos, confirmações ou alterações desconhecidas)
• Exfiltração de dados (relatórios de alterações ou adições suspeitas de arquivos, execuções inesperadas de fluxo de trabalho, atividade de API incomum, criações de repositório desconhecidas ou alterações inesperadas de visibilidade do repositório)
• Injeção de código mal-intencionado (relatórios de alterações suspeitas de código, execuções inesperadas de fluxo de trabalho, novos arquivos adicionados)
• Ataque à cadeia de suprimentos (relatórios de versões suspeitas do pacote, alertas para dependências vulneráveis)

Para obter ajuda para identificar esses sinais de ameaça em sua organização ou empresa, consulte Áreas comuns de investigação de incidentes de segurança.

Sugerimos que você não gaste muito tempo em inspeção profunda nos estágios anteriores da investigação, pois o objetivo inicial é identificar o sinal de ameaça para validá-lo e estratificar sua resposta.

2. Validar

Verifique se há evidências para validar se a ameaça potencial é real e se ela está ou não ativa no momento.

As ferramentas e superfícies a seguir GitHub podem ajudar.

Ferramenta/superfície	Purpose
Visão geral de segurança e alertas de segurança	Examinar alertas de segurança em toda a sua organização ou empresa
Logs de auditoria	Pesquisar eventos relacionados ao sinal que você está investigando, como criação de token, alterações de permissão ou alterações de visibilidade do repositório
Exibição de atividade	Exibir uma linha do tempo de pushes, confirmações e atividade de branch para um repositório específico
[

          GitHub pesquisa de código](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | Pesquisar indicadores conhecidos de comprometimento, como nomes de arquivo ou padrões de código específicos, entre repositórios |

| Gráfico de dependência | Verificar se os repositórios dependem de um pacote específico ou de uma versão específica do pacote. | | Execuções e logs de fluxo de trabalho | Examinar o histórico de execução do fluxo de trabalho e inspecionar a saída de log para atividades suspeitas |

Para obter detalhes sobre cada ferramenta, consulte Ferramentas de investigação para incidentes de segurança.

A fase de validação pode ser rápida:

• Procure reunir evidências suficientes para determinar se o sinal provavelmente será uma ameaça real e ativa .
• Se você não puder descartar rapidamente o sinal como um falso positivo, suponha que seja real.
• Uma investigação profunda pode ser realizada posteriormente.

3. Decidir

Com base nas evidências coletadas, determine três coisas:

1.        **Isso é uma ameaça real?** Se você não puder descartar rapidamente e com confiança o sinal como um falso positivo, trate-o como real e prossiga para a contenção.
   

2.        **A ameaça ainda está ativa?** Se o invasor parece ainda ter acesso ou a atividade está em andamento, priorize as ações de contenção imediatas primeiro. Se o compromisso parecer histórico, você ainda precisará investigar e corrigir, mas talvez tenha mais tempo para planejar sua resposta.
   

3.        **Qual é o escopo potencial?** Considere até onde o compromisso pode chegar: uma única credencial, um repositório, uma organização ou toda a empresa. Isso ajudará você a dimensionar sua resposta adequadamente.
   

Em caso de dúvida, trate a ameaça como real e redimensione sua resposta como as evidências permitem.

Etapa 2: Conter a ameaça

A próxima etapa pressupõe que você esteja lidando com uma ameaça real e ativa. A meta agora é reduzir imediatamente o risco contínuo usando o que você sabe até agora.

Há várias ações de contenção que você pode optar por executar para limitar o acesso e os recursos do invasor.

Revogar credenciais comprometidas

Para credenciais expostas ou exploradas, a ação mais imediata que você pode tomar é revogar as credenciais afetadas para evitar mais uso indevido.

• Revogar por meio da API

  Se o token for um dos seguintes tipos e o valor literal do token for conhecido, você (ou qualquer pessoa) poderá revogá-lo enviando uma solicitação por meio da API REST. Consulte Revogação.

  • Personal access token (classic)
  • Fine-grained personal access token

• Opções de revogação e contenção

  Há opções adicionais para bloquear o acesso à credencial. Para obter uma lista completa por tipo de credencial, consulte Tipos de credenciais do GitHub: Referência.

• Ações de emergência (incidente principal)

  Os proprietários da empresa no GitHub Enterprise Cloud podem realizar ações de emergência em massa para bloquear o acesso em toda a empresa. Para empresas com Enterprise Managed Users, isso inclui a exclusão de todos os tokens e chaves de usuário. Essas são ações de alto impacto que interromperão as automações e devem ser reservadas para incidentes importantes. Consulte Respondendo a incidentes de segurança em sua empresa.

Restringir o acesso

Para restringir o acesso à empresa, organização ou repositório, há várias ações imediatas que você pode executar.

• Configurar listas de permissões de IP

  Impedir que endereços IP desconhecidos ou suspeitos acessem a organização ou a empresa. Consulte Como restringir o tráfego de rede para sua empresa com uma lista de permissões de IP (administradores corporativos) e Gerenciar endereços IP permitidos para sua organização (proprietários da organização).

• Remover usuários comprometidos ou suspeitos

  Remova o usuário ou suspenda a conta. Consulte Remover um integrante da organização (proprietários da organização).

• Alterar a visibilidade do repositório para privada

  Altere a visibilidade do repositório afetado para privada e restrinja a capacidade de outras pessoas de fazer alterações adicionais. Por exemplo, se o código confidencial foi exposto em um repositório público pertencente à organização ou se um ator mal-intencionado alterou a configuração de visibilidade do repositório de privado para público, você pode alterar a visibilidade do repositório. Consulte Definir a visibilidade do repositório (administradores de repositório e proprietários da organização) e Restringir as alterações de visibilidade de repositório na organização (proprietários da organização).

• Ações de emergência (incidente principal)

  Os proprietários de empresas GitHub Enterprise Cloud podem realizar ações de emergência em massa para restringir o acesso em toda a empresa. Isso inclui bloquear o SSO para bloquear todo o acesso de não proprietário e revogar todas as autorizações de SSO de usuário entre organizações. Essas são ações de alto impacto que interromperão as automações e devem ser reservadas para incidentes importantes. Consulte Respondendo a incidentes de segurança em sua empresa.

Desativar artefatos maliciosos e atividade

• Parar execuções de fluxo de trabalho malicioso

  Se você suspeitar que um GitHub Actions fluxo de trabalho ou executor está sendo usado como parte de um ataque ativo, poderá executar as seguintes ações:

  • Cancele as execuções de fluxo de trabalho em andamento para um repositório afetado. Consulte Cancelar a execução do fluxo de trabalho.
  • Desabilite GitHub Actions para um repositório afetado em uma organização ou para uma organização específica. Consulte Desabilitando ou limitando GitHub Actions para sua organização (proprietários da organização) e Impor políticas para GitHub Actions em sua empresa (administradores corporativos).
  • Remova os executores auto-hospedados. Consulte Remover executores auto-hospedados.

• Desabilitar webhooks

  Se você suspeitar que um repositório comprometido ou webhook da organização está sendo usado como um canal de exfiltração de dados ao vivo, você poderá desabilitá-lo. Consulte Desativar webhooks.

• Excluir branches maliciosos

  Se você identificou branches que contêm código mal-intencionado ou fluxos de trabalho, exclua-os imediatamente para impedir a execução. Consulte Criar e excluir branches no repositório.

Etapa 3: Investigar totalmente

Após a contenção imediata, o objetivo agora é entender o escopo completo e o impacto do incidente, identificar todos os IoCs e mecanismos de persistência e reunir as evidências necessárias para conter e corrigir totalmente a ameaça.

1. Com base nos sinais que você viu e nas evidências coletadas até agora, desenvolva uma hipótese funcional do que aconteceu e decida quais evidências adicionais você precisará provar ou refutar essa hipótese.

2. Considere as diferentes áreas de investigação descritas em Áreas comuns de investigação de incidentes de segurança para ajudar a orientar sua investigação.

   Não limite sua investigação a uma única linha de investigação. Muitos ataques usam uma combinação de técnicas, como instalação de pacote mal-intencionado combinada com exploração de credenciais, injeções de arquivo de fluxo de trabalho e exfiltração de dados. Verifique se você está investigando todos os possíveis vetores de ataque.

3.        **Documente** todos os IoCs conhecidos até agora, buscando indícios em todas as superfícies de GitHub.
   

4.        **Inventário** de todos os fluxos de trabalho, repositórios e organizações afetados para capturar o escopo do incidente sistematicamente.
   

   • Inclua o nome do repositório, o que foi afetado (código, segredos, fluxos de trabalho) e a linha do tempo de comprometimento.
   • Crie uma lista de todas as contas e credenciais afetadas. Observe quais tokens, chaves SSH ou outras credenciais podem ter sido expostos ou usados indevidamente.

5.        **Valide** sua teoria de trabalho contra as evidências.
   

   • Revise as evidências que você reuniu. Ele dá suporte à sua hipótese inicial?
   • Considere explicações alternativas. Poderia haver uma causa diferente para a atividade que você observou?
   • Se sua hipótese for reprovada, forme uma nova hipótese com base nas evidências e repita as etapas de investigação conforme necessário.

6.        **Volte para a contenção** se você descobrir novos Indicadores de Comprometimento (IoCs) ou evidências de atividade em andamento que exige ação imediata.
   

Depois de ter alta confiança em sua compreensão do que aconteceu e da causa raiz, documente suas descobertas e prossiga para a correção.

Etapa 4: Corrigir

A meta agora é remover todos os rastreamentos de comprometimento, corrigir a causa raiz e restaurar sistemas para um estado seguro. As ações de correção dependerão da exploração que você enfrentou, mas algumas boas práticas são as seguintes.

Girar tokens e segredos

Mesmo que você não tenha certeza de que uma credencial foi comprometida, gire-a se houver alguma possibilidade de exposição.

• Gere novos tokens e segredos para substituir aqueles que foram revogados ou expostos.
• Gire os segredos armazenados nos GitHub níveis de repositório, ambiente e organização.
• Atualize as credenciais em sistemas externos que possam ter sido acessados usando tokens comprometidos.
• Considere habilitar políticas de expiração de token para incentivar a rotação regular daqui para frente. Consulte Como impor políticas para tokens de acesso pessoal na empresa.

Auditoria para mecanismos de persistência

Você precisará verificar os mecanismos de persistência que o invasor pode ter estabelecido para manter o acesso mesmo após as ações de contenção iniciais.

Isso inclui, mas não se limita a, verificar coisas como:

• Arquivos de fluxo de trabalho suspeitos ou desconhecidos que podem ter sido adicionados ou modificados.
• Novos webhooks indicando domínios desconhecidos.
• Novos corredores auto-hospedados.
• Modificações em corredores auto-hospedados.
• Recém-instaladas GitHub Apps ou OAuth app autorizações.
• Novas chaves de implantação adicionadas aos repositórios.
• Novos arquivos binários ou executáveis.

Auditar e reinstalar dependências

Dependências comprometidas podem servir como um vetor de ataque. Assegure-se de fazer uma auditoria completa de suas dependências e reinstalá-las de fontes confiáveis.

• Revise os Dependabot alertas para dependências vulneráveis e, quando disponível, revise os Dependabot malware alerts para pacotes mal-intencionados. (Dependabot malware alerts estão disponíveis no momento para o ecossistema npm.) Para investigar avisos adicionais de malware, pesquise type:malware e audite o GitHub Advisory Database grafo de dependência para obter correspondências.
• Fixe dependências em versões conhecidas ou confirme SHAs e reinstale do registro de pacote.

Verificar a remediação

Confirme se seus esforços de correção foram bem-sucedidos.

• Examine os code scanning alertas para confirmar se as vulnerabilidades de código foram resolvidas e nenhuma nova vulnerabilidade foi introduzida.
• Examine secret scanning os alertas para confirmar que nenhum segredo permanece exposto em nenhum repositório e que todos os alertas foram resolvidos.
• Continue revisando e monitorando logs de auditoria e outras superfícies relevantes nos próximos dias e semanas após o incidente.

Etapa 5. Documento

A documentação completa é essencial para as fases restantes e para referência futura.

• Registre todos os IoCs descobertos durante a investigação.
• Documente todas as etapas de correção realizadas, incluindo marcadores de data e hora e a pessoa que executou cada ação.
• Mantenha inventários de repositórios, fluxos de trabalho e contas afetados.
• Decisões de documento tomadas e o raciocínio por trás delas.
• Observe quaisquer implicações de conformidade, legais ou de privacidade. Considere se esse incidente constitui uma violação de dados que requer notificação.

Etapa 6: Refletir e fortalecer

O objetivo agora é aprender com o incidente e fortalecer sua postura de segurança para evitar incidentes semelhantes.

1. Escreva um resumo de incidentes. Isso deve incluir uma linha do tempo de eventos da primeira indicação à resolução, bem como a análise da causa raiz, as decisões e as ações tomadas e as lições aprendidas.

2. Acompanhe quaisquer itens de ação pendentes do incidente de segurança como problemas, como tarefas de correção restantes e quaisquer melhorias de segurança que precisam ser implementadas com base nas lições aprendidas.

3. Se você ainda não tiver um, verifique se sua empresa ou equipe tem um Plano de Resposta a Incidentes de Segurança atualizado. Isso deve incluir funções e responsabilidades definidas, caminhos de escalonamento, protocolos de comunicação, critérios de classificação de severidade e procedimentos de resposta passo a passo para tipos comuns de ameaças. Copilot pode ajudar a gerar e refinar esse plano com base em suas necessidades e recursos específicos. Para obter diretrizes adicionais, consulte o que é resposta a incidentes.

Próximas Etapas 

• Caso ainda não tenha feito isso, considere proteger sua postura de segurança para reduzir o risco de incidentes futuros. Consulte Proteção contra ameaças à segurança.