Рекомендации в этой статье ориентированы на владельцев предприятий, владельцев организаций, менеджеров по безопасности и команд безопасности. Однако для реализации некоторых функций, упомянутых в этой статье, вам потребуется роль владельца предприятия.
Introduction
Когда происходит инцидент с безопасностью, способность расследовать произошедшее, понять масштаб воздействия и сдерживать угрозу зависит от наличия правильных инструментов и процессов. В этой статье собраны ключевые действия, которые следует предпринять до инцидента, чтобы ваша команда была готова быстро и эффективно реагировать.
Заранее настройте критически важные инструменты
Следующие инструменты для расследования по умолчанию недоступны при создании вашего GitHub предприятия. Мы настоятельно рекомендуем включить эти функции до возникновения любого инцидента.
Эти меры имеют решающее значение для реагирования на инциденты, соблюдения требований и операционной прозрачности. Без них ваша команда может столкнуться с серьёзными пробелами в видимости во время расследования, особенно для активности API, Git и долгосрочных инцидентов, где нужны исторические данные.
Потоковая запись журнала аудита
Вы должны передавать журналы аудита предприятия, включая события запроса API, в систему управления сведениями и событиями безопасности (SIEM). Это сохраняет копию данных журнала аудита (включая веб-события, события Git и API) в системе, где можно выполнять сложные запросы в больших объемах данных и хранить данные за пределами периодов хранения по умолчанию.
Внимание
Потоковая передача журнала аудита включает только действие с момента его включения. Включение этого параметра во время инцидента не восстановит более ранние действия.
Это критически важно в случае инцидента, потому что некоторые важные события не видны в веб-интерфейсе GitHub журнала аудита, а логи доступны только ограниченное время, если вы не экспортируете и сохраняете их снаружи.
С помощью потоковых логов владельцы предприятий и организаций могут самостоятельно исследовать активность пользователей, приложений, токенов и SSH-ключей, вместо того чтобы полагаться на случайный сбор данных во время активного ответа.
Чтобы настроить потоковую трансляцию журнала аудита, см. AUTOTITLE.
События запросов потока API
По умолчанию поток журналов аудита не будет включать события запроса API. Включите трансляцию API-запросов, чтобы вы могли обнаруживать и расследовать несанкционированный доступ API или фильтрацию данных скомпрометированными токенами или приложениями.
См. раздел «Включение потокового потока аудитских журналов запросов API».
IP-адреса отображения
По умолчанию GitHub IP-адреса исходника не отображаются в журнале аудита предприятия. Во время расследования исходные IP-адреса помогают проверить, исходила ли активность от актора (пользователя или приложения) с доверенного или незнакомого адреса.
Предприятия могут GitHub Enterprise Cloud включить раскрытие IP-адресов, см. Отображение IP-адресов в журнале аудита для предприятия.
Сохранение логов идентификаторов провайдера
Если ваше предприятие или организации используют проверку подлинности SAML или OIDC, используйте аналогичную стратегию хранения журналов поставщика удостоверений (IdP).
Сохраненные журналы поставщика удостоверений помогают исследовать действия проверки подлинности и просматривать подготовку, отмену подготовки и изменение членства в группах с течением длительного времени. Это особенно важно, если вы используете подготовку SCIM или требуется исследовать действия с нескольких месяцев назад.
Ознакомьтесь с инструментами, ограничениями и общими областями расследования
Перед инцидентом изучите GitHub инструменты и поверхности, которые можно использовать в ходе расследования, и поймите возможности и ограничения каждого инструмента.
Ознакомьтесь с:
- GitHub инструменты и поверхности для расследования, включая их ограничения. См . раздел AUTOTITLE.
- Ключевые процедуры использования журнала аудита при угрозе безопасности, такие как Определение событий журнала аудита, выполняемых маркером доступа.
- Общие зоны расследования и проверки на конкретные сигналы угрозы. См . раздел AUTOTITLE.
Ознакомьтесь со стратегиями сдерживания
Перед инцидентом ознакомьтесь с немедленными мерами по сдерживанию, которые могут потребоваться. Заранее планирование этих действий с командами безопасности и операций помогает быстро реагировать и позволяет включить чёткие рекомендации в ваш план реагирования на инциденты с безопасностью (SIRP).
Ознакомьтесь с:
- Распространённые действия по сдерживанию GitHub, такие как аннулирование учетных данных, включение списка разрешений IP, приостановка пользователей и другие действия по отключению доступа. См. Сдерживать угрозу.
- Варианты отзыва для каждого типа учетных данных, которые могут программно получить GitHubдоступ к . См . раздел AUTOTITLE.
- Для предприятий по GitHub Enterprise Cloud: массовых экстренных действий, доступных владельцам предприятий в случае крупного инцидента, таких как блокировка SSO и удаление всех пользовательских токенов и ключей. См . раздел AUTOTITLE.
Подготовьте план реагирования на инциденты с безопасностью (SIRP)
Создайте и поддерживайте План реагирования на инциденты безопасности (SIRP) на up-toсроки для вашего предприятия.
Ваш план должен быть определен:
- Роли и обязанности
- Пути эскалации
- Протоколы связи
- Критерии классификации по тяжести
- Пошаговые процедуры реагирования на распространённые типы угроз
Copilot может помочь вам составить и доработать этот план с учётом потребностей и ресурсов вашей команды.
Для рекомендаций см. Что такое реагирование на инциденты.