Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•
•
jet_information_security
jet_information_security

Информационная безопасность: кейсы расследования инцидентов

1 of 20
Максим Жевнерев, ведущий аналитик Jet Security Operation Center Центра информационной безопасности компании «Инфосистемы Джет» Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать 4 июня 2014 г.
© 2013 Инфосистемы ДжетБольше чем безопасность 2 Содержание О чем пойдет речь: 1. Пример инцидента: случай с вирусом-шифратором • Зашифровано большое количество файлов на общем файловом сервере • Файловый сервер подключен к JSOC • Антивирус не сработал, сценариев обнаружения без AV не было 2. Пример инцидента: случай с возможной утечкой данных через VPN • Заказчик подозревает подрядчика в копировании критичных данных • Целевые системы не подключены к JSOC • Из источников – только внешний FW с VPN-доступом
© 2013 Инфосистемы ДжетБольше чем безопасность 3 Случай с вирусом-шифратором Шаг 1. Регистрация инцидента • Открыта заявка в Help Desk заказчика по проблеме с файлами на общем файловом ресурсе. • В заявке содержится информация о том, что все файлы переименованы в *.tutu@safrica.com_X28 Активность Время Прошло… Пользователь обратился в Help Desk 2013.07.09 13:10 - Заявка переведена на отдел ИБ заказчика 2013.07.09 13:32 22 минуты Подключен аналитик JSOC для анализа 2013.07.09 13:45 35 минут
© 2013 Инфосистемы ДжетБольше чем безопасность 4 Ключевые моменты для анализа Шаг 2. Начало анализа Что имеем: • Общий файловый сервер – файловая шара на Windows 2008 R2 • Целевой сервер подключен к JSOC (Windows Security Log) • Аудит доступа к файлам настроен Что нужно сделать срочно: • Определить хостпользователя, откуда пошло заражение • Найти хосты с похожей активностью • Определить список зараженных файлов Что нужно сделать по результатам анализа: • Определить, как вирус попал на рабочую станцию • Определить принцип работы вируса • Подготовить сценарии для выявления вируса
© 2013 Инфосистемы ДжетБольше чем безопасность 6 Как искать? Источник заражения Поиск событий доступа к файлам • EventID=4663 • FileName endsWith tutu@safrica.com_X28 • Смотрим самые первые по времени доступа для каждого из найденных пользователей Поиск событий по соответствию UserIP • EventID=4624 • UserName из списка найденных на 1-ом шаге • Код входа равен коду входа на предыдущем шаге
© 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 минуты
© 2013 Инфосистемы ДжетБольше чем безопасность 8 Как искать? Хосты с похожей активностью Время Пользователь Имя файла Параметры доступа Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg.tutu@safrica.com_X28 ReadAttributes Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg DELETE Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg ReadAttributes Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg WriteAttributes Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg WriteData (or AddFile) Tue Jul 09 12:25:54 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg ReadData (or ListDirectory) Tue Jul 09 12:25:54 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg READ_CONTROL Tue Jul 09 12:25:54 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg ReadAttributes На самом деле факт «шифрования» выглядел вот так: А доступ к уже зараженному файлу так: Время Пользователь Имя файла Параметры доступа Tue Jul 09 13:33:42 MSK 2013 adminsavilovep DeviceHarddiskVolume5SHARED...222.jpg.tutu@safrica.com_X28 ReadAttributes Tue Jul 09 13:33:42 MSK 2013 adminsavilovep DeviceHarddiskVolume5SHARED...222.jpg.tutu@safrica.com_X28 ReadData (or ListDirectory) Tue Jul 09 13:33:42 MSK 2013 adminsavilovep DeviceHarddiskVolume5SHARED...222.jpg.tutu@safrica.com_X28 READ_CONTROL Как проверить, какие из пользователей еще заражены?
© 2013 Инфосистемы ДжетБольше чем безопасность 9 Как искать? Хосты с похожей активностью Правило + Результат «тестирования» – корреляционное событие + Отчет Активность Время Прошло… Список хостов отправлен заказчику 2013.07.09 15:07 1 час 22 минуты =
© 2013 Инфосистемы ДжетБольше чем безопасность 11 Описание сценария обнаружения 1. Набор базовых правил 1. Фильтруют мусор от Windows Event Log 2. Добавляют IPHost в событие доступа к файлу 3. Корректно отслеживают события чтенияизмененияудаления файлов 2. DataMonitor и Dashboard 1. В основе – фильтры по базовым правилам удаления файлов 2. Считают кол-во обращений к файлам от уникальных UserHost 3. Правила для генерации оповещений 1. Смотрят за кол-вом уникальных каталогов, к которым осуществлен доступ 2. Создают кейс и отправляют оповещение в случае, если кол-во событий от DataMonitor больше определенного порога и кол-во различных каталогов больше 10
© 2013 Инфосистемы ДжетБольше чем безопасность 12 Выводы 1. К настройке сценариев обнаружения можно подойти по-разному ● Сделать конкретные правила, отслеживающие именно эту активность ● Сделать определение аномальной активности на файловом сервере и реагировать на нее 2. В первом случае получаем минимум ложных срабатываний, но очень большой шанс пропустить нужное событие 3. Во втором случае получаем в среднем 2–3 срабатывания в день и порядка 95% ложных. Но при этом видим много интересных вещей
© 2013 Инфосистемы ДжетБольше чем безопасность 13 Сводная информация по анализу Этапы анализа инцидента SIEM без настроенных правил SIEM с настроенным контентом Идентифицированы пользователи 36 минут 12 минут Найден исходный зараженный хост 54 минуты 18 минут Итоговая локализация заражения 1 час 22 минуты 24 минуты Подготовлены необходимые отчеты по зараженным файлам 1 час 56 минут 28 минут
© 2013 Инфосистемы ДжетБольше чем безопасность 14 Содержание О чем пойдет речь: 1. Пример инцидента: Случай с вирусом-шифратором • Зашифровано большое кол-во файлов на общем файловом сервере • Файловый сервер подключен к JSOC • Антивирус не сработал, сценариев обнаружения без AV не было 2. Пример инцидента: случай с возможной утечкой данных через VPN • Заказчик подозревает подрядчика в копировании критичных данных • Целевые системы не подключены к JSOC • Из источников – только внешний FW с VPN-доступом
© 2013 Инфосистемы ДжетБольше чем безопасность 15 Пример 2. Использование VPN-доступа Об инциденте: 1. У заказчика большое количество подрядчиков, интеграторов, которые работают удаленно через предоставленный VPN-доступ 2. На одной из презентаций руководитель проекта увидел «подозрительно знакомые фотографии» 3. Конечные системы не подключены к JSOC, но есть внешний FW (Cisco ASA)
© 2013 Инфосистемы ДжетБольше чем безопасность 16 Первый случай – исходные данные Шаг 1. Регистрация инцидента • Звонок заказчика с просьбой помочь • Данных достаточно много, но все разрозненные: название компании-подрядчика, возможное время утечки (неделя назад) и т.д. Активность Время Прошло… Подключен аналитик JSOC для анализа 2014.03.29 23:10 --
© 2013 Инфосистемы ДжетБольше чем безопасность 17 Ключевые моменты для анализа Шаг 2. Начало анализа Что имеем: • Список учетных записей на VPN известен • Внешний FW с логами VPN-доступа подключен • О конечной системе не знаем ничего, она не подключена к JSOC Что от нас ждет заказчик: • Понять, «тянут» ли данные в настоящий момент. Заказчика это волнует в первую очередь • Попробовать собрать максимальное количество данных, чтобы было что предъявить в дальнейшем
© 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 - Переданныйполученный трафик - Время жизни сессии - Время с момента последней активности. Одна проблема - Работает только для активных сессий…
© 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)(LOCALVPN_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(LOCALVPN_User1) to SERVERS:10.10.10.3/3389 duration 0:00:42 bytes 2844 TCP FINs (VPN_User1)
© 2013 Инфосистемы ДжетБольше чем безопасность 20 Как все это реализовано в JSOC Профилирование подключения к RDP Активность Время Прошло… Сообщили заказчику о первых данных 2014.03.29 23:17 7 минут Профилирование VPN-доступа По результатам заполняются списки: 1. SessionList – история VPN- подключений 2. ActiveLists – • Текущие активные пользователи • Профилирование VPNADHost Плюс отчеты на все случаи жизни: 1. Активность пользователя 2. История подключений 3. Количество переданной информации
© 2013 Инфосистемы ДжетБольше чем безопасность 21 А где же решение? Как понять, какие данные были переданы? 1. В данном случае – почти нереально 2. Тем не менее запросили доступ к конечной системе в надежде что-то найти 3. Журналы ОС – без настроенного аудита. Бесполезно 4. Беспечность – Бесценно! На сервере 2 каталога. C:FRAUD, C:FRAUD Release. Плюс лог-файл работы приложения, скачивавшего фотографии • Время создания совпадает с открытой сессией • Owner на файлах совпадает с именем пользователя в сессии • Объем скачанной информации совпадает с объемом в рамках сессии
Контакты: Максим Жевнерев Аналитик JSOC, Отдел аутсорсинга, ЦИБ

More Related Content

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

  • 1. Максим Жевнерев, ведущий аналитик Jet Security Operation Center Центра информационной безопасности компании «Инфосистемы Джет» Расследование инцидентов: как правильно понять, что он произошел и как об этом рассказать 4 июня 2014 г.
  • 2. © 2013 Инфосистемы ДжетБольше чем безопасность 2 Содержание О чем пойдет речь: 1. Пример инцидента: случай с вирусом-шифратором • Зашифровано большое количество файлов на общем файловом сервере • Файловый сервер подключен к JSOC • Антивирус не сработал, сценариев обнаружения без AV не было 2. Пример инцидента: случай с возможной утечкой данных через VPN • Заказчик подозревает подрядчика в копировании критичных данных • Целевые системы не подключены к JSOC • Из источников – только внешний FW с VPN-доступом
  • 3. © 2013 Инфосистемы ДжетБольше чем безопасность 3 Случай с вирусом-шифратором Шаг 1. Регистрация инцидента • Открыта заявка в Help Desk заказчика по проблеме с файлами на общем файловом ресурсе. • В заявке содержится информация о том, что все файлы переименованы в *.tutu@safrica.com_X28 Активность Время Прошло… Пользователь обратился в Help Desk 2013.07.09 13:10 - Заявка переведена на отдел ИБ заказчика 2013.07.09 13:32 22 минуты Подключен аналитик JSOC для анализа 2013.07.09 13:45 35 минут
  • 4. © 2013 Инфосистемы ДжетБольше чем безопасность 4 Ключевые моменты для анализа Шаг 2. Начало анализа Что имеем: • Общий файловый сервер – файловая шара на Windows 2008 R2 • Целевой сервер подключен к JSOC (Windows Security Log) • Аудит доступа к файлам настроен Что нужно сделать срочно: • Определить хостпользователя, откуда пошло заражение • Найти хосты с похожей активностью • Определить список зараженных файлов Что нужно сделать по результатам анализа: • Определить, как вирус попал на рабочую станцию • Определить принцип работы вируса • Подготовить сценарии для выявления вируса
  • 5. © 2013 Инфосистемы ДжетБольше чем безопасность 6 Как искать? Источник заражения Поиск событий доступа к файлам • EventID=4663 • FileName endsWith tutu@safrica.com_X28 • Смотрим самые первые по времени доступа для каждого из найденных пользователей Поиск событий по соответствию UserIP • EventID=4624 • UserName из списка найденных на 1-ом шаге • Код входа равен коду входа на предыдущем шаге
  • 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 минуты
  • 7. © 2013 Инфосистемы ДжетБольше чем безопасность 8 Как искать? Хосты с похожей активностью Время Пользователь Имя файла Параметры доступа Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg.tutu@safrica.com_X28 ReadAttributes Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg DELETE Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg ReadAttributes Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg WriteAttributes Tue Jul 09 12:25:55 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg WriteData (or AddFile) Tue Jul 09 12:25:54 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg ReadData (or ListDirectory) Tue Jul 09 12:25:54 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg READ_CONTROL Tue Jul 09 12:25:54 MSK 2013 rybkinaav DeviceHarddiskVolume5SHARED...222.jpg ReadAttributes На самом деле факт «шифрования» выглядел вот так: А доступ к уже зараженному файлу так: Время Пользователь Имя файла Параметры доступа Tue Jul 09 13:33:42 MSK 2013 adminsavilovep DeviceHarddiskVolume5SHARED...222.jpg.tutu@safrica.com_X28 ReadAttributes Tue Jul 09 13:33:42 MSK 2013 adminsavilovep DeviceHarddiskVolume5SHARED...222.jpg.tutu@safrica.com_X28 ReadData (or ListDirectory) Tue Jul 09 13:33:42 MSK 2013 adminsavilovep DeviceHarddiskVolume5SHARED...222.jpg.tutu@safrica.com_X28 READ_CONTROL Как проверить, какие из пользователей еще заражены?
  • 8. © 2013 Инфосистемы ДжетБольше чем безопасность 9 Как искать? Хосты с похожей активностью Правило + Результат «тестирования» – корреляционное событие + Отчет Активность Время Прошло… Список хостов отправлен заказчику 2013.07.09 15:07 1 час 22 минуты =
  • 9. © 2013 Инфосистемы ДжетБольше чем безопасность 11 Описание сценария обнаружения 1. Набор базовых правил 1. Фильтруют мусор от Windows Event Log 2. Добавляют IPHost в событие доступа к файлу 3. Корректно отслеживают события чтенияизмененияудаления файлов 2. DataMonitor и Dashboard 1. В основе – фильтры по базовым правилам удаления файлов 2. Считают кол-во обращений к файлам от уникальных UserHost 3. Правила для генерации оповещений 1. Смотрят за кол-вом уникальных каталогов, к которым осуществлен доступ 2. Создают кейс и отправляют оповещение в случае, если кол-во событий от DataMonitor больше определенного порога и кол-во различных каталогов больше 10
  • 10. © 2013 Инфосистемы ДжетБольше чем безопасность 12 Выводы 1. К настройке сценариев обнаружения можно подойти по-разному ● Сделать конкретные правила, отслеживающие именно эту активность ● Сделать определение аномальной активности на файловом сервере и реагировать на нее 2. В первом случае получаем минимум ложных срабатываний, но очень большой шанс пропустить нужное событие 3. Во втором случае получаем в среднем 2–3 срабатывания в день и порядка 95% ложных. Но при этом видим много интересных вещей
  • 11. © 2013 Инфосистемы ДжетБольше чем безопасность 13 Сводная информация по анализу Этапы анализа инцидента SIEM без настроенных правил SIEM с настроенным контентом Идентифицированы пользователи 36 минут 12 минут Найден исходный зараженный хост 54 минуты 18 минут Итоговая локализация заражения 1 час 22 минуты 24 минуты Подготовлены необходимые отчеты по зараженным файлам 1 час 56 минут 28 минут
  • 12. © 2013 Инфосистемы ДжетБольше чем безопасность 14 Содержание О чем пойдет речь: 1. Пример инцидента: Случай с вирусом-шифратором • Зашифровано большое кол-во файлов на общем файловом сервере • Файловый сервер подключен к JSOC • Антивирус не сработал, сценариев обнаружения без AV не было 2. Пример инцидента: случай с возможной утечкой данных через VPN • Заказчик подозревает подрядчика в копировании критичных данных • Целевые системы не подключены к JSOC • Из источников – только внешний FW с VPN-доступом
  • 13. © 2013 Инфосистемы ДжетБольше чем безопасность 15 Пример 2. Использование VPN-доступа Об инциденте: 1. У заказчика большое количество подрядчиков, интеграторов, которые работают удаленно через предоставленный VPN-доступ 2. На одной из презентаций руководитель проекта увидел «подозрительно знакомые фотографии» 3. Конечные системы не подключены к JSOC, но есть внешний FW (Cisco ASA)
  • 14. © 2013 Инфосистемы ДжетБольше чем безопасность 16 Первый случай – исходные данные Шаг 1. Регистрация инцидента • Звонок заказчика с просьбой помочь • Данных достаточно много, но все разрозненные: название компании-подрядчика, возможное время утечки (неделя назад) и т.д. Активность Время Прошло… Подключен аналитик JSOC для анализа 2014.03.29 23:10 --
  • 15. © 2013 Инфосистемы ДжетБольше чем безопасность 17 Ключевые моменты для анализа Шаг 2. Начало анализа Что имеем: • Список учетных записей на VPN известен • Внешний FW с логами VPN-доступа подключен • О конечной системе не знаем ничего, она не подключена к JSOC Что от нас ждет заказчик: • Понять, «тянут» ли данные в настоящий момент. Заказчика это волнует в первую очередь • Попробовать собрать максимальное количество данных, чтобы было что предъявить в дальнейшем
  • 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 - Переданныйполученный трафик - Время жизни сессии - Время с момента последней активности. Одна проблема - Работает только для активных сессий…
  • 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)(LOCALVPN_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(LOCALVPN_User1) to SERVERS:10.10.10.3/3389 duration 0:00:42 bytes 2844 TCP FINs (VPN_User1)
  • 18. © 2013 Инфосистемы ДжетБольше чем безопасность 20 Как все это реализовано в JSOC Профилирование подключения к RDP Активность Время Прошло… Сообщили заказчику о первых данных 2014.03.29 23:17 7 минут Профилирование VPN-доступа По результатам заполняются списки: 1. SessionList – история VPN- подключений 2. ActiveLists – • Текущие активные пользователи • Профилирование VPNADHost Плюс отчеты на все случаи жизни: 1. Активность пользователя 2. История подключений 3. Количество переданной информации
  • 19. © 2013 Инфосистемы ДжетБольше чем безопасность 21 А где же решение? Как понять, какие данные были переданы? 1. В данном случае – почти нереально 2. Тем не менее запросили доступ к конечной системе в надежде что-то найти 3. Журналы ОС – без настроенного аудита. Бесполезно 4. Беспечность – Бесценно! На сервере 2 каталога. C:FRAUD, C:FRAUD Release. Плюс лог-файл работы приложения, скачивавшего фотографии • Время создания совпадает с открытой сессией • Owner на файлах совпадает с именем пользователя в сессии • Объем скачанной информации совпадает с объемом в рамках сессии