Реагирование на инцидент с безопасностью

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

Introduction

Это руководство проведёт вас, как реагировать на инцидент с безопасностью, описывает GitHub поверхности, которые можно использовать для проверки и расследования угрозы, а также инструменты для её сдерживания и устранения.

Необходимые условия

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

На протяжении всего вашего ответа

По мере прохождения ответа убедитесь, что вы:

• Сохраняйте улики: Делайте скриншоты подозрительной активности, экспортируйте журналы или результаты запросов, а также сохраняйте копии затронутых файлов или кода перед очисткой.
• Ведите запись: документируйте свои результаты (например, время, даты, индикаторы компромисса (IoC), затронутые репозитории) и фиксируйте каждое принятое решение.
• Общайтесь: уведомляйте соответствующих заинтересованных сторон (таких как руководители по безопасности и инженерные менеджеры, а также юридические и конфиденциальные команды, если конфиденциальные данные находятся под угрозой) и держите их в курсе.

Шаг 1: Оцените сигнал и быстро проверьте

Цель — быстро определить, является ли сигнал, который вы видите, реальной и активной угрозой.

1. Идентифицировать

Попробуйте определить характер сигнала, который вы видите. Например, показывает ли сигнал признаки:

• Компрометация данных (предупреждение о утечке секрета, сообщения о нахожденных учетных данных на внешнем сайте)
• Несанкционированный доступ или компрометация аккаунта (сообщения о подозрительных входах, незнакомых коммитах или изменениях)
• Эксфильтрация данных (сообщения о подозрительных изменениях или дополнениях файлов, неожиданных запусках рабочих процессов, необычной активности API, создании неизвестных репозиториев или неожиданных изменениях видимости репозитория)
• Вредоносная инъекция кода (сообщения о подозрительных изменениях кода, неожиданных запусках рабочих процессов, добавлении новых файлов)
• Атака на цепочку поставок (сообщения о подозрительных версиях посылок, оповещения о уязвимых зависимостях)

Для помощи в выявлении этих сигналов угрозы в вашей организации или предприятии обратитесь к AUTOTITLE.

Мы рекомендуем не тратить слишком много времени на глубокий анализ на ранних этапах расследования, так как первоначальная цель — определить сигнал угрозы, чтобы подтвердить его и выработать стратегию реагирования.

2. Валидировать

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

Следующие GitHub инструменты и поверхности могут помочь.

Инструмент / поверхность	Purpose
Обзор безопасности и оповещения о безопасности	Проверяйте оповещения о безопасности по всей вашей организации или предприятию
Журналы аудита	Ищите события, связанные с исследуемым сигналом, такие как создание токенов, изменения разрешений или изменения видимости репозитория
Вид активности	Просмотр таймлайна push-файлов, коммитов и активности ветвей для конкретного репозитория
[

          GitHub Поиск по коду](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | Ищите известные признаки компрометации, такие как конкретные имена файлов или шаблоны кода, между репозиториями |

| Граф зависимостей | Проверьте, зависят ли репозитории от конкретного пакета или версии пакета | | Запуски рабочих процессов и логи | Проверяйте историю выполнения рабочих процессов и проверяйте выходные данные журнала на предмет подозрительной активности |

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

Этап валидации может быть быстрым:

• Стремитесь собрать достаточно доказательств, чтобы определить, является ли сигнал реальной и активной угрозой.
• Если вы не можете быстро исключить сигнал как ложноположительный, предположите, что он настоящий.
• Глубокое расследование может быть проведено позже.

3. Решите

Основываясь на собранных данных, определите три момента:

1.        **Это реальная угроза?** Если вы не можете быстро и уверенно исключить сигнал как ложноположительный, воспринимайте его как реальный и приступайте к локализации.
   

2.        **Угроза всё ещё активна?** Если у злоумышленника, похоже, всё ещё есть доступ или активность продолжается, сначала приоритизируйте немедленные меры по сдерживанию. Если компромисс кажется историческим, вам всё равно нужно расследовать и исправить ситуацию, но у вас может быть больше времени на планирование ответа.
   

3.        **Каков потенциальный масштаб?** Подумайте, насколько далеко может зайти компромисс — один удостоверительный данные, репозиторий, организация или всё предприятие. Это поможет вам правильно масштабировать свой ответ.
   

Если сомневаетесь, воспринимайте угрозу как реальную и снижайте реакцию по мере того, насколько это позволяет доказательство.

Шаг 2: Сдерживайте угрозу

Следующий шаг предполагает, что вы имеете дело с реальной и активной угрозой. Цель сейчас — немедленно снизить текущий риск , используя то, что вы уже знаете.

Существует несколько действий по сдерживанию, которые можно выполнить, чтобы ограничить доступ и возможности злоумышленника.

Аннулировать скомпрометированные учетные данные

Для раскрытых или использованных учетных данных наиболее срочное решение — аннулировать затронутые учетные данные, чтобы предотвратить дальнейшее злоупотребление.

• Варианты аннулирования и сдерживания

  Существуют дополнительные варианты блокировки доступа к учетным данным. Полный список по типу учётных данных см. Ссылка на типы учетных данных GitHub.

• Экстренные действия (крупный инцидент)

  Владельцы GitHub Enterprise Cloud предприятий могут принимать массовые экстренные меры для блокировки доступа к своему бизнесу. Для предприятий с Enterprise Managed Users, это включает удаление всех пользовательских токенов и ключей. Это действия с высоким воздействием, которые могут нарушить автоматизацию и должны быть зарезервированы для крупных инцидентов. См . раздел AUTOTITLE.

Ограничение доступа

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

• Настройка IP-листов разрешений

  Блокируйте доступ к неизвестным или подозрительным IP-адресам в организации или предприятии. См. Ограничение сетевого трафика в вашей организации с помощью списка разрешений IP-адресов (администраторы предприятий) и Управление разрешенными IP-адресами для организации (владельцы организаций).

• Удалять скомпрометированных или подозрительных пользователей

  Удалите пользователя или заблокируйте аккаунт. См. Удаление участника из организации (владельцы организаций).

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

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

• Экстренные действия (крупный инцидент)

  Владельцы GitHub Enterprise Cloud предприятий могут принимать массовые экстренные меры для блокировки доступа к своему бизнесу. К ним относятся блокировка SSO для блокировки доступа не для владельцев и отзыв всех авторизаций пользовательских SSO между организациями. Это действия с высоким воздействием, которые могут нарушить автоматизацию и должны быть зарезервированы для крупных инцидентов. См . раздел AUTOTITLE.

Отключить вредоносные артефакты и активность

• Остановить вредоносные рабочие процессы

  Если вы подозреваете, что GitHub Actions рабочий процесс или раннер используется как часть активной атаки, вы можете предпринять следующие действия:

  • Отмена текущих рабочих процессов для затронутого репозитория. См . раздел AUTOTITLE.
  • Отключить GitHub Actions для затронутого репозитория в организации или для конкретной организации. См. Отключение или ограничение GitHub Actions для вашей организации (владельцы организаций) и Применение политик для GitHub Actions в вашем предприятии (корпоративные администраторы).
  • Удалите самостоятельных бегунов. См . раздел AUTOTITLE.

• Отключить вебхуки

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

• Удалить вредоносные ветки

  Если вы выявили ветки с вредоносным кодом или рабочими процессами, удалите их немедленно, чтобы предотвратить выполнение. См . раздел AUTOTITLE.

Шаг 3: Полностью расследуйте

После немедленного локализации цель теперь — понять весь масштаб и последствия инцидента, выявить все IoC и механизмы сохранения, а также собрать необходимые доказательства для сдерживания и полного устранения угрозы.

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

2. Рассмотрите различные области расследования , описанные в AUTOTITLE , чтобы помочь вам направить расследование.

   Не ограничивайте расследование одной линией. Многие атаки используют комбинацию методов, таких как установка вредоносных пакетов в сочетании с эксплуатацией учетных данных, инъекции файлов в рабочие процессы и извлечение данных. Убедитесь, что вы исследуете все возможные векторы атаки.

3.        **Документируйте** все известные на данный момент IoC, ища следы на всех поверхностях GitHub.
   

4.        **Проведите инвентаризацию** всех затронутых рабочих процессов, репозиториев и организаций, чтобы систематически зафиксировать масштаб инцидента.
   

   • Включите название репозитория, что было затронуто (код, секреты, рабочие процессы) и хронологию компрометации.
   • Создайте список всех затронутых аккаунтов и учетных данных. Обратите внимание, какие токени, SSH-ключи или другие учетные данные могли быть раскрыты или использованы неправильно.

5.        **Подтвердите** свою рабочую теорию с доказательствами.
   

   • Изучите собранные вами доказательства. Подтверждает ли это вашу первоначальную гипотезу?
   • Рассмотрите альтернативные объяснения. Может ли быть другая причина наблюдаемой активности?
   • Если ваша гипотеза опровергнута, сформулируйте новую гипотезу на основе доказательств и повторите этапы расследования по мере необходимости.

6. Если обнаружите новые IoC или доказательства продолжающейся активности, требующей немедленных действий, возвращайтесь к контролю.

Когда вы будете уверены в своём понимании произошедшего и коренной причине, задокументируйте свои выводы и приступайте к устранению.

Шаг 4: Устранение

Цель сейчас — устранить все следы компрометации, устранить коренную проблему и восстановить системы до безопасного состояния. Меры по устранению будут зависеть от того, с чем вы столкнулись, но некоторые хорошие практики следующие.

Ротация жетонов и секретов

Даже если вы не уверены, что удостоверение было скомпрометировано, меняйте его, если есть вероятность раскрытия.

• Генерируйте новые токены и секреты, чтобы заменить те, что были отозваны или могли быть раскрыты.
• Ротировать секреты GitHub , хранящиеся на уровнях хранилища, среды и организации.
• Обновите любые учетные данные во внешних системах, к которым могли получить доступ с использованием скомпрометированных токенов.
• Рассмотрите возможность включения политики истечения токена для стимулирования регулярной ротации в будущем. См . раздел AUTOTITLE.

Аудит механизмов сохранения

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

Это включает, но не ограничивается, проверкой таких вещей, как:

• Подозрительные или незнакомые рабочие процессы, которые могли быть добавлены или изменены.
• Новые вебхуки, указывающие на незнакомые домены.
• Новые самостоятельные бегуны.
• Модификации для самостоятельных бегунов.
• Недавно установленные GitHub Apps или OAuth app авторизации.
• Новые ключи для развертывания добавлены в репозитории.
• Новые бинарные файлы или исполняемые файлы.

Аудит и переустановка зависимостей

Скомпрометированные зависимости могут служить вектором атаки. Обязательно проведите полный аудит ваших зависимостей и переустановите их из надёжных источников.

• Проверяйте Dependabot оповещения на наличие уязвимых зависимостей и, где доступно, Dependabot malware alerts на вредоносные пакеты. (Dependabot malware alerts В настоящее время доступны для экосистемы NPM.) Чтобы изучить дополнительные рекомендации по вредоносному ПО, найдите type:malware и GitHub Advisory Database проверьте свой график зависимостей на совпадения.
• Закрепите зависимости на известные хорошие версии или зафиксируйте SHA и переустановите их из реестра пакетов.

Проверка исправления

Убедитесь, что ваши усилия по устранению были успешными.

• Проверьте code scanning уведомления, чтобы подтвердить, что уязвимости кода устранены, новых уязвимостей нет.
• Проверьте secret scanning уведомления, чтобы убедиться, что в хранилищах не осталось никаких секретов и что все оповещения разрешены.
• Продолжайте проверять и контролировать журналы аудита и другие релевантные поверхности в ближайшие дни и недели после инцидента.

Шаг 5. Документ

Тщательная документация необходима для оставшихся этапов и для будущего использования.

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

Шаг 6: Отражайте и затвердевайте

Цель сейчас — извлечь уроки из происшествия и усилить свою безопасность, чтобы предотвратить подобные инциденты.

1. Напишите краткое описание инцидента. Это должно включать хронологию событий от первого признака до разрешения, а также анализ коренных причин, принятых решений и полученных уроков.

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

3. Если у вас его ещё нет, убедитесь, что у вашей компании или команды есть план реагирования на инциденты с безопасностью up-to. Это должно включать определённые роли и обязанности, пути эскалации, протоколы связи, критерии классификации по тяжести и пошаговые процедуры реагирования на распространённые типы угроз. Copilot может помочь сформировать и доработать этот план с учётом ваших конкретных потребностей и ресурсов. Для дополнительной информации см. раздел «Что такое реагирование на инциденты».

Дальнейшие действия

• Если вы ещё не сделали этого, подумайте о усилении своей безопасности, чтобы снизить риск будущих инцидентов. См . раздел AUTOTITLE.