JSOC Inside
0 likes805 views
Документ описывает процесс управления инцидентами в системе JSOC, включая этапы обнаружения, классификации и анализа инцидентов, а также обучение сотрудников первой и второй линии поддержки. Включены аспекты SLA и параметры обслуживания, а также проблемы, связанные с эксплуатацией SIEM. Приведены примеры инцидентов и сценариев их обработки, акцентируя внимание на важности визуализации и своевременного реагирования.
JSOC Inside
- 2. JSOC – СХЕМА РАЗБОРА ИНЦИДЕНТА Выявление инцидента, Первоначальная классификация, Первоначальная приоритезация Назначение исполнителя из 1-ой линии Анализ инцидента, Протоколирование исследования Необходима эскалация по экспертизе? Передача инцидента 2-ой линии/аналитику ДА НЕТ False Positive? Закрытие как FP Информирование Заказчика, предоставление информации по инциденту и требуемых отчетов Нужна дополнительная информация? Закрытие задачи НЕТ Необходима эскалация по критичности? Уведомление Заказчика и аналитика, формирование группы разбора инцидента ДА НЕТ ДА ДА НЕТ Администрируем ли СЗИ? ДА ДА Передача задачи по устранению группе администрирования
- 3. SOC ВНУТРИ – 1-Я ЛИНИЯ • Понимает основы безопасности • Разбирается в исходных событиях с систем • Владеет всеми инструментами расследования в SOC • Работает по инструкции, но не ограничивается ей • Пытается восстановить произошедшее в реальном мире
- 4. ПРОГРАММА ОБУЧЕНИЯ СОТРУДНИКА 1. Основы информационной безопасности: – Что такое информационная безопасность в принципе – Регулирующие документы в области информационной безопасности – Инцидент информационной безопасности: определение, отличие от ИТ-инцидента, принципы определения критичности – Драйверы информационной безопасности коммерческого сектора: регуляторы, политики, внешние угрозы, экономическая безопасность, репутационные риски – Киберпреступность: основные векторы атаки, пути компрометации, – Классификация инцидентов JSOC: с чем связан инцидент, какие последствия влечет, какая информация важна для расследования 2. Работа с аудитом ключевых инфраструктурных сервисов: – Active Directory – события аутентификации – Active Directory – прочие события – События аутентификации на прочих системах – Аудит ОС Windows – Аудит ОС Linux – Аудит СУБД (sql запросы, синтаксис, основы обработки и значения команд) – Аудит сетевого оборудования – Аудит межсетевых экранов – Антивирусы и прочее host-based ПО (принципы работы, ключевые события)
- 5. ПРОГРАММА ОБУЧЕНИЯ СОТРУДНИКА 3. События со СЗИ: – Антивирусы (типы вирусов, особенности поведения, критерии обнаружения) – Сетевые атаки (классификация, основные параметры) – DDOS-атаки (принципы работы, типы, ключевые способы обнаружения) – Атаки на веб-приложения (принципы, типы, ключевые способы обнаружения) 4. Инструментарий JSOC: – Основные инструменты ArcSight для расследования инцидента – Внешние способы обработки информации, источники знаний – Разбор 3-4 ключевых инцидентов в рамках совместной работы 5. Самостоятельный анализ информации, выполнение лабораторных 6. Выпускной экзамен по освоению материала
- 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 ч
- 7. О ЧЕМ ПОЙДЕТ РЕЧЬ • Проблемы эксплуатации SIEM и их решение • Как устроены сценарии по обнаружению инцидентов • Как устроена работа инженеров с возникающими событиями
- 8. ПРОБЛЕМА 1 – ОДИН СЦЕНАРИЙ ДЛЯ РАЗЛИЧНЫХ ИСТОЧНИКОВ • Логика инцидентов одинакова – brute-force всегда brute-force • В каждом приложении (AD, Unix OS, Cisco VPN, Siebel, Web- приложение) – свои логи и своя информация. • Добавить новое приложение – пара правил + списки с исключениями и профилированием активности • В итоге: • Сложность диагностики • Риск ошибки при реализации • Увеличение нагрузки на систему
- 9. ПРОБЛЕМА 2 - ОБЪЕДИНЕНИЕ ДАННЫХ • Сценарий – 10 срабатываний сигнатур IPS с одного источника • В случае 50 срабатываний (идет сканирование): • 40 различных событий • 40 сообщений в почту • С трудом можно сопоставить данные в одну сущность • При этом – потенциально это одна и та же активность
- 10. ПРИМЕР – ВНЕШНИЕ ПОДКЛЮЧЕНИЯ С TOR- СЕТИ Менее чем за час – 6 событий об одном и том же сканировании
- 11. «ПРОБЛЕМА 3» ПРАВИЛА ЖИЗНИ СЕРВИС-ПРОВАЙДЕРА 1. Три уровня SLA. • По каждому свое время реакции в зависимости от критичности инцидента • У каждого заказчика свой SLA • У каждого заказчика разное видение критичности инцидента 2. Визуализация и прозрачность работы с инцидентами. • Операторам должны быть доступны уже обработанные события. • Операторы не должны «выбирать» инциденты. 3. Мы не должны «терять» инциденты. • Критичный инцидент должен быть рассмотрен вовремя. Вне зависимости от того, что до него пришло 10 не критичных инцидентов • Критичности инцидентов – это не приоритет их расследования 4. Удобство работы и масштабируемость • Добавление нового правила не должно влиять на сервис • Масштабирование правила на новый источник не должно влиять на сервис • Инженер не должен искать в инструкциях время реакции, критичности, телефоны и e-mail заказчика
- 12. JSOC - WORKFLOW • Проблемы эксплуатации SIEM и их решение • Как устроены сценарии по обнаружению инцидентов • Как устроена работа инженеров с возникающими событиями
- 13. JSOC – АРХИТЕКТУРА КОРРЕЛЯЦИОННЫХ ПРАВИЛ Workflow Сценарии «Базовые» и «Профилирующие» правила Переработанные парсеры для коннекторов • Оповещения, создание кейсов, обработка информации • Необходимые отчеты и инструменты для анализа инцидентов • Генерация событий по соответствующим критериям • «Обогащение» информации • Очистка «мусора» • Добавление нашей категоризации • Профилирование активностей • Добавление «пропущенной» информации • Исправление проблем с парсингом
- 14. ПРИМЕРЫ СЦЕНАРИЕВ Базовые сценарии (косвенные признаки) Потенциальный инцидент Входящее письмо от неизвестного отправителя Почти 100% заражение хоста Вероятный целенаправленный взлом хоста Запуск нелегитимного ПО (процесса) на рабочей станции Исходящая активность Remote Access ToolsTORFeeds Создание локального администратора на системе Модификация реестра по снятию ограничений RDP на хосте Большое кол-во неуспешных подключений во внешнюю сеть Вероятные ботнетынеизвестные вирусы Доступ в интернет к известным опасным хостам (Feeds) подозрительные категории на прокси Исходящая попытка установить соединение удаленного администрирования Доступ к критичной информации (файлбазаetc) Утечка информацииИспользование учетных записей отсутствующих сотрудников Обнаружение передачи архива с паролем (DLP)Отправка большого объема данных через веб-почту Обнаружение нового хоста во внешнем периметре Успешный взлом внешнего сервиса Внешнее сканирование портов Успешная аутентификация с не разрешенного сегмента сети (на сервис ***) Исходящая сетевая активность от критичного сервера к не доверенным хостам
- 15. JSOC - WORKFLOW • Проблемы эксплуатации SIEM и их решение • Как устроены сценарии по обнаружению инцидентов • Как устроена работа инженеров с возникающими событиями
- 16. JSOC – ОСОБЕННОСТИ РАБОТЫ С ИНЦИДЕНТАМИ 1. Инцидент должен быть визуально различим 2. По каждому инциденту проставляется параметр «аггрегации» и базового скоринга 3. Необходима статистика по «развитию» инцидента и оповещениям в случае повторения или не устранения 4. Критичность инцидента различна для различных заказчиков
- 17. ПРОЦЕСС РЕГИСТРАЦИИ СОБЫТИЯ ArcSight ESM ArcSight Case KayakoAgentKayako Case RuleAction: Create Case1 RuleAction: Execute External Command 2 Сетевая модель + УЗ Информация о заказчике Информация по инциденту Общее описание Расчет SLA Линк для запуска консоли ESM Расчет критичности
- 18. ОБЕСПЕЧЕНИЕ SLA 1. «Время жизни» инцидента разбито на 3 промежутка: «Зеленая зона», «Желтая зона», «Красная зона» 2. При переходе инцидента из одной зоны в другую общий Score увеличивается по коэффициентам 3. Инженер обязан взять инцидент с самым высоким Score, а не приоритетом 4. Оповещения руководителей, аналитиков при необходимости «усиления» текущей команды 1-ой линии
- 19. Один день из жизни аналитика
- 20. ЗАДАЧИ АНАЛИТИКА ПО РАССЛЕДОВАНИЮ ИНЦИДЕНТОВ Расследование при эскалации Разбор аномалий и отчетность Выход нового IOC Помощь в расследовании
- 21. ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ Выявление инцидента, Первоначальная классификация, Первоначальная приоритезация Назначение исполнителя из 1-ой линии Анализ инцидента, Протоколирование исследования Необходима эскалация по экспертизе? Передача инцидента 2-ой линии/аналитику ДА НЕТ False Positive? Закрытие как FP Информирование Заказчика, предоставление информации по инциденту и требуемых отчетов Нужна дополнительная информация? Закрытие задачи НЕТ Необходима эскалация по критичности? Уведомление Заказчика и аналитика, формирование группы разбора инцидента ДА НЕТ ДА ДА НЕТ Администрируем ли СЗИ? ДА ДА Передача задачи по устранению группе администрирования
- 22. ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ РАЗБОР ИНЦИДЕНТА АНАЛИТИКОМ Сбор дополнительных сведений Взаимодействие с Заказчиком, получение обратной связи Подключение новых источников при инциденте для сбора дополнительной информации в экстренных случаях
- 23. ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ КЕЙС: REMOTE ADMIN TOOLS Источники: • Контроллеры домена • Сетевые устройства – МСЭ, Прокси • Локальные логи Сценарии срабатывания: • Встроенная категоризация сетевых устройств • Алерты по известным портам Расследование: • Анализ сетевой активности • Проверка запускаемых процессов (если хост подключен) Эскалация: • Ночное время • Критичные хосты
- 24. ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ КЕЙС: REMOTE ADMIN TOOLS 18 Jul 2015 03:08:02 MSK Зафиксирован инцидент: Запуск RemoteAdminTools на хосте Исходные данные: • Машина руководителя отдела • Локальные логи недоступны Расследование: • Оповещение аналитика • Согласование с Заказчиком подключения машины к JSOC • Подключение хоста. Для организации ретроспективного анализа – в agent properties «startatend=false»
- 25. ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ ПРИМЕР УВЕДОМЛЕНИЯ
- 26. ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ 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
- 27. • Профилирование легитимных процессов • Изменение файлов /system32, в том числе Hosts • Контроль веток реестра: – Run, RunOnce – Параметр fSingleSessionPerUser в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server – CLASSES_ROOTexefileshell – …… ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ КОНТРОЛЬ
- 28. ОТЧЕТЫ К УТРЕННЕМУ КОФЕ Case review Выборочная проверка разбора инцидентов 1-й линией Работа с сырыми данными Сводка по инцидентам, векторы атак
- 29. ОТЧЕТЫ К УТРЕННЕМУ КОФЕ АВТОМАТИЗАЦИЯ? НЕ ВСЕГДА! • Запуск процессов /Temp • Проверка легитимности C:UsersADMIN- ~2AppDataLocalTempklrbtagt_64.exe – Касперский? • 178 соединений на ip ХХ.ХХХ.ХХ.ХХХ (Spain) с исследуемого хоста за день, подозрительно? • Соединения ровно 1 раз в 15 минут • Вердикт экспертизы машины – вредонос по мотивам carberb
- 30. ВЫХОД НОВОГО IOC Анализ IOC Добавление сигнатур Оповещение Заказчиков Ретроспективный анализ
- 31. ВЫХОД НОВОГО IOC Incident of compromise Сетевой кусок: ip-адреса Следы присутствия вредоноса Реестр Файлы Сопутствующие уязвимости Процессы
- 32. ВЫХОД НОВОГО IOC • Carberb (Anunak, Carbanak) • Skeleton key – использование любой учетной записи в домене без пароля
- 33. • Сетевую часть в active list`s. Срабатывание правила: INC_Outbound communication to Malicious Host • Следы и эксплуатируемые уязвимости: – Проверка на сопутствующие уязвимости сканером защищенности; – Проверка на хостах файловых составляющих вредоноса – скрипт, Qualys; – Проверка на хостах реестровых составляющих – скрипт, Qualys. • Контрмеры: – Рекомендации по блокировке; – Закрытие сопутствующих уязвимостей, направленных на повышение привилегий, загрузку в VBR/MBR и др.; – Мониторинг создания файлов в используемых вредоносом папках (по умолчанию мониторинг производится папок system32 и других критичных системных папках) на критичных хостах; – Мониторинг изменения некоторых критичных файлов (в т.ч. Hosts) на критичных хостах. ВЫХОД НОВОГО IOC РЕАЛИЗАЦИЯ
- 34. ПОМОЩЬ В РАССЛЕДОВАНИИ Не подключенные системы Инциденты, выходящие за рамки сценариев JSOC Компании, не использующие JSOC
- 35. • Сбой в работе Siebel фронт-офис • Причина: «битый» конфигурационный файл • Две активные сессии: – Подрядчик (SMB) с предпродакшн сервера – Сотрудник банка (RDP) с рабочей станции • Активности: – Сотрудник: в рамках RDP-сессий было передано в среднем порядка 5Мб, что исключает копирование готового файла конфигурации на рабочие сервера: 5758010 байт на app04, 6020111 байт на app03, 7979583 байт на app02, 2481417 байт на app01. – Подрядчик: Доступ ко всем продуктивным серверам к каталогу C$ с предпродуктивного (тестового) сервера Siebel ПОМОЩЬ В РАССЛЕДОВАНИИ СБОЙ В РАБОТЕ КЛЮЧЕВОЙ СИСТЕМЫ
- 36. • Подключаем тестовый сервер Siebel: – Доступ на предпродакшн сервер из диапазона адресов подрядной организации (VPN) – На предпродакшн сервере был запущен процесс siebdev.exe из-под учетки сотрудника подрядной организации. Процесс генерирует конфигурационный файл для Siebel. – Далее на предпродакшн запуск через cmd C:/Bat files/sbl_stop – Через 2 минуты запуск через cmd C:/Bat files/sbl_start • Реализация: – Чтение параметров процесса с помощью настроек аудита: Include command line in process creation events во вкладке Computer ConfigurationPoliciesAdministrative TemplatesSystemAudit Process Creation ПОМОЩЬ В РАССЛЕДОВАНИИ СБОЙ В РАБОТЕ КЛЮЧЕВОЙ СИСТЕМЫ
- 37. Вопросы безопасности в JSOC
- 38. О ЧЕМ ПОЙДЕТ РЕЧЬ • Безопасность Solar в целом • Непрерывность JSOC • Безопасность данных в JSOC
- 39. ПРОБЛЕМЫ ЗАПУСКА ЭФФЕКТИВНОГО ИБ • Отсутствие поддержки сверху сниз – Бизнес отдельно от ИБ (другие приоритеты) – Выделение бюджетов на средства и персонал • Сложность проведения оценки рисков – Внутри нет компетенций – Снаружи – не гарантирован учет специфики • «Исторические хвосты» процессов и инфраструктуры • Низкая мотивация бизнеса и ИТ на работу с рисками
- 40. СПЕЦИФИКА SOLAR • Все руководители «в теме» ИБ • Короткий «астральный хвост» • Высокие внутренние компетенции • Свои системы и сервисы на «страже» компании • Собственная уникальная методика по оценке рисков
- 41. ПРОЙДЕННЫЕ ШАГИ • Бизнес-интервью по 15 ключевым сотрудникам • Собран и согласован реестр рисков (33 опасных), информации и активов • Создан комитет по информационной безопасности • Согласован план мероприятий по ИБ • В октябре – завершаем первый этап мероприятий • PCI DSS – уже есть, ориентир - 27001
- 42. АРХИТЕКТУРА Корп. сеть клиента Корп. сеть клиента Корп. сеть клиента СборсобытийИБ пилоты СборсобытийИБ ЦОД JSOC РЦОД JSOC SIEM backup addons trial SIEM backup jivsvdi jivsvdi
- 43. JSOC: ДОСТУПНОСТЬ • Инфраструктура – вынесенный ЦОД категории Tier3 – резервный ЦОД – катастрофоустойчивость – доступность ядра – 99,2% • Планы непрерывности бизнеса – распределенные площадки – схема дежурства по компетенциям – возможность работать без инфраструктуры Solar
- 44. JSOC: ЦЕЛОСТНОСТЬ • Модель здоровья, ориентированная на сервис – Контроль состояния источников – Контроль быстродействия • Собственные механизмы бэкапирования • Резервирование информации и компетенций
- 45. JSOC: ПРАВИЛА ГИГИЕНЫ • Централизованный доступ: – персональные учетки – второй фактор – терминальный сервер с записью событий – защита удаленного доступа: два фактора + дежурные ноутбуки • Ролевая модель: – разделение мониторинга и реагирования – ограниченный доступ для 1-ой линии – four eye principle внутри каждой из команд – контроль выгрузок и обработок информации
- 46. JSOC:КОНФИДЕНЦИАЛЬНОСТЬ – ЗАЩИЩАЕМЫЕ ДАННЫЕ – Реквизиты доступа к клиентам – Информация по инцидентам клиентов – Информация по инфраструктуре – Профиль клиента – Сводные отчеты за период – Сырые данные клиентов – Полный каталог сценариев JSOC
- 47. JSOC: ВНЕШНИЕ УГРОЗЫ - ВЗЛОМ • В Solar пользовательский сегмент изолирован: взаимодействие только с почтой и доменом • Отдельный service desk, KB • В сегменте ЦОД нет публичного интернета • Доступ в сегмент ЦОД – только через TS + контролируемый резервный доступ для архитектора • В сегменте ЦОД - отдельный домен JSOC, второй фактор аутентификации
- 48. JSOC: ВНЕШНИЕ УГРОЗЫ • Угроза атаки со стороны клиента: – Доступно один-два адреса – Up2date патчи на системах – Честный PCI DSS – Ограниченный доступ к среде – Мониторинг инфраструктуры JSOC
- 49. JSOC: ВНЕШНИЕ УГРОЗЫ – СОЦИНЖЕНЕРИЯ • Проводим регулярные тесты по соц.инженерии – Внутренние проверки – раз в квартал и по факту выхода новых сотрудников – Внешние – раз в год • Расширенный security awareness в команде JSOC – Основы деятельности кибепреступников – Гигиена общения с клиентом – Разбор ярких кейсов последнего времени – Гигиена личного пространства
- 50. С уважением, Команда Solar Security http://solarsecurity.ru +7 (499) 755-07-70 info@solarsecurity.ru