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

Применяется к рекомендации по безопасности Azure Well-Architected Framework:

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

Большинство предприятий имеют центральную группу операций безопасности (также известную как Центр операций безопасности (SOC) или SecOps. Ответственность группы по обеспечению безопасности заключается в быстром обнаружении, приоритете и выполнении потенциальных атак. Команда также отслеживает данные телеметрии, связанные с безопасностью, и изучает нарушения безопасности.

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

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

Определения

Основные стратегии проектирования

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

Назначение контактов уведомления об инцидентах

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

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

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

Исследование с помощью команды триажа

Участник группы, получающий уведомление об инциденте, отвечает за настройку процесса сортировки, включающего соответствующих людей на основе доступных данных. Команда триажа, часто называемая командой моста, должна согласиться на режим и процесс коммуникации. Требует ли этот инцидент асинхронных обсуждений или вызовов моста? Как команда отслеживает и сообщает ход расследования? Где команда может получить доступ к ресурсам инцидентов?

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

Для дальнейшего расследования необходимо привлечь соответствующих людей. Вы можете включить руководителя инцидентов, сотрудника по безопасности или потенциальных клиентов, ориентированных на рабочую нагрузку. Чтобы сохранить фокус, исключите людей, которые находятся вне области проблемы. Иногда отдельные команды расследуют инцидент. Может быть группа, которая первоначально расследует проблему и пытается устранить инцидент, и другая специализированная группа, которая может выполнять судебно-медицинские экспертизы для глубокого расследования, чтобы определить широкие проблемы. Вы можете поместить в карантин среду рабочей нагрузки, чтобы позволить группе судебно-медицинских экспертов выполнять свои расследования. В некоторых случаях одна и та же команда может обрабатывать все расследование.

На начальном этапе команда триажа отвечает за определение потенциального вектора и его влияние на конфиденциальность, целостность и доступность (также называемое ЦРУ) системы.

В категориях ЦРУ назначьте начальный уровень серьезности, указывающий глубину ущерба и срочность исправления. Этот уровень, как ожидается, изменится с течением времени, так как дополнительные сведения обнаруживаются на уровнях триажа.

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

Если вы решите завершить работу системы, следующие шаги приводят к процессу аварийного восстановления рабочей нагрузки (DR).

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

Восстановление после инцидента

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

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

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

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

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

Узнайте об инциденте

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

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

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

Проводите проверки после инцидента или посмертные проверки, чтобы выявить слабые места в процессе реагирования и областях для улучшения. На основе уроков, извлеченных из инцидента, обновите план реагирования на инциденты (IRP) и элементы управления безопасностью.

Определение плана коммуникации

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

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

Упрощение функций Azure

Microsoft Sentinel — это решение SIEM и SOAR. Это единое решение для обнаружения оповещений, отображения угроз, упреждающей охоты и реагирования на угрозы. Дополнительные сведения см. в статье "Что такое Microsoft Sentinel?"

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

Дополнительные сведения о создании указанной точки контакта, получающей уведомления об инцидентах Azure из Microsoft Defender для облака, см. в статье "Настройка Уведомления по электронной почте для оповещений системы безопасности".

Соответствие структуре организации

Cloud Adoption Framework для Azure предоставляет рекомендации по планированию реагирования на инциденты и операциям безопасности. Дополнительные сведения см. в разделе "Операции безопасности".

Дополнительные ссылки

• Автоматическое создание инцидентов из оповещений системы безопасности Майкрософт
• Проведение комплексной охоты на угрозы с помощью функции охоты
• Настройка Уведомления по электронной почте для оповещений системы безопасности
• Обзор реагирования на инциденты
• Готовность к инциденту Microsoft Azure
• Навигация и исследование инцидентов в Microsoft Sentinel
• Управление безопасностью: реагирование на инциденты
• Решения SOAR в Microsoft Sentinel
• Учебный курс. Общие сведения о готовности к инцидентам Azure
• Обновление параметров уведомлений портал Azure
• Что такое SOC?
• Что такое Microsoft Sentinel?

Контрольный список по безопасности

Ознакомьтесь с полным набором рекомендаций.