D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Автор: NomadSP
Источник: XSS.is
Понятие "Incident".
Инцидентом считается любое событие, которое влечёт за собой полную недоступность критической сервиса корпоративной инфраструктуры. Обычно классификация выглядит следующим образом:
- External Incident(например, хакерская атака).
- Internal Incident(внутренняя проблема технического характера).
- Non-Tech Incident(ошибка на основании человеческого фактора).
Команда SOAR.
Создание команды "ГБР" является важным, а иногда и ключевым фактором в обеспечении безопасности организации, так как во многом влияет организация процесса и коммуникация между различными отделами, ответственными за Incident Management.
Если мы говорим о конкретных специализациях, то команда выглядит следующим образом:
1. Lead.
Ответственный за принятия решений и координацию действий. На практике это представитель C-level(CTO, CSO, CCO etc.)
2. InfoSec.
Представители команды информационной безопасности необходимы для анализа вектора атак, оценки угроз, мер противодействия.
3. IT.
Я обобщил данный сектор, так как ответственные вызываются, в зависимости от сервиса, следовательно за недоступность функционала сайта будет вызван Frontend Dev, либо могут быть задействованы несколько различных отделов разработки.
4. PR / Customer Support.
Репутация нарабатывается временем, а теряется по щелчку пальцев. При длительной недоступности каких-то функций, которыми пользуются тысячи или миллионы пользователей, ваш имидж страдает в первую очередь, поэтому необходимо своевременно комментировать ваши неполадки и взаимодействовать с клиентами.
5. DevOps.
Так как core system чаще всего является сферой влияния именно данного отдела, то их присутствие будет определенно преимуществом.
При этом недостаточно просто иметь готовую команду, так же необходимы планирование, адаптация и практика. К чему мы скоро и перейдём.
Разработка плана и процедур реагирования.
Эффективный план реагирования имеет чёткую структуру:
1. Описание целей и задач плана.
2. Перечисление ответственных лиц.
3. Описание инцидентов.
4. Сценарии инцидентов.
5. Процедуры для сценариев реагирования.
Сам план реагирования крайне удобно визуализировать, например, блок-схемами в XMind. Вы будете чётко понимать саму процедуру в каждом случае применения.
В вашем IMP(Incident Management Plan) так же важно охватить такую тему как "определение уровней риска", так как обычно от этого зависит само понятие инцидента.
Для простоты привожу формулу расчёта:
Вероятность — исходя из всех имеющихся данных, практическая вероятность частного случая.
Воздействие — какое воздействие данный случай имеет на вашу инфраструктуру.
Классификация рисков по уровням:
- Низкий
- Средний
- Высокий
Данный вывод поможет определить что именно является полной недоступностью или критическим сервисом, а так же основанием для запуска процедуры реагирования на инциденты.
Практические командные тесты.(Стратегии).
Я затрагивал тему аудита систем безопасности и реагирования на инциденты для определения наиболее подходящих инструментов, в своих предыдущих статьях.
На практике мною было выделено, что самый лучший аудит проводится практическим методом. Поэтому ниже привожу несколько сценариев для тестирования:
1. Симуляция инцидента. (R/B Team).
Команда 1 создаёт инцидент с помощью внутренних или внешних инструментов. Необходимо создать триггер для своевременной реакции со стороны ответственных(Команда 2), согласно IMP.
Например:
1. Создаётся имитация.
- Потери соединения:
Пример:
Bash: Скопировать в буфер обмена
- Повышенной нагрузки:
Пример:
Bash: Скопировать в буфер обмена
- Повышенного лага сети:
Пример:
Bash: Скопировать в буфер обмена
- Отключение конкретного Product Service.
Пример: Payment system.
2. Происходит оповещение команды 2.
3. Происходит тест процедур IMP.
Выводы: Координация процесса, скорость реагирования, возможное противодействие, скорость исправления.
2. Тренировка на основе сценариев.
Составленные заранее вов ремя планирования сценарии необходимо так же тестировать.
Например:
Составлен сценарий противодействия DDoS атаке.
Команде необходимо отточить полностью процедуру, которая будет включать в себя такие этапы как:
1. Обнаружение ициндента с помощью мониторинговых систем.
2. Оценка и анализ ситуации ответственной 1-й линией.
3. Уведомление SOAR.
4. Сбор кейсов и доказательств.
5. Реакция и противодействие Incident Management Team.
6. Постинциндентый анализ.
Выводы: Опрелеление эффективности частных сценариев, доработка процедур, определение необходимых мониторинговых систем.
3. Ротация ролей.
Для понимания зоны ответственности и специфики смежных по специализации ролей, в Incident Management Team возможно проводить ротацию для создание более полноценной картины.
Например:
PR <-> Customer Support.
Предоставление возможности отделу PR взаимодействовать со входящими обращениями клиентов через каналы связи, а Customer Support составлению плана исключения или смягчения репутационных рисков.
Выводы: Более дополненное представление сотрудников о реагировании на инциденты.
Выводы из тестов.
Проведя все тесты, мы получаем тонны данных для анализа, а следовательно дальнейших вариаций противодействия атаке на инфраструктуру. Это позволит вам составлять более чёткие процессы и процедуры реагирования, оптимизировать свои SIEM-системы или же дополнять арсенал инструментов.
Однако, я бы хотел вознаградить постоянных читателей небольшим бонусом. Самое первое, что влияет на скорость реакции это дашборды, которые в режиме реального времени могут показывать аномальные изменения поведения ваших систем. Первые в голову приходят такие инструменты как Grafana, Kibana(в сочетании с Elastic search), Prometheus и NetData. Поэтому мы создадим бесплатно простой дашборд с помощью 2-х инструментов - Grafana + Prometheus для логгирования событий безопасности и визуализации:
Шаг 1. Устанавливаем инструменты.
- Prometheus отвечает за сбор данных и хранения метрик.
- Grafana отвечает за визуализацию данных.
Bash: Скопировать в буфер обмена
Шаг 2. Настроим Prometheus.
Создаём конфигурационный файл prometheus.yml и вставляем следующее:
YAML: Скопировать в буфер обмена
Сохраняем.
Шаг 3. Запуск Prometheus.
Bash: Скопировать в буфер обмена
Шаг 4. Сбор данных.
Для сбора данных будем использовать auditd, чтобы отслеживать, например, событие входа в систему.
Устанавливаем auditd:
Bash: Скопировать в буфер обмена
Шаг 5. Настраиваем правила аудита.
Откроем файл по пути etc/audit/audit.rules и добавим правило:
Bash: Скопировать в буфер обмена
Шаг 6. Перезапускаем auditd.
Bash: Скопировать в буфер обмена
Шаг 7. Настроим экспорт метрик.
Для этого используем node_exporter, устанавливаем:
Bash: Скопировать в буфер обмена
Шаг 8. Добавляем в конфигурацию Prometheus.
Снова открываем файл prometheus.yml и добавляем:
YAML: Скопировать в буфер обмена
Шаг 7. Запустим Grafana.
Bash: Скопировать в буфер обмена
Шаг 8. Переходим в веб-интерфейс Grafana.
Обычно интерфейс доступен по адресу http://localhost:3000.
Шаг 9. Входим в Grafana.
- Входим с помощью стандартных admin/admin.
- Добавляем источник данных.
"Configurations" -> "Data Sources".
- Выбираем Prometheus и указываем URL.
Шаг 10. Создаём дашборд.
1. Перейдите в "Dashboards" > "New Dashboard".
2. Добавьте панели для отображения метрик безопасности:
- Количество неудачных попыток входа: используйте запросы к логам auth.log.
- Активные пользователи: количество активных сессий.
- События аудита: количество событий, зарегистрированных auditd.
Пример запроса для неудачных попыток входа:
Код: Скопировать в буфер обмена
Шаг 11. Добавляем визуализацию.
Настройте графики и таблицы, которые хотелось бы отслеживать, в зависимости от ваших требований.
Если кто-то держит в уме Part 1, то заодно скажу, что Grafana отлично сочетается так же и с honeypot ловушками от Cowrie, которые так же можно взаимосвязать.
Данные из Cowrie обычно хранятся в базе данных SQLite, но так же есть формат JSON.
Поэтому, чтобы интегрировать Cowrie с Grafana, нам необходимо экспортировать логи в систему мониторинга - Prometheus.
Правда для этого нам понадобится Exporter для Cowrie.
https://github.com/marvinpinto/cowrie-exporte, либо же написать свой скрипт на Python.
Шаг 1. Установим репозиторий.
Bash: Скопировать в буфер обмена
Шаг 2. Установите зависимости.
Bash: Скопировать в буфер обмена
Шаг 3. Настройка Exporter.
Откройте файл cowrie_exporter.py и измените параметры подключения к вашему экземпляру Cowrie (например, путь к логам или API, если используется).
Шаг 4. Запускаем Exporter.
Bash: Скопировать в буфер обмена
Не забываем убедиться в правильном пути к логам Cowrie.
Шаг 5. Изменить файл конфигурации Prometheus(prometheus.yml).
Например:
YAML: Скопировать в буфер обмена
Дальше мы запускаем Prometheus и повторяем процедуру с настройкой дашбордов в веб-интефейсе Grafana.
В дальнейшем можно улучшать, модернизировать и добавлять сервисы, которые вы захотите мониторить. Мой опыт подсказывает, что необходимо отслеживать всё, что вы считаете критичным и лучше иметь, но не нуждаться, чем нуждаться, но не иметь.
В этой части я буду заканчивать. Скоро увидимся!
Источник: XSS.is
Понятие "Incident".
Инцидентом считается любое событие, которое влечёт за собой полную недоступность критической сервиса корпоративной инфраструктуры. Обычно классификация выглядит следующим образом:
- External Incident(например, хакерская атака).
- Internal Incident(внутренняя проблема технического характера).
- Non-Tech Incident(ошибка на основании человеческого фактора).
Команда SOAR.
Создание команды "ГБР" является важным, а иногда и ключевым фактором в обеспечении безопасности организации, так как во многом влияет организация процесса и коммуникация между различными отделами, ответственными за Incident Management.
Если мы говорим о конкретных специализациях, то команда выглядит следующим образом:
1. Lead.
Ответственный за принятия решений и координацию действий. На практике это представитель C-level(CTO, CSO, CCO etc.)
2. InfoSec.
Представители команды информационной безопасности необходимы для анализа вектора атак, оценки угроз, мер противодействия.
3. IT.
Я обобщил данный сектор, так как ответственные вызываются, в зависимости от сервиса, следовательно за недоступность функционала сайта будет вызван Frontend Dev, либо могут быть задействованы несколько различных отделов разработки.
4. PR / Customer Support.
Репутация нарабатывается временем, а теряется по щелчку пальцев. При длительной недоступности каких-то функций, которыми пользуются тысячи или миллионы пользователей, ваш имидж страдает в первую очередь, поэтому необходимо своевременно комментировать ваши неполадки и взаимодействовать с клиентами.
5. DevOps.
Так как core system чаще всего является сферой влияния именно данного отдела, то их присутствие будет определенно преимуществом.
При этом недостаточно просто иметь готовую команду, так же необходимы планирование, адаптация и практика. К чему мы скоро и перейдём.
Разработка плана и процедур реагирования.
Эффективный план реагирования имеет чёткую структуру:
1. Описание целей и задач плана.
2. Перечисление ответственных лиц.
3. Описание инцидентов.
4. Сценарии инцидентов.
5. Процедуры для сценариев реагирования.
Сам план реагирования крайне удобно визуализировать, например, блок-схемами в XMind. Вы будете чётко понимать саму процедуру в каждом случае применения.
В вашем IMP(Incident Management Plan) так же важно охватить такую тему как "определение уровней риска", так как обычно от этого зависит само понятие инцидента.
Для простоты привожу формулу расчёта:
Вероятность — исходя из всех имеющихся данных, практическая вероятность частного случая.
Воздействие — какое воздействие данный случай имеет на вашу инфраструктуру.
Классификация рисков по уровням:
- Низкий
- Средний
- Высокий
Данный вывод поможет определить что именно является полной недоступностью или критическим сервисом, а так же основанием для запуска процедуры реагирования на инциденты.
Практические командные тесты.(Стратегии).
Я затрагивал тему аудита систем безопасности и реагирования на инциденты для определения наиболее подходящих инструментов, в своих предыдущих статьях.
На практике мною было выделено, что самый лучший аудит проводится практическим методом. Поэтому ниже привожу несколько сценариев для тестирования:
1. Симуляция инцидента. (R/B Team).
Команда 1 создаёт инцидент с помощью внутренних или внешних инструментов. Необходимо создать триггер для своевременной реакции со стороны ответственных(Команда 2), согласно IMP.
Например:
1. Создаётся имитация.
- Потери соединения:
Пример:
Bash: Скопировать в буфер обмена
sudo ip link set eth0 down- Повышенной нагрузки:
Пример:
Bash: Скопировать в буфер обмена
Код:
sudo apt-get install stress
stress --cpu 8 --timeout 60- Повышенного лага сети:
Пример:
Bash: Скопировать в буфер обмена
sudo tc qdisc add dev eth0 root netem delay 100ms- Отключение конкретного Product Service.
Пример: Payment system.
2. Происходит оповещение команды 2.
3. Происходит тест процедур IMP.
Выводы: Координация процесса, скорость реагирования, возможное противодействие, скорость исправления.
2. Тренировка на основе сценариев.
Составленные заранее вов ремя планирования сценарии необходимо так же тестировать.
Например:
Составлен сценарий противодействия DDoS атаке.
Команде необходимо отточить полностью процедуру, которая будет включать в себя такие этапы как:
1. Обнаружение ициндента с помощью мониторинговых систем.
2. Оценка и анализ ситуации ответственной 1-й линией.
3. Уведомление SOAR.
4. Сбор кейсов и доказательств.
5. Реакция и противодействие Incident Management Team.
6. Постинциндентый анализ.
Выводы: Опрелеление эффективности частных сценариев, доработка процедур, определение необходимых мониторинговых систем.
3. Ротация ролей.
Для понимания зоны ответственности и специфики смежных по специализации ролей, в Incident Management Team возможно проводить ротацию для создание более полноценной картины.
Например:
PR <-> Customer Support.
Предоставление возможности отделу PR взаимодействовать со входящими обращениями клиентов через каналы связи, а Customer Support составлению плана исключения или смягчения репутационных рисков.
Выводы: Более дополненное представление сотрудников о реагировании на инциденты.
Выводы из тестов.
Проведя все тесты, мы получаем тонны данных для анализа, а следовательно дальнейших вариаций противодействия атаке на инфраструктуру. Это позволит вам составлять более чёткие процессы и процедуры реагирования, оптимизировать свои SIEM-системы или же дополнять арсенал инструментов.
Однако, я бы хотел вознаградить постоянных читателей небольшим бонусом. Самое первое, что влияет на скорость реакции это дашборды, которые в режиме реального времени могут показывать аномальные изменения поведения ваших систем. Первые в голову приходят такие инструменты как Grafana, Kibana(в сочетании с Elastic search), Prometheus и NetData. Поэтому мы создадим бесплатно простой дашборд с помощью 2-х инструментов - Grafana + Prometheus для логгирования событий безопасности и визуализации:
Шаг 1. Устанавливаем инструменты.
- Prometheus отвечает за сбор данных и хранения метрик.
- Grafana отвечает за визуализацию данных.
Bash: Скопировать в буфер обмена
Код:
# Установка Prometheus
sudo apt-get update
sudo apt-get install prometheus
# Установка Grafana
sudo apt-get install grafanaШаг 2. Настроим Prometheus.
Создаём конфигурационный файл prometheus.yml и вставляем следующее:
YAML: Скопировать в буфер обмена
Код:
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'linux_metrics'
static_configs:
- targets: ['localhost:9090'] # Укажите адрес вашего сервераСохраняем.
Шаг 3. Запуск Prometheus.
Bash: Скопировать в буфер обмена
prometheus --config.file=prometheus.ymlШаг 4. Сбор данных.
Для сбора данных будем использовать auditd, чтобы отслеживать, например, событие входа в систему.
Устанавливаем auditd:
Bash: Скопировать в буфер обмена
sudo apt-get install auditdШаг 5. Настраиваем правила аудита.
Откроем файл по пути etc/audit/audit.rules и добавим правило:
Bash: Скопировать в буфер обмена
-w /var/log/auth.log -p wa -k auth_logШаг 6. Перезапускаем auditd.
Bash: Скопировать в буфер обмена
sudo service auditd restartШаг 7. Настроим экспорт метрик.
Для этого используем node_exporter, устанавливаем:
Bash: Скопировать в буфер обмена
Код:
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-<version>.linux-amd64.tar.gz
tar xvfz node_exporter-<version>.linux-amd64.tar.gz
cd node_exporter-<version>.linux-amd64
./node_exporter &Шаг 8. Добавляем в конфигурацию Prometheus.
Снова открываем файл prometheus.yml и добавляем:
YAML: Скопировать в буфер обмена
Код:
- job_name: 'node_exporter'
static_configs:
- targets: ['localhost:9100']Шаг 7. Запустим Grafana.
Bash: Скопировать в буфер обмена
sudo service grafana-server startШаг 8. Переходим в веб-интерфейс Grafana.
Обычно интерфейс доступен по адресу http://localhost:3000.
Шаг 9. Входим в Grafana.
- Входим с помощью стандартных admin/admin.
- Добавляем источник данных.
"Configurations" -> "Data Sources".
- Выбираем Prometheus и указываем URL.
Шаг 10. Создаём дашборд.
1. Перейдите в "Dashboards" > "New Dashboard".
2. Добавьте панели для отображения метрик безопасности:
- Количество неудачных попыток входа: используйте запросы к логам auth.log.
- Активные пользователи: количество активных сессий.
- События аудита: количество событий, зарегистрированных auditd.
Пример запроса для неудачных попыток входа:
Код: Скопировать в буфер обмена
sum(rate(auditd_events_total{event_type="failed_login"}[5m]))Шаг 11. Добавляем визуализацию.
Настройте графики и таблицы, которые хотелось бы отслеживать, в зависимости от ваших требований.
Если кто-то держит в уме Part 1, то заодно скажу, что Grafana отлично сочетается так же и с honeypot ловушками от Cowrie, которые так же можно взаимосвязать.
Данные из Cowrie обычно хранятся в базе данных SQLite, но так же есть формат JSON.
Поэтому, чтобы интегрировать Cowrie с Grafana, нам необходимо экспортировать логи в систему мониторинга - Prometheus.
Правда для этого нам понадобится Exporter для Cowrie.
https://github.com/marvinpinto/cowrie-exporte, либо же написать свой скрипт на Python.
Шаг 1. Установим репозиторий.
Bash: Скопировать в буфер обмена
Код:
git clone https://github.com/marvinpinto/cowrie-exporter.git
cd cowrie-exporterШаг 2. Установите зависимости.
Bash: Скопировать в буфер обмена
pip install prometheus_client requestsШаг 3. Настройка Exporter.
Откройте файл cowrie_exporter.py и измените параметры подключения к вашему экземпляру Cowrie (например, путь к логам или API, если используется).
Шаг 4. Запускаем Exporter.
Bash: Скопировать в буфер обмена
python cowrie_exporter.py --cowrie-log-dir /path/to/cowrie/logs --port 8080Не забываем убедиться в правильном пути к логам Cowrie.
Шаг 5. Изменить файл конфигурации Prometheus(prometheus.yml).
Например:
YAML: Скопировать в буфер обмена
Код:
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'cowrie'
static_configs:
- targets: ['localhost:8080'] # Порт, на котором работает ваш exporterДальше мы запускаем Prometheus и повторяем процедуру с настройкой дашбордов в веб-интефейсе Grafana.
В дальнейшем можно улучшать, модернизировать и добавлять сервисы, которые вы захотите мониторить. Мой опыт подсказывает, что необходимо отслеживать всё, что вы считаете критичным и лучше иметь, но не нуждаться, чем нуждаться, но не иметь.
В этой части я буду заканчивать. Скоро увидимся!