JSOC Inside

50
JSOC Inside Команда JSOC

Transcript of JSOC Inside

JSOC Inside

Команда JSOC

JSOC – СХЕМА РАЗБОРА ИНЦИДЕНТА

Выявление инцидента,Первоначальная классификация,Первоначальная приоритезация

Назначение исполнителя из 1-ой линии

Анализ инцидента,Протоколирование исследования

Необходима эскалация по экспертизе?

Передача инцидента 2-ой линии/аналитику

ДА

НЕТ

False Positive? Закрытие как FP

Информирование Заказчика, предоставление информации по инциденту и требуемых отчетов

Нужна дополнительная информация?

Закрытие задачи

НЕТ

Необходима эскалация по критичности?

Уведомление Заказчика и аналитика, формирование группы разбора инцидента

ДА

НЕТ

ДА

ДА

НЕТ

Администрируем ли СЗИ? ДА

ДА

Передача задачи по устранению группе администрирования

SOC ВНУТРИ – 1-Я ЛИНИЯ

• Понимает основы безопасности

• Разбирается в исходных событиях с систем

• Владеет всеми инструментами расследования в SOC

• Работает по инструкции, но не ограничивается ей

• Пытается восстановить произошедшее в реальном мире

ПРОГРАММА ОБУЧЕНИЯ СОТРУДНИКА

1. Основы информационной безопасности:– Что такое информационная безопасность в принципе

– Регулирующие документы в области информационной безопасности

– Инцидент информационной безопасности: определение, отличие от ИТ-инцидента, принципы определения критичности

– Драйверы информационной безопасности коммерческого сектора: регуляторы, политики, внешние угрозы, экономическая безопасность, репутационные риски

– Киберпреступность: основные векторы атаки, пути компрометации,

– Классификация инцидентов JSOC: с чем связан инцидент, какие последствия влечет, какая информация важна для расследования

2. Работа с аудитом ключевых инфраструктурных сервисов:– Active Directory – события аутентификации

– Active Directory – прочие события

– События аутентификации на прочих системах

– Аудит ОС Windows

– Аудит ОС Linux

– Аудит СУБД (sql запросы, синтаксис, основы обработки и значения команд)

– Аудит сетевого оборудования

– Аудит межсетевых экранов

– Антивирусы и прочее host-based ПО (принципы работы, ключевые события)

ПРОГРАММА ОБУЧЕНИЯ СОТРУДНИКА

3. События со СЗИ:

– Антивирусы (типы вирусов, особенности поведения, критерии обнаружения)

– Сетевые атаки (классификация, основные параметры)

– DDOS-атаки (принципы работы, типы, ключевые способы обнаружения)

– Атаки на веб-приложения (принципы, типы, ключевые способы обнаружения)

4. Инструментарий JSOC:

– Основные инструменты ArcSight для расследования инцидента

– Внешние способы обработки информации, источники знаний

– Разбор 3-4 ключевых инцидентов в рамках совместной работы

5. Самостоятельный анализ информации, выполнение лабораторных

6. Выпускной экзамен по освоению материала

SLA

Параметры сервиса Базовый Расширенный Премиум

Время обслуживания 8*5 24*7 24*7

Время

обнаружения

инцидента (мин)

Критичные инциденты 15-30 10-20 5-10

Прочие инциденты до 60 до 60 до 45

Время базовой

диагностики и

информирования

заказчика (мин)

Критичные инциденты 45 30 20

Прочие инциденты до 120 до 120 до 90

Время выдачи

рекомендаций по

противодействию

Критичные инциденты до 2 ч до 1,5 ч до 45 мин

Прочие инциденты до 8 ч до 6 ч до 4 ч

О ЧЕМ ПОЙДЕТ РЕЧЬ

• Проблемы эксплуатации SIEM и их решение

• Как устроены сценарии по обнаружению инцидентов

• Как устроена работа инженеров с возникающими событиями

ПРОБЛЕМА 1 – ОДИН СЦЕНАРИЙ ДЛЯ РАЗЛИЧНЫХ ИСТОЧНИКОВ

• Логика инцидентов одинакова – brute-force всегда brute-force

• В каждом приложении (AD, Unix OS, Cisco VPN, Siebel, Web-приложение) – свои логи и своя информация.

• Добавить новое приложение – пара правил + списки с исключениями и профилированием активности

• В итоге:• Сложность диагностики• Риск ошибки при реализации• Увеличение нагрузки на систему

ПРОБЛЕМА 2 - ОБЪЕДИНЕНИЕ ДАННЫХ

• Сценарий – 10 срабатываний сигнатур IPS с одного источника

• В случае 50 срабатываний (идет сканирование):• 40 различных событий• 40 сообщений в почту• С трудом можно сопоставить данные в одну сущность

• При этом – потенциально это одна и та же активность

ПРИМЕР – ВНЕШНИЕ ПОДКЛЮЧЕНИЯ С TOR-СЕТИ

Менее чем за час – 6 событий об одном и том же сканировании

«ПРОБЛЕМА 3»ПРАВИЛА ЖИЗНИ СЕРВИС-ПРОВАЙДЕРА

1. Три уровня SLA. • По каждому свое время реакции в зависимости от критичности инцидента

• У каждого заказчика свой SLA

• У каждого заказчика разное видение критичности инцидента

2. Визуализация и прозрачность работы с инцидентами.• Операторам должны быть доступны уже обработанные события.

• Операторы не должны «выбирать» инциденты.

3. Мы не должны «терять» инциденты. • Критичный инцидент должен быть рассмотрен вовремя. Вне зависимости от того, что до него пришло

10 не критичных инцидентов

• Критичности инцидентов – это не приоритет их расследования

4. Удобство работы и масштабируемость• Добавление нового правила не должно влиять на сервис

• Масштабирование правила на новый источник не должно влиять на сервис

• Инженер не должен искать в инструкциях время реакции, критичности, телефоны и e-mail заказчика

JSOC - WORKFLOW

• Проблемы эксплуатации SIEM и их решение

• Как устроены сценарии по обнаружению инцидентов

• Как устроена работа инженеров с возникающими событиями

JSOC – АРХИТЕКТУРА КОРРЕЛЯЦИОННЫХ ПРАВИЛ

Workflow

Сценарии

«Базовые» и

«Профилирующие» правила

Переработанные парсеры для коннекторов

• Оповещения, создание кейсов, обработка информации

• Необходимые отчеты и инструментыдля анализа инцидентов

• Генерация событий по соответствующим критериям

• «Обогащение» информации

• Очистка «мусора»• Добавление нашей категоризации• Профилирование активностей• Добавление «пропущенной»

информации

• Исправление проблем с парсингом

ПРИМЕРЫ СЦЕНАРИЕВ

Базовые сценарии (косвенные признаки) Потенциальный инцидент

Входящее письмо от неизвестного отправителя

Почти 100% заражение хостаВероятный целенаправленный взлом хоста

Запуск нелегитимного ПО (процесса) на рабочей станции

Исходящая активность Remote Access Tools\TOR\Feeds

Создание локального администратора на системе

Модификация реестра по снятию ограничений RDP на хосте

Большое кол-во неуспешных подключений во внешнюю сеть

Вероятные ботнеты\неизвестные вирусыДоступ в интернет к известным опасным хостам (Feeds) \подозрительные категории на прокси

Исходящая попытка установить соединение удаленного администрирования

Доступ к критичной информации (файл\база\etc)

Утечка информацииИспользование учетных записей отсутствующих сотрудников

Обнаружение передачи архива с паролем (DLP)\Отправка большого объема данных через веб-почту

Обнаружение нового хоста во внешнем периметре

Успешный взлом внешнего сервисаВнешнее сканирование портовУспешная аутентификация с не разрешенного сегмента сети (на сервис ***)Исходящая сетевая активность от критичного сервера к не доверенным хостам

JSOC - WORKFLOW

• Проблемы эксплуатации SIEM и их решение

• Как устроены сценарии по обнаружению инцидентов

• Как устроена работа инженеров с возникающими событиями

JSOC – ОСОБЕННОСТИ РАБОТЫ С ИНЦИДЕНТАМИ

1. Инцидент должен быть визуально различим

2. По каждому инциденту проставляется параметр «аггрегации» и базового скоринга

3. Необходима статистика по «развитию» инцидента и оповещениям в случае повторения или не устранения

4. Критичность инцидента различна для различных заказчиков

ПРОЦЕСС РЕГИСТРАЦИИ СОБЫТИЯ

ArcSight ESM ArcSight Case

KayakoAgentKayako Case

RuleAction: Create Case1

RuleAction: Execute External Command

2

Сетевая модель + УЗ

Информация о заказчике

Информация по инциденту

Общее описание

Расчет SLAЛинк для запуска

консоли ESM

Расчет критичности

ОБЕСПЕЧЕНИЕ SLA

1. «Время жизни» инцидента разбито на 3 промежутка: «Зеленая зона», «Желтая зона», «Красная зона»

2. При переходе инцидента из одной зоны в другую общий Score увеличивается по коэффициентам

3. Инженер обязан взять инцидент с самым высоким Score, а не приоритетом

4. Оповещения руководителей, аналитиков при необходимости «усиления» текущей команды 1-ой линии

Один день из жизни аналитика

ЗАДАЧИ АНАЛИТИКА ПО РАССЛЕДОВАНИЮ ИНЦИДЕНТОВ

Расследование при эскалации

Разбор аномалий и отчетность

Выход нового IOC

Помощь в расследовании

ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ

Выявление инцидента,Первоначальная классификация,Первоначальная приоритезация

Назначение исполнителя из 1-ой линии

Анализ инцидента,Протоколирование исследования

Необходима эскалация по экспертизе?

Передача инцидента 2-ой линии/аналитику

ДА

НЕТ

False Positive? Закрытие как FP

Информирование Заказчика, предоставление информации по инциденту и требуемых отчетов

Нужна дополнительная информация?

Закрытие задачи

НЕТ

Необходима эскалация по критичности?

Уведомление Заказчика и аналитика, формирование группы разбора инцидента

ДА

НЕТ

ДА

ДА

НЕТ

Администрируем ли СЗИ? ДА

ДА

Передача задачи по устранению группе администрирования

ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ РАЗБОР ИНЦИДЕНТА АНАЛИТИКОМ

Сбор дополнительных сведений

Взаимодействие с Заказчиком, получение

обратной связи

Подключение новых источников при

инциденте для сбора дополнительной информации в

экстренных случаях

ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ КЕЙС: REMOTE ADMIN TOOLS

Источники:• Контроллеры домена

• Сетевые устройства – МСЭ, Прокси

• Локальные логи

Сценарии срабатывания:• Встроенная категоризация сетевых устройств

• Алерты по известным портам

Расследование:• Анализ сетевой активности

• Проверка запускаемых процессов (если хост подключен)

Эскалация:• Ночное время

• Критичные хосты

ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ КЕЙС: REMOTE ADMIN TOOLS

18 Jul 2015 03:08:02 MSK Зафиксирован инцидент: Запуск RemoteAdminTools на хосте

Исходные данные:

• Машина руководителя отдела

• Локальные логи недоступны

Расследование:

• Оповещение аналитика

• Согласование с Заказчиком подключения машины к JSOC

• Подключение хоста. Для организации ретроспективного анализа – в agent properties «startatend=false»

ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИПРИМЕР УВЕДОМЛЕНИЯ

ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИDETAILS…

• 17 Jul 2015 17:23:44 MSK Запуск псевдополезного ПО

• 17 Jul 2015 18:59:14 MSK Логаут пользователя, блокировка компьютера

• 18 Jul 2015 03:07:57 MSK Запуск процесса vuupc.exe

• 18 Jul 2015 03:08:02 MSK Инцидент

• 18 Jul 2015 03:26:00 MSKОповещение аналитика по телефону

• 18 Jul 2015 03:32:48 MSKОповещение от 1-й линии в сторону Заказчика

• 18 Jul 2015 03:55:00 MSKподключение машины к ArcSight

• Профилирование легитимных процессов

• Изменение файлов /system32, в том числе Hosts

• Контроль веток реестра:– Run, RunOnce

– Параметр fSingleSessionPerUser в \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

– CLASSES_ROOT\exefile\shell

– ……

ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИКОНТРОЛЬ

ОТЧЕТЫ К УТРЕННЕМУ КОФЕ

Case review

Выборочная проверка разбора инцидентов

1-й линией

Работа с сырыми данными

Сводка по инцидентам, векторы

атак

ОТЧЕТЫ К УТРЕННЕМУ КОФЕАВТОМАТИЗАЦИЯ? НЕ ВСЕГДА!

• Запуск процессов /Temp

• Проверка легитимности C:\Users\ADMIN-~2\AppData\Local\Temp\klrbtagt_64.exe – Касперский?

• 178 соединений на ip ХХ.ХХХ.ХХ.ХХХ (Spain) с исследуемого хоста за день, подозрительно?

• Соединения ровно 1 раз в 15 минут

• Вердикт экспертизы машины –вредонос по мотивам carberb

ВЫХОД НОВОГО IOC

Анализ IOC Добавление

сигнатур

Оповещение Заказчиков

Ретроспективный анализ

ВЫХОД НОВОГО IOC

Incident of compromise

Сетевой кусок:ip-адреса

Следы присутствиявредоноса

Реестр Файлы

Сопутствующие уязвимости

Процессы

ВЫХОД НОВОГО IOC

• Carberb (Anunak, Carbanak)

• Skeleton key – использование

любой учетной записи в домене без пароля

• Сетевую часть в active list`s. Срабатывание правила: INC_Outboundcommunication to Malicious Host

• Следы и эксплуатируемые уязвимости:– Проверка на сопутствующие уязвимости сканером защищенности;

– Проверка на хостах файловых составляющих вредоноса – скрипт, Qualys;

– Проверка на хостах реестровых составляющих – скрипт, Qualys.

• Контрмеры:– Рекомендации по блокировке;

– Закрытие сопутствующих уязвимостей, направленных на повышение привилегий, загрузку в VBR/MBR и др.;

– Мониторинг создания файлов в используемых вредоносом папках (по умолчанию мониторинг производится папок system32 и других критичных системных папках) на критичных хостах;

– Мониторинг изменения некоторых критичных файлов (в т.ч. Hosts) на критичных хостах.

ВЫХОД НОВОГО IOCРЕАЛИЗАЦИЯ

ПОМОЩЬ В РАССЛЕДОВАНИИ

Не подключенные системы

Инциденты, выходящие за рамки

сценариев JSOC

Компании, не использующие JSOC

• Сбой в работе Siebel фронт-офис

• Причина: «битый» конфигурационный файл

• Две активные сессии:

– Подрядчик (SMB) с предпродакшн сервера

– Сотрудник банка (RDP) с рабочей станции

• Активности:– Сотрудник: в рамках RDP-сессий было передано в среднем порядка 5Мб, что исключает копирование готового

файла конфигурации на рабочие сервера: 5758010 байт на app04, 6020111 байт на app03, 7979583 байт на app02, 2481417 байт на app01.

– Подрядчик: Доступ ко всем продуктивным серверам к каталогу C$ с предпродуктивного (тестового) сервера Siebel

ПОМОЩЬ В РАССЛЕДОВАНИИСБОЙ В РАБОТЕ КЛЮЧЕВОЙ СИСТЕМЫ

• Подключаем тестовый сервер Siebel:

– Доступ на предпродакшн сервер из диапазона адресов подрядной организации (VPN)

– На предпродакшн сервере был запущен процесс siebdev.exe из-под учетки сотрудника подрядной организации. Процесс генерирует конфигурационный файл для Siebel.

– Далее на предпродакшн запуск через cmd C:/Bat files/sbl_stop

– Через 2 минуты запуск через cmd C:/Bat files/sbl_start

• Реализация:

– Чтение параметров процесса с помощью настроек аудита: Include command line in processcreation events во вкладке Computer Configuration\Policies\Administrative Templates\System\Audit Process Creation

ПОМОЩЬ В РАССЛЕДОВАНИИСБОЙ В РАБОТЕ КЛЮЧЕВОЙ СИСТЕМЫ

Вопросы безопасности в JSOC

О ЧЕМ ПОЙДЕТ РЕЧЬ

• Безопасность Solar в целом

• Непрерывность JSOC

• Безопасность данных в JSOC

ПРОБЛЕМЫ ЗАПУСКА ЭФФЕКТИВНОГО ИБ

• Отсутствие поддержки сверху сниз– Бизнес отдельно от ИБ (другие приоритеты)

– Выделение бюджетов на средства и персонал

• Сложность проведения оценки рисков– Внутри нет компетенций

– Снаружи – не гарантирован учет специфики

• «Исторические хвосты» процессов

и инфраструктуры

• Низкая мотивация бизнеса

и ИТ на работу с рисками

СПЕЦИФИКА SOLAR

• Все руководители «в теме» ИБ

• Короткий «астральный хвост»

• Высокие внутренние компетенции

• Свои системы и сервисы на «страже» компании

• Собственная уникальная методика по оценке рисков

ПРОЙДЕННЫЕ ШАГИ

• Бизнес-интервью по 15 ключевым сотрудникам

• Собран и согласован реестр рисков (33 опасных),информации и активов

• Создан комитет по информационной безопасности

• Согласован план мероприятий по ИБ

• В октябре – завершаем первый этап мероприятий

• PCI DSS – уже есть, ориентир - 27001

АРХИТЕКТУРА

Корп. сеть клиента Корп. сеть клиента Корп. сеть клиента

Сбор событи

й ИБ

пило

ты

Сбор

собы

тий

ИБ

ЦОД JSOCРЦОД JSOC

SIEM backup

addons

trial

SIEM

backup

jivsvdi

jivsvdi

JSOC: ДОСТУПНОСТЬ

• Инфраструктура

– вынесенный ЦОД категории Tier3

– резервный ЦОД – катастрофоустойчивость

– доступность ядра – 99,2%

• Планы непрерывности бизнеса

– распределенные площадки

– схема дежурства по компетенциям

– возможность работать

без инфраструктуры Solar

JSOC: ЦЕЛОСТНОСТЬ

• Модель здоровья, ориентированная на сервис

– Контроль состояния источников

– Контроль быстродействия

• Собственные механизмы бэкапирования

• Резервирование информации и компетенций

JSOC: ПРАВИЛА ГИГИЕНЫ

• Централизованный доступ:– персональные учетки– второй фактор– терминальный сервер с записью событий– защита удаленного доступа: два фактора + дежурные ноутбуки

• Ролевая модель:– разделение мониторинга и реагирования– ограниченный доступ для 1-ой линии– four eye principle внутри каждой из команд– контроль выгрузок и обработок информации

JSOC:КОНФИДЕНЦИАЛЬНОСТЬ –ЗАЩИЩАЕМЫЕ ДАННЫЕ

– Реквизиты доступа к клиентам

– Информация по инцидентам клиентов

– Информация по инфраструктуре

– Профиль клиента

– Сводные отчеты за период

– Сырые данные клиентов

– Полный каталог сценариев JSOC

JSOC: ВНЕШНИЕ УГРОЗЫ - ВЗЛОМ

• В Solar пользовательский сегмент изолирован:

взаимодействие только с почтой и доменом

• Отдельный service desk, KB

• В сегменте ЦОД нет публичного интернета

• Доступ в сегмент ЦОД – только через TS

+ контролируемый резервный доступ для архитектора

• В сегменте ЦОД - отдельный домен JSOC,

второй фактор аутентификации

JSOC: ВНЕШНИЕ УГРОЗЫ

• Угроза атаки со стороны клиента:

– Доступно один-два адреса

– Up2date патчи на системах

– Честный PCI DSS

– Ограниченный доступ к среде

– Мониторинг инфраструктуры JSOC

JSOC: ВНЕШНИЕ УГРОЗЫ –СОЦИНЖЕНЕРИЯ

• Проводим регулярные тесты по соц.инженерии– Внутренние проверки – раз в квартал и по факту

выхода новых сотрудников– Внешние – раз в год

• Расширенный security awareness в команде JSOC– Основы деятельности кибепреступников– Гигиена общения с клиентом– Разбор ярких кейсов последнего времени– Гигиена личного пространства

С уважением,

Команда Solar Security

http://solarsecurity.ru

+7 (499) 755-07-70

[email protected]