Инструменты расследования инцидентов с безопасностью

Используйте эту ссылку, чтобы решить, какие GitHub инструменты использовать во время расследования безопасности, на какие вопросы каждый инструмент может ответить и какие факторы могут повлиять на доступные данные.

Примечание.

Доступность каждого инструмента (и предоставляемых им данных) зависит от GitHub плана, вашей роли и разрешений, включения функций и конфигурации до инцидента (например, стриминг журналов аудита и раскрытие IP-адреса требуют предварительной настройки).

Отображение активности

Использовать

Получите обзор активности в конкретном репозитории, включая слияния, пуши, форс-пуши, создание и удаление ветвей, приписываемые конкретным акторам за определённый период.
Сопоставьте подозрительные появления кода с соответствующими push-пушами или слияниями.
Отвечайте на вопросы о том, когда было внесено изменение, кто его сделал, в какой ветке и изучайте историю различий или коммитов.

Permissions

Читать доступ к репозиторию.

Ключевые ресурсы

Использование представления действий для просмотра изменений в репозитории

Заметки и ограничения

Вид активности лучше всего использовать как начальную навигационную и корреляционную поверхность; Он не обладает такой полнотой и возможностью запроса, как экспорт журналов аудита.
Некоторые инциденты требуют корреляции между репозиториями или организациями, что может быть проще в журнале аудита.

Журналы аудита

Использовать

Отвечайте на вопросы о том, что изменилось, когда и кем это произошло в компании или организации.
Расследуйте события, которые могли позволить компрометации или указать на это, такие как изменения в составе участников, ролей, разрешений, а также генерация или использование токенов доступа и т.д.
Приписывайте действия, связанные с безопасностью, участнику (пользователю или интеграции) и постройте хронологию расследования.
Фильтруйте по актору, действию, IP-адресу (если он включен) или токене, чтобы выявить подозрительные действия или использование токена отслеживания.
Сопоставьте активность между несколькими репозиториями или организациями.

Permissions

Чтобы просмотреть журнал аудита организации, вам нужно быть владельцем организации.
Чтобы просматривать журнал корпоративного аудита, нужно быть корпоративным администратором.
Чтобы просмотреть журнал безопасности (личный аккаунт), нужно быть владельцем аккаунта.
Чтобы просматривать данные журналов аудита, экспортированные во внешнюю систему управления информацией и событиями безопасности (SIEM), систему управления журналами или другие инструменты и сервисы, необходим доступ к этой системе.

Ключевые ресурсы

Заметки и ограничения

GitHub предоставляет три журнала аудита: журналы корпоративных, организационных и пользовательских журналов безопасности.
GitHub Интерфейс журнала аудита имеет ограниченные возможности фильтрации и поиска. По этой причине мы рекомендуем предприятиям транслировать журнал корпоративного аудита во внешнюю систему SIEM или систему управления журналами для более сложных запросов.
- Потоковая передача аудитских журналов на внешний SIEM или систему управления журналами требует предварительной настройки. См . раздел AUTOTITLE.
- Без потокового потока журналов аудита вы не сможете выполнять более сложные запросы, такие как корреляция событий между организациями или репозиториями, или переход с конкретного токена ко всем связанным событиям.
- Данные о событиях Git включены в поток.
Мы рекомендуем транслировать мероприятия с запросом на API; для этого требуется предварительная конфигурация. См . раздел AUTOTITLE.
Для предприятий на GitHub Enterprise Cloud, мы рекомендуем отображать IP-адреса в журналах аудита; для этого требуется предварительная настройка. См . раздел AUTOTITLE.
Разные GitHub планы предлагают разную доступность данных и хранение данных:
- GitHub Free и GitHub Team планы вообще не могут просматривать активность API или события Git.
- Автономные организации (организации, не входящие в корпоративное управление) не могут транслировать журналы аудита, не могут просматривать события запросов API и ограничены 7 днями для получения данных событий Git.
- Для предприятий по GitHub Enterprise Cloudследующим вопросам:
  - Если ваше предприятие использует Enterprise Managed Users, то журнал аудита также включает журналы безопасности пользователей (события, связанные с учетными записями пользователей, такие как активность входа в систему и использование токенов).
  - Если ваше предприятие _не использует,_Enterprise Managed Users то GitHub журнал аудита включает только события, связанные с корпоративным аккаунтом и организациями внутри него.
В журналах аудита нет телеметрии просмотра страниц или репозитории.

Граф зависимостей

Использовать

Проверьте, зависит ли репозиторий от уязвимого или скомпрометированного пакета (или версии).
Проверьте на наличие новых или подозрительных зависимости , которые могли появиться во время инцидента.
Фильтруйте и изучайте зависимости по экосистемам или отношениям (прямым или транзитивным).
Экспортировать программный список материалов (SBOM) для аудиторских целей или для сохранения доказательств.

Permissions

Пишите или поддерживайте доступ к репозиторию.

Ключевые ресурсы

Заметки и ограничения

Граф зависимостей генерируется из поддерживаемых файлов манифеста/блокировки (и опциональных отправок во время сборки), поэтому он может быть неполным или отличаться от того, что было создано и развернуто. Чтобы получить максимально точное представление, особенно для зависимостей, решаемых во время CI/сборки, следует дополнять граф зависимостей отправкой зависимостей во время сборки (или другим источником билдов, например, SBOM).

GitHub Поиск по коду

Использовать

Ищите индикаторы компрометации (IoC) по репозиториям, например, известные вредоносные рабочие процессы или имена пакетов.
Быстро определите потенциальный радиус взрыва, проверяя, не появляются ли подозрительные шаблоны кода, такие как утечка секрета или вредоносный фрагмент кода, в других хранилищах организации или предприятия.
Охватайте поиск по различным квалификаторам, которые могут быть полезны во время инцидента, например:
- Ищите в конкретном репозитории, организации или предприятии (с помощью repo:, org:, enterprise: квалификаторов).
- Поиск в рамках определённых путей файлов (path:.github/workflows repo:ORG-NAME/REPO-NAME).

Требуются разрешения

Чтобы искать по публичным репозиториям, необходимо войти в свой GitHub аккаунт.
Чтобы искать по частным репозиториям, необходимо иметь доступ к этим репозиториям.

Ключевые ресурсы

Поиск кода

Заметки и ограничения

Поддерживает поиск по регулярным выражениям.
Поиск осуществляется только по стандартной ветке репозитория. Если подозрительный код был введён в нестандартной ветке и не был объединён, его не найдут поиском кода.
Можно использовать поиск по коду, чтобы определить, присутствует ли паттерн или IoC, но он не даёт контекста, например, когда или кем был добавлен код. Вам следует использовать поиск по коду вместе с другими инструментами, такими как журналы аудита, просмотр активности или проверка виновного вида, истории коммитов и истории pull request в репозитории.

Обзор безопасности и оповещения о безопасности

Использовать

Просмотрите общий обзор всех оповещений безопасности (secret scanning, code scanningи Dependabot оповещений) в репозиториях организации или предприятия.
Сортируйте то, что GitHub уже обнаружено, и определите, какие хранилища затронуты.
Отслеживайте новые оповещения, созданные во время инцидента (которые могут указывать на активную эксплуатацию или распространение).

Требуются разрешения

Чтобы видеть данные для организаций на корпоративном уровне, корпоративный администратор должен выполнять роль владельца организации или менеджера по безопасности в соответствующих организациях.
Для просмотра данных репозиториев на уровне организации требуется роль владельца организации или менеджера по безопасности.

Ключевые ресурсы

Заметки и ограничения

Оповещения о утечках секретов, уязвимом коде, уязвимых зависимости и вредоносном ПО видны только если соответствующие функции были включены и настроены до инцидента.

Запуски рабочих процессов и логи

Использовать

Подтвердите, что было выполнено в CI/CD в данный момент времени (например, выполненные команды или установленную зависимость).
Проверьте подозрительные рабочие процессы, такие как те, что запускаются незнакомым пользователем или в необычное время, чтобы узнать, какие действия были выполнены, какие секреты были обнаружены и какой код был выполнен.
Проверьте, к каким учетным данным имела задача рабочего процесса, включая стандартные GITHUB_TOKEN, любые personal access tokens, GitHub App токены, другие учетные данные, хранящиеся в виде секретов, и токены доступа, полученные во время выполнения рабочего процесса.
Получайте логи программно через REST API для архивных, судебных или автоматизированных целей.

Требуются разрешения

Читать доступ к репозиторию.

Ключевые ресурсы

Заметки и ограничения

GitHub Автоматически редактирует секреты из журналов рабочих процессов.
По умолчанию журналы рабочих процессов сохраняются до GitHub 90 дней, но вы можете настроить этот период сохранения. Максимальный срок удержания — 400 дней. Удержание может быть настроено на уровне предприятия, организации или репозитория. Если запуск рабочего процесса произошёл вне вашего настроенного окна удержания, логи могут быть недоступны. Дополнительные сведения см. в разделе AUTOTITLE, [AUTOTITLE[ или Управление настройками GitHub Actions для репозитория](/organizations/managing-organization-settings/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-organization).](/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise)
Запуски рабочих процессов (включая их логи) также можно удалить через REST API. Чтобы проверить, был ли забег удалён, запросите события workflows.delete_workflow_run в журнале аудита.
Стандартный GITHUB_TOKEN срок, выдаваемый для каждой задачи, ограничен на эту задачу и истекает после завершения работы или после её максимального эффективного срока службы (до 24 часов на самостоятельных раннерах). Даже если шаг захватил жетон, его нельзя использовать повторно после завершения работы. Дополнительные сведения см. в разделе GITHUB_TOKEN.
Другие учетные данные, на которые ссылаются в рабочих процессах, такие personal access tokensкак установочные GitHub App токены или сторонние API-ключи, хранящиеся в виде секретов, имеют собственный жизненный цикл и не истекают после завершения задания. Если на этапе процесса один из этих учетных данных был открыт, токен остаётся действительным до момента аннулирования или истечения срока действия согласно собственной политике. Любые удостоверения, которые могли быть раскрыты, должны быть скомпрометированы и немедленно заменены или заменёны. Просматривайте файл рабочего процесса и секреты репозитория, организации и среды, чтобы определить, какие учетные данные были доступны. Дополнительные сведения см. в разделе Использование секретов в GitHub Actions.
Вы можете скачать логи для всего запущенного рабочего процесса или для конкретной задачи программно, используя REST API. Обе конечные точки возвращают URL перенаправления, который действителен в течение одной минуты. Дополнительные сведения см. в разделе [AUTOTITLE и Конечные точки REST API для выполнения рабочих процессов](/rest/actions/workflow-jobs).
Логи запуска рабочих процессов фиксируют только стандартный результат из шагов рабочего процесса. Активность, не записывающая в стандартный формат, такая как сетевые вызовы, модификации файловой системы или фоновые процессы, не отображается в журналах.
Для бегунов с GitHub-хостингом среда бегуна эфемерна и разрушается после завершения работы. GitHub не сохраняет никаких данных, выходящих за рамки журналов запуска рабочих процессов для этих раннеров. Для самостоятельных пользователей может быть доступна дополнительная телеметрия на уровне хоста или сети из вашей собственной инфраструктуры.
Для более комплексного исследования сопоставьте логи запущенных рабочих процессов с событиями аудита. События, такие как git.clone, git.fetch, git.push, protected_branch.create, и protected_branch.policy_override могут дать дополнительный контекст. Поскольку события Git в GitHub-hosted audit logs в настоящее время сохраняются для предприятий всего 7 дней, для такого рода расследования важно заранее настраивать потоковые журналы корпоративного аудита. Дополнительные сведения см. в разделе Подготовка к инциденту с безопасностью.

Инструменты расследования инцидентов с безопасностью

В этой статье