Respuesta a un incidente de seguridad

Las instrucciones de este artículo están dirigidas a propietarios empresariales, propietarios de la organización, administradores de seguridad y equipos de seguridad. Sin embargo, deberá tener el rol de propietario de la empresa para realizar varias de las acciones descritas en este artículo. Algunos pasos pueden requerir coordinación con los propietarios de la organización o los administradores de repositorios.

Introduction

Esta guía le guía a través de cómo responder a un incidente de seguridad, esquematización de las GitHub superficies que puede usar para validar e investigar una amenaza, y las herramientas que puede usar para contenerlo y corregirlo.

Prerequisites

Idealmente, ya tiene habilitado el streaming del registro de auditoría y la visibilidad de la dirección IP de origen para la empresa (transmitiendo los datos a un sistema de administración de eventos e información de seguridad (SIEM)) y tiene acceso a esos datos. Consulte Streaming del registro de auditoría de su empresa.

A lo largo de tu respuesta.

A medida que desarrolla su respuesta, asegúrese de que:

• Conservar evidencia: tome capturas de pantalla de la actividad sospechosa, exporte los registros o los resultados de la consulta y guarde copias de los archivos afectados o el código antes de la limpieza.
• Mantener un registro: documente los resultados (por ejemplo, horas, fechas, indicadores de compromiso (IoC), repositorios afectados) y registre cada decisión que tome.
• Comunicar: notifique a las partes interesadas pertinentes (como responsables de seguridad y administradores de ingeniería, así como a los equipos legales y de privacidad si la información confidencial está en riesgo) y manténgalos actualizados.

Paso 1: Evaluar la señal y validar rápidamente

El objetivo es determinar rápidamente si la señal que ve es probable que sea una amenaza real y activa.

1. Identificación

Intente identificar la naturaleza de la señal que está viendo. Por ejemplo, la señal muestra indicaciones de:

• Peligro de credenciales (alerta de un secreto filtrado, informes de credenciales encontradas en un sitio externo)
• Acceso no autorizado o peligro de la cuenta (informes de inicios de sesión sospechosos, confirmaciones o cambios desconocidos)
• Filtración de datos (informes de cambios o adiciones de archivos sospechosos, ejecuciones de flujo de trabajo inesperadas, actividad de API inusual, creaciones de repositorio desconocidas o cambios inesperados de visibilidad del repositorio)
• Inyección de código malintencionada (informes de cambios de código sospechosos, ejecuciones de flujo de trabajo inesperadas, nuevos archivos agregados)
• Ataque de cadena de suministro (informes de versiones sospechosas de paquetes, alertas de dependencias vulnerables)

Para obtener ayuda para identificar estas señales de amenazas en toda la organización o empresa, consulte Áreas comunes de investigación de incidentes de seguridad.

Le sugerimos que no dedique demasiado tiempo a realizar una inspección profunda en las fases anteriores de la investigación, ya que el objetivo inicial es identificar la señal de amenaza para validarla y estratega la respuesta.

2. Validar

Compruebe si hay evidencia para validar que la posible amenaza es real y si está activa o no.

Las siguientes GitHub herramientas y superficies pueden ayudar.

Herramienta y superficie	propósito
Información general de seguridad y alertas de seguridad	Revisión de alertas de seguridad en toda la organización o empresa
Registros de auditoría	Busque eventos relacionados con la señal que está investigando, como la creación de tokens, los cambios de permisos o los cambios de visibilidad del repositorio.
Vista de actividad	Ver una línea de tiempo de pushes, confirmaciones y actividad en la rama para un repositorio específico
[

          GitHub búsqueda de código](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | Buscar indicadores conocidos de peligro, como nombres de archivo específicos o patrones de código, entre repositorios |

| Gráfico de dependencias | Comprobación de si los repositorios dependen de un paquete o una versión de paquete específicos | | Ejecuciones y registros de flujo de trabajo | Revisar el historial de ejecución del flujo de trabajo e inspeccionar la salida de registros para detectar actividad sospechosa |

Para obtener más información sobre cada herramienta, consulte Herramientas de investigación para incidentes de seguridad.

La fase de validación puede ser rápida:

• Pretende recopilar suficientes evidencias para determinar si es probable que la señal sea una amenaza real y activa .
• Si no puede descartar rápidamente la señal como un falso positivo, suponga que es real.
• La investigación profunda se puede realizar más adelante.

3. Decidir

En función de las pruebas recopiladas, determine tres cosas:

1.        **¿Es una amenaza real?** Si no puede descartar rápidamente y con confianza la señal como un falso positivo, trátela como real y continúe con la contención.
   

2.        **¿La amenaza sigue activa?** Si el atacante parece tener acceso o actividad está en curso, priorice primero las acciones de contención inmediatas. Si el compromiso parece ser histórico, todavía debe investigar y remediar, pero es posible que tenga más tiempo para planificar la respuesta.
   

3.        **¿Cuál es el ámbito potencial?** Considere hasta dónde podría llegar la brecha de seguridad: una sola credencial, un repositorio, una organización o la empresa completa. Esto le ayudará a escalar la respuesta correctamente.
   

En caso de duda, trate la amenaza como real, y reduzca su respuesta a medida que la evidencia lo permita.

Paso 2: Contener la amenaza

En el siguiente paso se asume que está tratando con una amenaza real y activa. El objetivo ahora es reducir inmediatamente el riesgo continuo mediante lo que sabe hasta ahora.

Hay varias acciones de contención que puede realizar para limitar el acceso y las funcionalidades del atacante.

Revocar credenciales comprometidas

En el caso de las credenciales expuestas o explotadas, la acción más inmediata que puede realizar es revocar las credenciales afectadas para evitar un uso incorrecto adicional.

• Revocar a través de la API

  Si el token es uno de los siguientes tipos y se conoce el valor literal del token, usted (o cualquiera) puede revocarlo mediante el envío de una solicitud a través de la API REST. Consulte Revocación.

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

• Opciones de revocación y contención

  Hay opciones adicionales para bloquear el acceso a las credenciales. Para obtener una lista completa por tipo de credencial, consulte Referencia de tipos de credenciales de GitHub.

• Acciones de emergencia (incidente principal)

  Los propietarios de empresas en GitHub Enterprise Cloud pueden realizar acciones masivas de emergencia para bloquear el acceso en todas sus empresas. En el caso de las empresas con Enterprise Managed Users, esto incluye eliminar todos los tokens y claves de usuario. Estas son acciones de alto impacto que interrumpirán las automatizaciones y se deben reservar para incidentes importantes. Consulte Responder a incidentes de seguridad en su empresa.

Restringir el acceso

Para restringir el acceso a la empresa, organización o repositorio, hay varias acciones inmediatas que puede realizar.

• Configurar listas de permitidos de IP

  Impedir que las direcciones IP desconocidas o sospechosas accedan a la organización o a la empresa. Consulte Restricción del tráfico de red a la empresa con una lista de direcciones IP permitidas (administradores de empresa) y Administrar las direcciones IP permitidas en tu organización (propietarios de la organización).

• Eliminación de usuarios en peligro o sospechosos

  Quite el usuario o suspenda la cuenta. Consulte Eliminar a un miembro de tu organización (propietarios de la organización).

• Cambio de la visibilidad del repositorio a privado

  Cambie la visibilidad del repositorio afectado a privado y restrinja la capacidad de otros usuarios para realizar más cambios. Por ejemplo, si el código confidencial se expone en un repositorio público que pertenece a la organización, o si un actor malintencionado cambió la configuración de visibilidad del repositorio de privado a público, puede cambiar la visibilidad del repositorio. Consulte Configurar la visibilidad de un repositorio (administradores de repositorios y propietarios de la organización) y Restringir cambios en la visibilidad de los repositorios en tu organización (propietarios de la organización).

• Acciones de emergencia (incidente principal)

  Los propietarios de empresas en GitHub Enterprise Cloud pueden realizar acciones masivas de emergencia para bloquear el acceso en toda su organización. Estos incluyen bloquear el SSO para impedir todo acceso de personas no propietarias y revocar todas las autorizaciones de SSO de usuario en todas las organizaciones. Estas son acciones de alto impacto que interrumpirán las automatizaciones y se deben reservar para incidentes importantes. Consulte Responder a incidentes de seguridad en su empresa.

Desactivar actividad y artefactos malintencionados

• Detener ejecuciones de flujo de trabajo malintencionadas

  Si sospecha que se usa un GitHub Actions flujo de trabajo o un ejecutor como parte de un ataque activo, puede realizar las siguientes acciones:

  • Cancelar ejecuciones de flujo de trabajo en curso para un repositorio afectado. Consulte Cancelar una ejecución de flujo de trabajo.
  • Deshabilite GitHub Actions para un repositorio afectado en una organización o para una organización específica. Consulte Deshabilitación o limitación de GitHub Actions para su organización (propietarios de la organización) y Aplicación de directivas para GitHub Actions en la empresa (administradores de empresa).
  • Elimine los ejecutores autohospedados. Consulte Eliminar ejecutores autoalojados.

• Deshabilitar webhooks

  Si sospecha que se está usando un repositorio comprometido o un webhook de organización como un canal de exfiltración de datos en vivo, puede deshabilitarlo. Consulte Desactivación de webhooks.

• Eliminar ramas maliciosas

  Si ha identificado ramas que contienen código malintencionado o flujos de trabajo, elimínelas inmediatamente para evitar la ejecución. Consulte Crear y eliminar ramas en tu repositorio.

Paso 3: Investigar completamente

Después de la contención inmediata, el objetivo ahora es comprender el ámbito completo y el impacto del incidente, identificar todos los ioCs y mecanismos de persistencia, y recopilar la evidencia que necesita para contener y corregir completamente la amenaza.

1. En función de las señales que ha visto y de las pruebas recopiladas hasta ahora, desarrolle una hipótesis de trabajo de lo que ha ocurrido y decida qué evidencia adicional necesitará probar o rechazar esa hipótesis.

2. Tenga en cuenta las diferentes áreas de investigación descritas en Áreas comunes de investigación de incidentes de seguridad para ayudar a guiar su investigación.

   No limite su investigación a una sola línea de investigación. Muchos ataques usan una combinación de técnicas, como la instalación de paquetes malintencionados combinada con la explotación de credenciales, las inyecciones de archivos de flujo de trabajo y la filtración de datos. Asegúrese de que está investigando todos los vectores de ataque potenciales.

3.        **Documente** todos los IOC conocidos hasta ahora, buscando rastros a través de todas las superficies de GitHub.
   

4.        **Realice un inventario** de todos los flujos de trabajo, repositorios y organizaciones afectados para capturar el ámbito del incidente sistemáticamente.
   

   • Incluya el nombre del repositorio, lo que se ha visto afectado (código, secretos, flujos de trabajo) y la escala de tiempo de riesgo.
   • Cree una lista de todas las cuentas y credenciales afectadas. Tenga en cuenta qué tokens, claves SSH u otras credenciales pueden haberse expuesto o mal usado.

5.        **Valide** tu teoría de trabajo con la evidencia.
   

   • Revise la evidencia que ha recopilado. ¿Sostiene su hipótesis inicial?
   • Considere las explicaciones alternativas. ¿Podría haber una causa diferente para la actividad que ha observado?
   • Si la hipótesis no se aprueba, forme una nueva hipótesis basada en la evidencia y repita los pasos de investigación según sea necesario.

6.        **Regrese a la contención** si detecta nuevos IoC o evidencia de actividad en curso que requiere una acción inmediata.
   

Una vez que tenga alta confianza en su comprensión de lo que ha ocurrido y la causa principal, documente sus hallazgos y continúe con la corrección.

Paso 4: Corrección

El objetivo ahora es eliminar todos los indicios de compromiso, corregir la causa raíz y restaurar los sistemas a un estado seguro. Las acciones de corrección dependerán de la explotación a la que se enfrenta, pero algunos procedimientos recomendados son los siguientes.

Rotación de tokens y secretos

Aunque no esté seguro de que se haya comprometido una credencial, rótele si hay alguna posibilidad de exposición.

• Genere nuevos tokens y secretos para reemplazar los que se revocaron o que se hayan expuesto.
• Gira los secretos almacenados en GitHub en los niveles de repositorio, entorno y organización.
• Actualice las credenciales de los sistemas externos a los que se pueda acceder mediante tokens en peligro.
• Considere la posibilidad de habilitar las directivas de expiración de tokens para fomentar la rotación regular en el futuro. Consulte Imposición de políticas para tokens de acceso personales en su empresa.

Auditoría de mecanismos de persistencia

Deberá comprobar si hay mecanismos de persistencia que el atacante haya establecido para mantener el acceso incluso después de las acciones de contención iniciales.

Esto incluye, pero no está limitado a, comprobando cosas como:

• Archivos de flujo de trabajo sospechosos o desconocidos que se pueden haber agregado o modificado.
• Nuevos webhooks que apuntan a dominios desconocidos.
• Nuevos ejecutores autohospedados.
• Modificaciones para ejecutores autohospedados.
• Autorizaciones recién instaladas GitHub Apps o OAuth app.
• Nuevas claves de implementación agregadas a los repositorios.
• Nuevos archivos binarios o ejecutables.

Auditoría y reinstalación de dependencias

Las dependencias en peligro pueden servir como vector de ataque. Asegúrese de realizar una auditoría completa de las dependencias y reinstalarlas desde orígenes de confianza.

• Revise las alertas Dependabot para dependencias vulnerables y, si están disponibles, Dependabot malware alerts para paquetes malintencionados. (Dependabot malware alerts están disponibles actualmente para el ecosistema de npm). Para investigar avisos de malware adicionales, busque type:malware en el GitHub Advisory Database gráfico de dependencias y audite las coincidencias.
• Ancle las dependencias a versiones correctas conocidas o confirme shAs y vuelva a instalar desde el registro de paquetes.

Comprobación de la corrección

Confirme que los esfuerzos de corrección se han realizado correctamente.

• Revise code scanning las alertas para confirmar que se han resuelto las vulnerabilidades de código y no se han introducido nuevas vulnerabilidades.
• Revise secret scanning las alertas para confirmar que ningún secreto permanece expuesto en ningún repositorio y que se han resuelto todas las alertas.
• Continúe revisando y supervisando los registros de auditoría y otras superficies pertinentes en los próximos días y semanas posteriores al incidente.

Paso 5. Documento

La documentación exhaustiva es esencial para las fases restantes y para futuras referencias.

• Registre todas las IoC detectadas durante la investigación.
• Documente todos los pasos de corrección realizados, incluidas las marcas de tiempo y quién realizó cada acción.
• Mantenga inventarios de repositorios, flujos de trabajo y cuentas afectados.
• Documente las decisiones tomadas y el razonamiento detrás de ellos.
• Tenga en cuenta las implicaciones de cumplimiento, legal o privacidad. Considere si este incidente constituye una infracción de datos que requiere notificación.

Paso 6: Reflexionar y fortalecer

El objetivo ahora es aprender del incidente y reforzar su posición de seguridad para evitar incidentes similares.

1. Escriba un resumen de incidentes. Esto debe incluir una escala de tiempo de los eventos de la primera indicación a la resolución, así como el análisis de la causa principal, las decisiones y las acciones tomadas y las lecciones aprendidas.

2. Realice un seguimiento de los elementos de acción pendientes del incidente de seguridad como problemas, como las tareas de corrección restantes y las mejoras de seguridad que deba implementarse en función de las lecciones aprendidas.

3. Si aún no tiene uno, asegúrese de que su empresa o equipo tenga un plan de respuesta a incidentes de seguridad actualizado. Esto debe incluir roles y responsabilidades definidos, rutas de acceso de escalación, protocolos de comunicación, criterios de clasificación de gravedad y procedimientos de respuesta paso a paso para tipos de amenazas comunes. Copilot puede ayudar a generar y refinar este plan en función de sus necesidades y recursos específicos. Para obtener instrucciones adicionales, consulte ¿Qué es la respuesta a incidentes?

Pasos siguientes

• Si aún no lo ha hecho, considere la posibilidad de reforzar la posición de seguridad para reducir el riesgo de incidentes futuros. Consulte Protección contra amenazas de seguridad.