+ All Categories
Home > Technology > Расследование инцидентов: как правильно понять, что он...

Расследование инцидентов: как правильно понять, что он...

Date post: 28-Nov-2014
Category:
Upload: jetinformationsecurity
View: 190 times
Download: 5 times
Share this document with a friend
Description:
Информационная безопасность: кейсы расследования инцидентов
Popular Tags:
20
Максим Жевнерев, ведущий аналитик Jet Security Operation Center Центра информационной безопасности компании «Инфосистемы Джет» Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать 4 июня 2014 г.
Transcript
Page 1: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

Максим Жевнерев,

ведущий аналитик

Jet Security Operation Center

Центра информационной безопасности

компании «Инфосистемы Джет»

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

как правильно понять, что он

произошел и как об этом

рассказать

4 июня 2014 г.

Page 2: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

2

Содержание

О чем пойдет речь:

1. Пример инцидента: случай с вирусом-шифратором

• Зашифровано большое количество файлов на общем файловом сервере

• Файловый сервер подключен к JSOC

• Антивирус не сработал, сценариев обнаружения без AV не было

2. Пример инцидента: случай с возможной утечкой данных через VPN

• Заказчик подозревает подрядчика в копировании критичных данных

• Целевые системы не подключены к JSOC

• Из источников – только внешний FW с VPN-доступом

Page 3: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

3

Случай с вирусом-шифратором

Шаг 1. Регистрация инцидента

• Открыта заявка в Help Desk заказчика по проблеме с файлами на

общем файловом ресурсе.

• В заявке содержится информация о том, что все файлы

переименованы в *[email protected]_X28

Активность Время Прошло…

Пользователь обратился в Help Desk 2013.07.09 13:10 -

Заявка переведена на отдел ИБ заказчика 2013.07.09 13:32 22 минуты

Подключен аналитик JSOC для анализа 2013.07.09 13:45 35 минут

Page 4: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

4

Ключевые моменты для анализа

Шаг 2. Начало анализа

Что имеем:

• Общий файловый сервер – файловая шара на Windows 2008 R2

• Целевой сервер подключен к JSOC (Windows Security Log)

• Аудит доступа к файлам настроен

Что нужно сделать срочно:

• Определить хост\пользователя, откуда пошло заражение

• Найти хосты с похожей активностью

• Определить список зараженных файлов

Что нужно сделать по результатам анализа:

• Определить, как вирус попал на рабочую станцию

• Определить принцип работы вируса

• Подготовить сценарии для выявления вируса

Page 5: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

6

Как искать? Источник заражения

Поиск событий доступа к файлам

• EventID=4663

• FileName endsWith [email protected]_X28

• Смотрим самые первые по времени

доступа для каждого из найденных

пользователей

Поиск событий по соответствию User\IP

• EventID=4624

• UserName из списка найденных на 1-ом

шаге

• Код входа равен коду входа на

предыдущем шаге

Page 6: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

7

Оповещение. Источник заражения

Имя

пользователя Код входа IP-адрес Время первого обращения к файлу Примечания

Rybkinaav 0x348ed7bb 172.XXX.XXX.17 Jul 09 2013 12:21:40 Первое зафиксированное событие

Kazancevaaa 0x20755919 172.XXX.XXX.208 Jul 09 2013 12:46:05

Smirnovadl 0x1bed9b11 172.XXX.XXX.121 Jul 09 2013 13:23:07

Adminsavilovep 0x1b83d2fb 172.XXX.XXX.74 Jul 09 2013 13:32:57 Администраторы ИБ обнаружили проблему

Пример отчета по определению первых событий доступа и отчета по количеству обращений к файлам за

этот период времени

Активность Время Прошло

Список пользователей отправлен заказчику 2013.07.09 14:21 36 минут

Исходный хост идентифицирован 2013.07.09 14:39 54 минуты

Page 7: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

8

Как искать? Хосты с похожей активностью

Время Пользователь Имя файла Параметры доступа

Tue Jul 09 12:25:55 MSK 2013 rybkinaav \Device\HarddiskVolume5\SHARED\...\[email protected]_X28 ReadAttributes

Tue Jul 09 12:25:55 MSK 2013 rybkinaav \Device\HarddiskVolume5\SHARED\...\222.jpg DELETE

Tue Jul 09 12:25:55 MSK 2013 rybkinaav \Device\HarddiskVolume5\SHARED\...\222.jpg ReadAttributes

Tue Jul 09 12:25:55 MSK 2013 rybkinaav \Device\HarddiskVolume5\SHARED\...\222.jpg WriteAttributes

Tue Jul 09 12:25:55 MSK 2013 rybkinaav \Device\HarddiskVolume5\SHARED\...\222.jpg WriteData (or AddFile)

Tue Jul 09 12:25:54 MSK 2013 rybkinaav \Device\HarddiskVolume5\SHARED\...\222.jpg ReadData (or ListDirectory)

Tue Jul 09 12:25:54 MSK 2013 rybkinaav \Device\HarddiskVolume5\SHARED\...\222.jpg READ_CONTROL

Tue Jul 09 12:25:54 MSK 2013 rybkinaav \Device\HarddiskVolume5\SHARED\...\222.jpg ReadAttributes

На самом деле факт «шифрования» выглядел вот так:

А доступ к уже зараженному файлу так:

Время Пользователь Имя файла Параметры доступа

Tue Jul 09 13:33:42 MSK 2013 adminsavilovep \Device\HarddiskVolume5\SHARED\...\[email protected]_X28 ReadAttributes

Tue Jul 09 13:33:42 MSK 2013 adminsavilovep \Device\HarddiskVolume5\SHARED\...\[email protected]_X28 ReadData (or ListDirectory)

Tue Jul 09 13:33:42 MSK 2013 adminsavilovep \Device\HarddiskVolume5\SHARED\...\[email protected]_X28 READ_CONTROL

Как проверить, какие из пользователей еще заражены?

Page 8: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

9

Как искать? Хосты с похожей активностью

Правило

+

Результат «тестирования» –

корреляционное событие

+

Отчет

Активность Время Прошло…

Список хостов отправлен заказчику 2013.07.09 15:07 1 час 22 минуты

=

Page 9: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

11

Описание сценария обнаружения

1. Набор базовых правил

1. Фильтруют мусор от Windows Event Log

2. Добавляют IP\Host в событие доступа к файлу

3. Корректно отслеживают события чтения\изменения\удаления

файлов

2. DataMonitor и Dashboard

1. В основе – фильтры по базовым правилам удаления файлов

2. Считают кол-во обращений к файлам от уникальных User\Host

3. Правила для генерации оповещений

1. Смотрят за кол-вом уникальных каталогов, к которым

осуществлен доступ

2. Создают кейс и отправляют оповещение в случае, если кол-во

событий от DataMonitor больше определенного порога и кол-во

различных каталогов больше 10

Page 10: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

12

Выводы

1. К настройке сценариев обнаружения можно подойти по-разному

● Сделать конкретные правила, отслеживающие именно эту

активность

● Сделать определение аномальной активности на файловом

сервере и реагировать на нее

2. В первом случае получаем минимум ложных срабатываний, но

очень большой шанс пропустить нужное событие

3. Во втором случае получаем в среднем 2–3 срабатывания в день и

порядка 95% ложных. Но при этом видим много интересных вещей

Page 11: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

13

Сводная информация по анализу

Этапы анализа инцидента

SIEM без

настроенных

правил

SIEM с

настроенным

контентом

Идентифицированы

пользователи 36 минут 12 минут

Найден исходный зараженный

хост 54 минуты 18 минут

Итоговая локализация заражения 1 час 22 минуты 24 минуты

Подготовлены необходимые

отчеты по зараженным файлам 1 час 56 минут 28 минут

Page 12: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

14

Содержание

О чем пойдет речь:

1. Пример инцидента: Случай с вирусом-шифратором

• Зашифровано большое кол-во файлов на общем файловом сервере

• Файловый сервер подключен к JSOC

• Антивирус не сработал, сценариев обнаружения без AV не было

2. Пример инцидента: случай с возможной утечкой данных через VPN

• Заказчик подозревает подрядчика в копировании критичных данных

• Целевые системы не подключены к JSOC

• Из источников – только внешний FW с VPN-доступом

Page 13: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

15

Пример 2. Использование VPN-доступа

Об инциденте:

1. У заказчика большое количество подрядчиков, интеграторов,

которые работают удаленно через предоставленный VPN-доступ

2. На одной из презентаций руководитель проекта увидел

«подозрительно знакомые фотографии»

3. Конечные системы не подключены к JSOC, но есть внешний FW

(Cisco ASA)

Page 14: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

16

Первый случай – исходные данные

Шаг 1. Регистрация инцидента

• Звонок заказчика с просьбой помочь

• Данных достаточно много, но все разрозненные: название

компании-подрядчика, возможное время утечки (неделя назад) и

т.д.

Активность Время Прошло…

Подключен аналитик JSOC для анализа 2014.03.29 23:10 --

Page 15: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

17

Ключевые моменты для анализа

Шаг 2. Начало анализа

Что имеем:

• Список учетных записей на VPN известен

• Внешний FW с логами VPN-доступа подключен

• О конечной системе не знаем ничего, она не подключена к JSOC

Что от нас ждет заказчик:

• Понять, «тянут» ли данные в настоящий момент. Заказчика это

волнует в первую очередь

• Попробовать собрать максимальное количество данных, чтобы

было что предъявить в дальнейшем

Page 16: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

18

Поиск данных – активные сессии

sh vpn-sessiondb remote filter

Вывод:

Username : RAusername Index : 1628

Assigned IP : 172.XXX.XXX.49 Public IP:

XXX.XXX.XXX.XXX

Protocol : IKE IPsecOverNatT

License : IPsec

Encryption : AES128 AES256 Hashing :

SHA1

Bytes Tx 627178181 : Bytes Rx : 433044813

Group Policy : GroupPolicy Tunnel Group :

GroupName

Login Time : 10:38:13 GST Fri Mar 25 2014

Duration : 3d 18h:09m:58s

Inactivity : 3h:2m:13s

NAC Result : Unknown

VLAN Mapping : N/A VLAN : none

Информация по активным сессиям на ASA

Есть практически все:

- Имя пользователя

- Выделенный IP

- Переданный\полученный трафик

- Время жизни сессии

- Время с момента последней активности.

Одна проблема

- Работает только для активных сессий…

Page 17: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

19

Поиск данных – а если сессия уже

завершена?

Логи Cisco ASA

Старт сессии

Mar 25 2014 10:08:59: %ASA-6-722022: Group <GroupPolicy_Group1> User <VPN_User_1> IP <External IP> TCP

SVC connection established without compression

Плюс выделение IP в рамках сессии:

Mar 25 2014 10:08:59: %ASA-6-722022: User [VPN_User_1] assigned IP Address 10.10.10.10

Завершение сессии:

<164>Mar 29 2014 10:08:59: %ASA-4-113019: Group = GROUP, Username = VPN_User, IP = PublicIP, Session

disconnected. Session Type: IPsecOverNatT, Duration: 4d 0h:00m:47s, Bytes xmt: 433044813, Bytes rcv: 627178181,

Reason: Administrator Reset

Любое подключение внутри сети после установления сессии можно отследить двумя событиями:

Apr 23 2014 14:59:34: %ASA-6-302013: Built inbound TCP connection 666328534 for INTERNET:172.26.0.1/59558

(172.26.0.1/59558)(LOCAL\VPN_User1) to SERVERS:10.10.10.3/3389 (10.10.10.3/3389) (VPN_User1)

И соответствующее ему завершение сессии:

<166>Apr 23 2014 15:00:17: %ASA-6-302014: Teardown TCP connection 666328534 for

INTERNET:172.26.0.1/59558(LOCAL\VPN_User1) to SERVERS:10.10.10.3/3389 duration 0:00:42 bytes 2844 TCP

FINs (VPN_User1)

Page 18: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

20

Как все это реализовано в JSOC

Профилирование подключения к RDP

Активность Время Прошло…

Сообщили заказчику о первых данных 2014.03.29 23:17 7 минут

Профилирование VPN-доступа

По результатам заполняются

списки:

1. SessionList – история VPN-

подключений

2. ActiveLists –

• Текущие активные

пользователи

• Профилирование

VPN\AD\Host

Плюс отчеты на все случаи

жизни:

1. Активность пользователя

2. История подключений

3. Количество переданной

информации

Page 19: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

© 2013 Инфосистемы Джет Больше чем безопасность

21

А где же решение?

Как понять, какие данные были переданы?

1. В данном случае – почти нереально

2. Тем не менее запросили доступ к конечной системе в надежде что-то найти

3. Журналы ОС – без настроенного аудита. Бесполезно

4. Беспечность – Бесценно!

На сервере 2 каталога. C:\FRAUD, C:\FRAUD Release. Плюс лог-файл работы приложения,

скачивавшего фотографии

• Время создания совпадает с

открытой сессией

• Owner на файлах совпадает с

именем пользователя в сессии

• Объем скачанной информации

совпадает с объемом в рамках

сессии

Page 20: Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать

Контакты:

Максим Жевнерев

Аналитик JSOC,

Отдел аутсорсинга, ЦИБ


Recommended