SlideShare une entreprise Scribd logo
1  sur  50
Télécharger pour lire hors ligne
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 ToolsTORFeeds
Создание локального администратора на системе
Модификация реестра по снятию ограничений 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_MACHINESYSTEMCurrentControlSetControlTerminal Server
– CLASSES_ROOTexefileshell
– ……
ЭСКАЛАЦИЯ ПО КРИТИЧНОСТИ
КОНТРОЛЬ
ОТЧЕТЫ К УТРЕННЕМУ КОФЕ
Case review
Выборочная проверка
разбора инцидентов
1-й линией
Работа с сырыми
данными
Сводка по
инцидентам, векторы
атак
ОТЧЕТЫ К УТРЕННЕМУ КОФЕ
АВТОМАТИЗАЦИЯ? НЕ ВСЕГДА!
• Запуск процессов /Temp
• Проверка легитимности
C:UsersADMIN-
~2AppDataLocalTempklrbtagt_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_Outbound
communication 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 process
creation events во вкладке Computer ConfigurationPoliciesAdministrative
TemplatesSystemAudit 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
info@solarsecurity.ru

Contenu connexe

Tendances

Security as a Service = JSOC
Security as a Service = JSOCSecurity as a Service = JSOC
Security as a Service = JSOCSolar Security
 
спроси эксперта. все, что вы хотели узнать про Dlp, но не у кого было спросить
спроси эксперта. все, что вы хотели узнать про Dlp, но не у кого было спросить спроси эксперта. все, что вы хотели узнать про Dlp, но не у кого было спросить
спроси эксперта. все, что вы хотели узнать про Dlp, но не у кого было спросить Solar Security
 
Solar inCode – система анализа программного кода на наличие уязвимостей ИБ
Solar inCode – системаанализа программного кода на наличие уязвимостей ИБSolar inCode – системаанализа программного кода на наличие уязвимостей ИБ
Solar inCode – система анализа программного кода на наличие уязвимостей ИБSolar Security
 
От SIEM к SOC дорогу осилит смотрящий
От SIEM к SOC дорогу осилит смотрящийОт SIEM к SOC дорогу осилит смотрящий
От SIEM к SOC дорогу осилит смотрящийjet_information_security
 
спроси эксперта. все, что вы хотели знать про Id m, но боялись спросить
спроси эксперта. все, что вы хотели знать про Id m, но боялись спроситьспроси эксперта. все, что вы хотели знать про Id m, но боялись спросить
спроси эксперта. все, что вы хотели знать про Id m, но боялись спроситьSolar Security
 
Solar inRights - IdM, каким он должен быть
Solar inRights - IdM, каким он должен бытьSolar inRights - IdM, каким он должен быть
Solar inRights - IdM, каким он должен бытьSolar Security
 

Tendances (16)

пр Процедура управление инцидентами иб (Small)
пр Процедура управление инцидентами иб (Small) пр Процедура управление инцидентами иб (Small)
пр Процедура управление инцидентами иб (Small)
 
Security as a Service = JSOC
Security as a Service = JSOCSecurity as a Service = JSOC
Security as a Service = JSOC
 
спроси эксперта. все, что вы хотели узнать про Dlp, но не у кого было спросить
спроси эксперта. все, что вы хотели узнать про Dlp, но не у кого было спросить спроси эксперта. все, что вы хотели узнать про Dlp, но не у кого было спросить
спроси эксперта. все, что вы хотели узнать про Dlp, но не у кого было спросить
 
пр 03.JSOC inside
пр 03.JSOC insideпр 03.JSOC inside
пр 03.JSOC inside
 
3.про soc от из
3.про soc от из3.про soc от из
3.про soc от из
 
пр Управление инцидентами ИБ (Dozor)
пр Управление инцидентами ИБ (Dozor)пр Управление инцидентами ИБ (Dozor)
пр Управление инцидентами ИБ (Dozor)
 
пр 02.Устройство и Сервисы JSOC
пр 02.Устройство и Сервисы JSOCпр 02.Устройство и Сервисы JSOC
пр 02.Устройство и Сервисы JSOC
 
пр Про DLP Dozor v6
пр Про DLP Dozor v6пр Про DLP Dozor v6
пр Про DLP Dozor v6
 
Solar inCode – система анализа программного кода на наличие уязвимостей ИБ
Solar inCode – системаанализа программного кода на наличие уязвимостей ИБSolar inCode – системаанализа программного кода на наличие уязвимостей ИБ
Solar inCode – система анализа программного кода на наличие уязвимостей ИБ
 
4.про soc от пм
4.про soc от пм4.про soc от пм
4.про soc от пм
 
пр Solar inView Безопасность под контролем, в.1.3
пр Solar inView Безопасность под контролем, в.1.3пр Solar inView Безопасность под контролем, в.1.3
пр Solar inView Безопасность под контролем, в.1.3
 
От SIEM к SOC дорогу осилит смотрящий
От SIEM к SOC дорогу осилит смотрящийОт SIEM к SOC дорогу осилит смотрящий
От SIEM к SOC дорогу осилит смотрящий
 
спроси эксперта. все, что вы хотели знать про Id m, но боялись спросить
спроси эксперта. все, что вы хотели знать про Id m, но боялись спроситьспроси эксперта. все, что вы хотели знать про Id m, но боялись спросить
спроси эксперта. все, что вы хотели знать про Id m, но боялись спросить
 
Вебинар Спроси эксперта про IdM
Вебинар Спроси эксперта про IdMВебинар Спроси эксперта про IdM
Вебинар Спроси эксперта про IdM
 
пр Что такое новый Dozor
пр Что такое новый Dozorпр Что такое новый Dozor
пр Что такое новый Dozor
 
Solar inRights - IdM, каким он должен быть
Solar inRights - IdM, каким он должен бытьSolar inRights - IdM, каким он должен быть
Solar inRights - IdM, каким он должен быть
 

En vedette

Solar inCode – система анализа программного кода на наличие уязвимостей ИБ
Solar inCode – системаанализа программного кода на наличие уязвимостей ИБSolar inCode – системаанализа программного кода на наличие уязвимостей ИБ
Solar inCode – система анализа программного кода на наличие уязвимостей ИБSolar Security
 
Корпоративное воровство. Как взять его под контроль
Корпоративное воровство. Как взять его под контроль Корпоративное воровство. Как взять его под контроль
Корпоративное воровство. Как взять его под контроль Solar Security
 
Инструмент ChangelogBuilder для автоматической подготовки Release Notes
Инструмент ChangelogBuilder для автоматической подготовки Release NotesИнструмент ChangelogBuilder для автоматической подготовки Release Notes
Инструмент ChangelogBuilder для автоматической подготовки Release NotesPositive Hack Days
 
Тренды и угрозы в сфере ИБ
Тренды и угрозы в сфере ИБТренды и угрозы в сфере ИБ
Тренды и угрозы в сфере ИБSolar Security
 
Актуальный ландшафт угроз ИБ
Актуальный ландшафт угроз ИБ Актуальный ландшафт угроз ИБ
Актуальный ландшафт угроз ИБ Solar Security
 
Учебный центр "Информзащита". Андрей Степаненко. "Квалифицированный сотрудник...
Учебный центр "Информзащита". Андрей Степаненко. "Квалифицированный сотрудник...Учебный центр "Информзащита". Андрей Степаненко. "Квалифицированный сотрудник...
Учебный центр "Информзащита". Андрей Степаненко. "Квалифицированный сотрудник...Expolink
 
JSOC - кейсы ИБ
JSOC - кейсы ИБJSOC - кейсы ИБ
JSOC - кейсы ИБSolar Security
 
Защита от внутренних угроз
Защита от внутренних угрозЗащита от внутренних угроз
Защита от внутренних угрозSolar Security
 
Эффективные и проблемные SOC-процессы
Эффективные и проблемные SOC-процессыЭффективные и проблемные SOC-процессы
Эффективные и проблемные SOC-процессыPositive Hack Days
 
Устройство и Сервисы JSOC
Устройство и Сервисы JSOCУстройство и Сервисы JSOC
Устройство и Сервисы JSOCSolar Security
 
10 принципов измерения ИБ
10 принципов измерения ИБ10 принципов измерения ИБ
10 принципов измерения ИБSolar Security
 
Solar in code: в поисках уязвимостей
Solar in code: в поисках уязвимостей Solar in code: в поисках уязвимостей
Solar in code: в поисках уязвимостей Solar Security
 
Спроси эксперта. 2 сезон 2 серия. Тестирование приложений на уязвимости. Прак...
Спроси эксперта. 2 сезон 2 серия. Тестирование приложений на уязвимости. Прак...Спроси эксперта. 2 сезон 2 серия. Тестирование приложений на уязвимости. Прак...
Спроси эксперта. 2 сезон 2 серия. Тестирование приложений на уязвимости. Прак...Solar Security
 
Как выбрать правильный IdM управление доступом в крупных компаниях
Как выбрать правильный IdM управление доступом в крупных компанияхКак выбрать правильный IdM управление доступом в крупных компаниях
Как выбрать правильный IdM управление доступом в крупных компанияхSolar Security
 
Несколько слайдов про измерение ИБ
Несколько слайдов про измерение ИБНесколько слайдов про измерение ИБ
Несколько слайдов про измерение ИБSolar Security
 
Спроси эксперта. 2 сезон 3 серия: Solar Dozor 6.4 - новые инструменты расслед...
Спроси эксперта. 2 сезон 3 серия: Solar Dozor 6.4 - новые инструменты расслед...Спроси эксперта. 2 сезон 3 серия: Solar Dozor 6.4 - новые инструменты расслед...
Спроси эксперта. 2 сезон 3 серия: Solar Dozor 6.4 - новые инструменты расслед...Solar Security
 
Как реагировать на инциденты ИБ с помощью DLP?
Как реагировать на инциденты ИБ с помощью DLP? Как реагировать на инциденты ИБ с помощью DLP?
Как реагировать на инциденты ИБ с помощью DLP? Solar Security
 
Почему аутсорсинг ИБ становится все более востребованным в России?
Почему аутсорсинг ИБ становится все более востребованным в России?Почему аутсорсинг ИБ становится все более востребованным в России?
Почему аутсорсинг ИБ становится все более востребованным в России?Solar Security
 
Практика использования Solar inCode
Практика использования Solar inCodeПрактика использования Solar inCode
Практика использования Solar inCodeSolar Security
 

En vedette (19)

Solar inCode – система анализа программного кода на наличие уязвимостей ИБ
Solar inCode – системаанализа программного кода на наличие уязвимостей ИБSolar inCode – системаанализа программного кода на наличие уязвимостей ИБ
Solar inCode – система анализа программного кода на наличие уязвимостей ИБ
 
Корпоративное воровство. Как взять его под контроль
Корпоративное воровство. Как взять его под контроль Корпоративное воровство. Как взять его под контроль
Корпоративное воровство. Как взять его под контроль
 
Инструмент ChangelogBuilder для автоматической подготовки Release Notes
Инструмент ChangelogBuilder для автоматической подготовки Release NotesИнструмент ChangelogBuilder для автоматической подготовки Release Notes
Инструмент ChangelogBuilder для автоматической подготовки Release Notes
 
Тренды и угрозы в сфере ИБ
Тренды и угрозы в сфере ИБТренды и угрозы в сфере ИБ
Тренды и угрозы в сфере ИБ
 
Актуальный ландшафт угроз ИБ
Актуальный ландшафт угроз ИБ Актуальный ландшафт угроз ИБ
Актуальный ландшафт угроз ИБ
 
Учебный центр "Информзащита". Андрей Степаненко. "Квалифицированный сотрудник...
Учебный центр "Информзащита". Андрей Степаненко. "Квалифицированный сотрудник...Учебный центр "Информзащита". Андрей Степаненко. "Квалифицированный сотрудник...
Учебный центр "Информзащита". Андрей Степаненко. "Квалифицированный сотрудник...
 
JSOC - кейсы ИБ
JSOC - кейсы ИБJSOC - кейсы ИБ
JSOC - кейсы ИБ
 
Защита от внутренних угроз
Защита от внутренних угрозЗащита от внутренних угроз
Защита от внутренних угроз
 
Эффективные и проблемные SOC-процессы
Эффективные и проблемные SOC-процессыЭффективные и проблемные SOC-процессы
Эффективные и проблемные SOC-процессы
 
Устройство и Сервисы JSOC
Устройство и Сервисы JSOCУстройство и Сервисы JSOC
Устройство и Сервисы JSOC
 
10 принципов измерения ИБ
10 принципов измерения ИБ10 принципов измерения ИБ
10 принципов измерения ИБ
 
Solar in code: в поисках уязвимостей
Solar in code: в поисках уязвимостей Solar in code: в поисках уязвимостей
Solar in code: в поисках уязвимостей
 
Спроси эксперта. 2 сезон 2 серия. Тестирование приложений на уязвимости. Прак...
Спроси эксперта. 2 сезон 2 серия. Тестирование приложений на уязвимости. Прак...Спроси эксперта. 2 сезон 2 серия. Тестирование приложений на уязвимости. Прак...
Спроси эксперта. 2 сезон 2 серия. Тестирование приложений на уязвимости. Прак...
 
Как выбрать правильный IdM управление доступом в крупных компаниях
Как выбрать правильный IdM управление доступом в крупных компанияхКак выбрать правильный IdM управление доступом в крупных компаниях
Как выбрать правильный IdM управление доступом в крупных компаниях
 
Несколько слайдов про измерение ИБ
Несколько слайдов про измерение ИБНесколько слайдов про измерение ИБ
Несколько слайдов про измерение ИБ
 
Спроси эксперта. 2 сезон 3 серия: Solar Dozor 6.4 - новые инструменты расслед...
Спроси эксперта. 2 сезон 3 серия: Solar Dozor 6.4 - новые инструменты расслед...Спроси эксперта. 2 сезон 3 серия: Solar Dozor 6.4 - новые инструменты расслед...
Спроси эксперта. 2 сезон 3 серия: Solar Dozor 6.4 - новые инструменты расслед...
 
Как реагировать на инциденты ИБ с помощью DLP?
Как реагировать на инциденты ИБ с помощью DLP? Как реагировать на инциденты ИБ с помощью DLP?
Как реагировать на инциденты ИБ с помощью DLP?
 
Почему аутсорсинг ИБ становится все более востребованным в России?
Почему аутсорсинг ИБ становится все более востребованным в России?Почему аутсорсинг ИБ становится все более востребованным в России?
Почему аутсорсинг ИБ становится все более востребованным в России?
 
Практика использования Solar inCode
Практика использования Solar inCodeПрактика использования Solar inCode
Практика использования Solar inCode
 

Similaire à JSOC Inside

Решения и сервисы для обеспечения ИБ (ИБ Банков 2016)
Решения и сервисы для обеспечения ИБ (ИБ Банков 2016)Решения и сервисы для обеспечения ИБ (ИБ Банков 2016)
Решения и сервисы для обеспечения ИБ (ИБ Банков 2016)Alexey Kachalin
 
RuSIEM. Потребители. Состав продукта. Отличия. Применение.
RuSIEM. Потребители. Состав продукта. Отличия. Применение.RuSIEM. Потребители. Состав продукта. Отличия. Применение.
RuSIEM. Потребители. Состав продукта. Отличия. Применение.Olesya Shelestova
 
Три кита в обслуживании телекоммуникационных систем
Три кита в обслуживании телекоммуникационных системТри кита в обслуживании телекоммуникационных систем
Три кита в обслуживании телекоммуникационных системКРОК
 
SOC Technologies and processes
SOC Technologies and processesSOC Technologies and processes
SOC Technologies and processesAlexey Kachalin
 
Анализ ИБ и расследование инцидентов ИБ (учебный семинар)
Анализ ИБ и расследование инцидентов ИБ (учебный семинар)Анализ ИБ и расследование инцидентов ИБ (учебный семинар)
Анализ ИБ и расследование инцидентов ИБ (учебный семинар)Alexey Kachalin
 
Управление инцидентами информационной безопасности от А до Я
Управление инцидентами информационной безопасности от А до ЯУправление инцидентами информационной безопасности от А до Я
Управление инцидентами информационной безопасности от А до ЯDialogueScience
 
PT ESC - кто полечит доктора?
PT ESC - кто полечит доктора?PT ESC - кто полечит доктора?
PT ESC - кто полечит доктора?Alexey Kachalin
 
Вебинар: MaxPatrol + MaxPatrol SIEM - что нужно знать об оценке состояния и у...
Вебинар: MaxPatrol + MaxPatrol SIEM - что нужно знать об оценке состояния и у...Вебинар: MaxPatrol + MaxPatrol SIEM - что нужно знать об оценке состояния и у...
Вебинар: MaxPatrol + MaxPatrol SIEM - что нужно знать об оценке состояния и у...DialogueScience
 
Сколько надо SOC?
Сколько надо SOC?Сколько надо SOC?
Сколько надо SOC?Sergey Soldatov
 
Некоторые примеры метрик для измерения эффективности SOC
Некоторые примеры метрик для измерения эффективности SOCНекоторые примеры метрик для измерения эффективности SOC
Некоторые примеры метрик для измерения эффективности SOCAleksey Lukatskiy
 
Измерение эффективности SOC. 3 года спустя
Измерение эффективности SOC. 3 года спустяИзмерение эффективности SOC. 3 года спустя
Измерение эффективности SOC. 3 года спустяAleksey Lukatskiy
 
Почему аналитики L1 в SOC бесполезны?
Почему аналитики L1 в SOC бесполезны?Почему аналитики L1 в SOC бесполезны?
Почему аналитики L1 в SOC бесполезны?Aleksey Lukatskiy
 
SIEM - мониторинг безопасности в Вашей компании
SIEM - мониторинг безопасности в Вашей компанииSIEM - мониторинг безопасности в Вашей компании
SIEM - мониторинг безопасности в Вашей компанииSoftline
 
О ядре SOC - SOC-Forum Astana 2017
О ядре SOC - SOC-Forum Astana 2017О ядре SOC - SOC-Forum Astana 2017
О ядре SOC - SOC-Forum Astana 2017Alexey Kachalin
 
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"Expolink
 
Аппаратная видеоаналитика для охраны стратегических объектов
Аппаратная видеоаналитика для охраны стратегических объектов Аппаратная видеоаналитика для охраны стратегических объектов
Аппаратная видеоаналитика для охраны стратегических объектов Nikolai Ptitsyn
 
Мастер-класс по моделированию угроз
Мастер-класс по моделированию угрозМастер-класс по моделированию угроз
Мастер-класс по моделированию угрозAleksey Lukatskiy
 
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...DialogueScience
 
Вебинар по HP ArcSight 25.11.14
Вебинар по HP ArcSight 25.11.14Вебинар по HP ArcSight 25.11.14
Вебинар по HP ArcSight 25.11.14DialogueScience
 

Similaire à JSOC Inside (20)

Решения и сервисы для обеспечения ИБ (ИБ Банков 2016)
Решения и сервисы для обеспечения ИБ (ИБ Банков 2016)Решения и сервисы для обеспечения ИБ (ИБ Банков 2016)
Решения и сервисы для обеспечения ИБ (ИБ Банков 2016)
 
RuSIEM. Потребители. Состав продукта. Отличия. Применение.
RuSIEM. Потребители. Состав продукта. Отличия. Применение.RuSIEM. Потребители. Состав продукта. Отличия. Применение.
RuSIEM. Потребители. Состав продукта. Отличия. Применение.
 
Три кита в обслуживании телекоммуникационных систем
Три кита в обслуживании телекоммуникационных системТри кита в обслуживании телекоммуникационных систем
Три кита в обслуживании телекоммуникационных систем
 
SOC Technologies and processes
SOC Technologies and processesSOC Technologies and processes
SOC Technologies and processes
 
Анализ ИБ и расследование инцидентов ИБ (учебный семинар)
Анализ ИБ и расследование инцидентов ИБ (учебный семинар)Анализ ИБ и расследование инцидентов ИБ (учебный семинар)
Анализ ИБ и расследование инцидентов ИБ (учебный семинар)
 
Управление инцидентами информационной безопасности от А до Я
Управление инцидентами информационной безопасности от А до ЯУправление инцидентами информационной безопасности от А до Я
Управление инцидентами информационной безопасности от А до Я
 
PT ESC - кто полечит доктора?
PT ESC - кто полечит доктора?PT ESC - кто полечит доктора?
PT ESC - кто полечит доктора?
 
Вебинар: MaxPatrol + MaxPatrol SIEM - что нужно знать об оценке состояния и у...
Вебинар: MaxPatrol + MaxPatrol SIEM - что нужно знать об оценке состояния и у...Вебинар: MaxPatrol + MaxPatrol SIEM - что нужно знать об оценке состояния и у...
Вебинар: MaxPatrol + MaxPatrol SIEM - что нужно знать об оценке состояния и у...
 
Сколько надо SOC?
Сколько надо SOC?Сколько надо SOC?
Сколько надо SOC?
 
Некоторые примеры метрик для измерения эффективности SOC
Некоторые примеры метрик для измерения эффективности SOCНекоторые примеры метрик для измерения эффективности SOC
Некоторые примеры метрик для измерения эффективности SOC
 
Измерение эффективности SOC. 3 года спустя
Измерение эффективности SOC. 3 года спустяИзмерение эффективности SOC. 3 года спустя
Измерение эффективности SOC. 3 года спустя
 
Почему аналитики L1 в SOC бесполезны?
Почему аналитики L1 в SOC бесполезны?Почему аналитики L1 в SOC бесполезны?
Почему аналитики L1 в SOC бесполезны?
 
SIEM - мониторинг безопасности в Вашей компании
SIEM - мониторинг безопасности в Вашей компанииSIEM - мониторинг безопасности в Вашей компании
SIEM - мониторинг безопасности в Вашей компании
 
О ядре SOC - SOC-Forum Astana 2017
О ядре SOC - SOC-Forum Astana 2017О ядре SOC - SOC-Forum Astana 2017
О ядре SOC - SOC-Forum Astana 2017
 
пр 5 почему аутсорсинга ИБ
пр 5 почему аутсорсинга ИБпр 5 почему аутсорсинга ИБ
пр 5 почему аутсорсинга ИБ
 
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
 
Аппаратная видеоаналитика для охраны стратегических объектов
Аппаратная видеоаналитика для охраны стратегических объектов Аппаратная видеоаналитика для охраны стратегических объектов
Аппаратная видеоаналитика для охраны стратегических объектов
 
Мастер-класс по моделированию угроз
Мастер-класс по моделированию угрозМастер-класс по моделированию угроз
Мастер-класс по моделированию угроз
 
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
 
Вебинар по HP ArcSight 25.11.14
Вебинар по HP ArcSight 25.11.14Вебинар по HP ArcSight 25.11.14
Вебинар по HP ArcSight 25.11.14
 

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»
  • 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 ПОМОЩЬ В РАССЛЕДОВАНИИ СБОЙ В РАБОТЕ КЛЮЧЕВОЙ СИСТЕМЫ
  • 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