Herramientas de investigación para incidentes de seguridad

Use esta referencia para decidir qué GitHub herramientas usar durante una investigación de seguridad, qué preguntas pueden responder cada herramienta y qué factores pueden afectar a los datos que puede ver.

Nota:

La disponibilidad de cada herramienta (y los datos que proporciona) varía según GitHub el plan, el rol y los permisos, la habilitación de características y la configuración previa al incidente (por ejemplo, la transmisión de registros de auditoría y la divulgación de direcciones IP requieren una configuración previa).

Vista de actividad

Uso

Obtenga información general sobre la actividad en un repositorio específico, incluidas las combinaciones, las inserciones, las inserciones forzadas, las creaciones y eliminaciones de ramas, que se atribuyen a actores específicos durante un período definido.
Correlaciona las apariciones de código sospechoso con envíos o fusiones relacionadas.
Responda a preguntas sobre cuándo se realizó un cambio, quién lo hizo, en qué rama, y explore el historial de diferencias o confirmaciones.

Permissions

Acceso de lectura al repositorio.

Recursos clave

Uso de la vista de actividad para ver los cambios en un repositorio

Notas y limitaciones

La vista de actividad se usa mejor como una superficie inicial de navegación y correlación; no tiene la misma integridad o capacidad de consulta que las exportaciones en bruto de registros de auditoría.
Algunos incidentes requieren correlación entre repositorios u organizaciones, lo que puede ser más fácil en el registro de auditoría.

Registros de auditoría

Uso

Responda a preguntas sobre lo que ha cambiado, cuándo y por quién en una empresa u organización.
Investigar eventos que pueden haber habilitado el riesgo o indicarlo, como cambios en la pertenencia, los roles, los permisos o la generación o el uso de tokens de acceso, etc.
Atribuye acciones relevantes para la seguridad a un actor (usuario o integración) y cree una escala de tiempo de investigación.
Filtre por actor, acción, dirección IP (si está habilitada) o token, para identificar la actividad sospechosa o el uso del token de seguimiento.
Correlacionar la actividad entre varios repositorios o organizaciones.

Permissions

Para ver el registro de auditoría de la organización, debe ser propietario de la organización.
Para ver el registro de auditoría de empresa, debe ser administrador de empresa.
Para ver el registro de seguridad (cuenta personal), debe ser el propietario de la cuenta.
Para ver los datos del registro de auditoría exportados a un sistema externo de administración de eventos e información de seguridad (SIEM), el sistema de administración de registros u otras herramientas y servicios, necesita acceder a ese sistema.

Recursos clave

Notas y limitaciones

GitHubproporciona tres registros de auditoría: registros de seguridad de empresa, organización y usuario.****
La interfaz de usuario del GitHub registro de auditoría tiene funcionalidades limitadas de filtrado y búsqueda . Por este motivo, se recomienda que las empresas transmitan el registro de auditoría de empresa a un sistema externo de administración de registros o SIEM para realizar consultas más avanzadas.
- La transmisión de registros de auditoría a un sistema de administración de registros o SIEM externo requiere una configuración anterior. Consulte Streaming del registro de auditoría de su empresa.
- Sin el streaming de registros de auditoría, no podrá ejecutar consultas más complejas, como correlacionar eventos entre organizaciones o repositorios, o cambiar el enfoque desde un token específico a todos los eventos relacionados.
- Los datos de eventos del sistema Git se incluyen en la secuencia.
Se recomienda streaming de eventos de solicitud de API; esto requiere una configuración anterior. Consulte Streaming del registro de auditoría de su empresa.
Para las empresas en GitHub Enterprise Cloud, se recomienda mostrar las direcciones IP en los registros de auditoría; esto requiere una configuración previa. Consulte Presentación de direcciones IP en el registro de auditoría de la empresa.
Los diferentes GitHub planes tienen diferentes ofertas de disponibilidad de datos y retención de datos:
- ```
          Los planes de GitHub Free y GitHub Team no permiten ver la actividad de la API ni los eventos de Git.
```
- Las organizaciones independientes (organizaciones que no forman parte de una empresa) no pueden transmitir los registros de auditoría, no pueden ver eventos de solicitud de API y están limitados a 7 días para los datos de eventos de Git.
- Para empresas con GitHub Enterprise Cloud:
  - Si su empresa usa Enterprise Managed Users, el registro de auditoría también incluye registros de seguridad de usuario (eventos relacionados con cuentas de usuario, como la actividad de inicio de sesión y el uso de tokens).
  - Si su empresa _no usa_Enterprise Managed Users, el GitHub registro de auditoría solo incluye eventos relacionados con la cuenta de empresa y las organizaciones dentro de ella.
Los registros de auditoría no incluyen la vista de página ni la telemetría de exploración del repositorio.

Gráfica de dependencias

Uso

Compruebe si un repositorio depende de un paquete vulnerable o en peligro (o versión).
Revise las dependencias nuevas o sospechosas que se pueden haber introducido durante un incidente.
Filtre y explore las dependencias por ecosistema o relación (directa o transitiva).
Exporte una lista de materiales de software (SBOM) para fines de auditoría o para conservar la evidencia.

Permissions

Acceso de escritura o mantenimiento en el repositorio.

Recursos clave

Notas y limitaciones

El gráfico de dependencias se genera a partir de archivos de manifiesto/bloqueo admitidos (y envíos opcionales en tiempo de compilación), por lo que puede ser incompleto o diferente de lo realmente creado e implementado. Para obtener la vista más precisa, especialmente para las dependencias resueltas durante la CI/compilación, debe complementar el gráfico de dependencias con el envío de dependencias en el momento de la compilación (u otra procedencia de la compilación, como SBOM).

GitHub búsqueda de código

Uso

Buscar indicadores de compromiso (IoC) entre los repositorios, como flujos de trabajo o nombres de paquetes malintencionados conocidos.
Evaluar rápidamente el radio de explosión potencial verificando si los patrones de código sospechosos, como un secreto filtrado o un fragmento de código malintencionado, aparecen en otros repositorios de la organización o empresa.
Delimita la búsqueda usando distintos calificadores que pueden ser útiles durante un incidente, por ejemplo:
- Busque dentro de un repositorio, organización o empresa determinados (mediante los repo:, org:, enterprise: calificadores).
- Buscar en rutas de archivos específicas (path:.github/workflows repo:ORG-NAME/REPO-NAME).

Permisos requeridos

Para buscar en repositorios públicos, debe iniciar sesión en su GitHub cuenta.
Para buscar en repositorios privados, debe tener acceso de lectura a esos repositorios.

Recursos clave

Buscar código

Notas y limitaciones

Admite la búsqueda regex.
Busca solo en la rama predeterminada de un repositorio. Si el código sospechoso se introdujo en una rama no predeterminada y no se ha combinado, la búsqueda de código no la encontrará.
Puede usar la búsqueda de código para determinar si hay un patrón o IoC presente, pero no proporciona contexto, como cuando el código se agregó o por quién. Debe usar la búsqueda de código junto con otras herramientas, como registros de auditoría, vista de actividad o comprobación de la vista de responsabilidad, historial de confirmaciones e historial de solicitudes de incorporación de cambios de un repositorio.

Información general de seguridad y alertas de seguridad

Uso

Consultar una vista general de todas las alertas de seguridad (alertas de secret scanning, code scanning y Dependabot) en los repositorios de una organización o empresa.
Evaluar lo que GitHub ya ha detectado e identificar qué repositorios se ven afectados.
Realice un seguimiento de las nuevas alertas creadas durante un incidente (lo que puede indicar la explotación activa o la propagación).

Permisos requeridos

Para ver los datos de las organizaciones en el nivel empresarial, un administrador de empresa debe tener el rol propietario de la organización o administrador de seguridad en las organizaciones pertinentes.
Para ver los datos de los repositorios en el nivel de organización, se requiere el rol propietario de la organización o administrador de seguridad.

Recursos clave

Notas y limitaciones

Las alertas de secretos filtrados, código vulnerable, dependencias vulnerables y malware solo son visibles si las características pertinentes se habilitaron y configuraron antes del incidente.

Ejecuciones y registros de flujo de trabajo

Uso

Confirme lo que se ejecutó en CI/CD en un momento determinado (como los comandos ejecutados o la dependencia instalada).
Investigue las ejecuciones sospechosas de flujo de trabajo, como las desencadenadas por un usuario desconocido o en un momento inusual, para ver qué acciones se realizaron, qué secretos se accedieron y qué código se ejecutó.
Revise a qué credenciales tuvo acceso una tarea de flujo de trabajo, incluido el GITHUB_TOKEN predeterminado, cualquier token de personal access tokens y GitHub App, otras credenciales almacenadas como secretos y los tokens de acceso obtenidos durante la ejecución del flujo de trabajo.
Recupere registros mediante programación a través de la API REST para fines de archivado, forense o automatización.

Permisos requeridos

Acceso de lectura al repositorio.

Recursos clave

Notas y limitaciones

GitHub censura automáticamente los secretos de los registros de flujo de trabajo.
De forma predeterminada, los registros de flujo de trabajo se conservan durante GitHub 90 días, pero puede configurar este período de retención. La retención máxima es de 400 días. La retención se puede configurar en el nivel de empresa, organización o repositorio. Si se produjo una ejecución de flujo de trabajo fuera de la ventana de retención configurada, es posible que los registros ya no estén disponibles. Para más información, consulta Administración de la configuración de GitHub Actions para un repositorio, Configuración del período de retención para los artefactos y registros de GitHub Actions en tu organización o Aplicación de directivas para GitHub Actions en la empresa.
Las ejecuciones de flujo de trabajo (incluidos sus registros) también se pueden eliminar a través de la API REST. Para comprobar si se eliminó una ejecución, busque eventos workflows.delete_workflow_run en el registro de auditoría.
El GITHUB_TOKEN predeterminado que se emite para cada trabajo se limita a ese trabajo y caduca cuando el trabajo finaliza o al alcanzar su vida útil máxima efectiva (hasta 24 horas en runners autohospedados). Incluso si un paso capturó el token, no se puede reutilizar una vez finalizado el trabajo. Para obtener más información, vea GITHUB_TOKEN.
Otras credenciales a las que se hace referencia en flujos de trabajo, como personal access tokens, GitHub App tokens de instalación o claves de API de terceros almacenadas como secretos, tienen su propio ciclo de vida y no expiran cuando finaliza el trabajo. Si un paso de flujo de trabajo expone una de estas credenciales, el token permanece válido hasta que se revoca o expira según su propia directiva. Cualquier credencial que pueda haberse visto expuesta debe tratarse como comprometida y cambiarse o sustituirse de inmediato. Revise el archivo de flujo de trabajo y el repositorio, la organización y los secretos de entorno para determinar qué credenciales eran accesibles. Para obtener más información, vea Uso de secretos en Acciones de GitHub.
Puede descargar registros para toda una ejecución de flujo de trabajo o para un trabajo específico mediante programación mediante la API REST. Ambos puntos de conexión devuelven una dirección URL de redireccionamiento válida durante un minuto. Para obtener más información, vea Puntos de conexión de API de REST para ejecuciones de flujo de trabajo y Puntos de conexión de API de REST para trabajos de flujo de trabajo.
Los registros de ejecución de flujo de trabajo solo capturan la salida estándar de los pasos de flujo de trabajo. La actividad que no escribe en la salida estándar, como las llamadas de red, las modificaciones del sistema de archivos o los procesos en segundo plano, no aparecen en los registros.
Para los ejecutores alojados en GitHub, el entorno del ejecutor es efímero y se destruye cuando finaliza el trabajo. GitHub no conserva ningún dato más allá de los registros de ejecución del flujo de trabajo para estos ejecutores. Para los runners autohospedados, puede haber telemetría adicional a nivel de host o de red disponible a través de tu propia infraestructura.
Para una investigación más completa, ponga en correlación los registros de ejecución del flujo de trabajo con eventos de registro de auditoría. Los eventos como git.clone, git.fetch, git.push, protected_branch.createy protected_branch.policy_override pueden proporcionar contexto adicional. Dado que los eventos de Git en los registros de auditoría alojados en GitHub actualmente solo se conservan durante 7 días en las empresas, es importante configurar con antelación la transmisión de los registros de auditoría empresariales para este tipo de investigación. Para obtener más información, vea Preparación de un incidente de seguridad.

Herramientas de investigación para incidentes de seguridad

En este artículo