Каждый безопасник в своей жизни сталкивался с тем, что сотрудники ходят в Интернет, минуя прокси, качают фильмы через торрент и пользуются TeamViewer'ом. В этом посте мы немного расскажем о том, как решаем проблемы с организацией безопасного доступа в Интернет по сервисной модели и поделимся адскими кейсами, с которыми сталкиваемся у заказчиков.
Не так давно мы рассказывали про архитектуру Единой платформы сервисов кибербезопасности (ЕПСК), которая является ядром экосистемы управляемых сервисов кибербезопасности Solar MSS. ЕПСК включает и сервис по защите от сетевых угроз — Unified Threat Management (UTM).
У каждого производителя UTM свой набор функций. У нас он следующий:
- межсетевой экран;
- система предотвращения вторжений;
- сетевой антивирус;
- фильтрация веб-трафика;
- контроль использования приложений.
Часто бывает так (особенно это характерно для банков или ритейла), что у компании есть головной офис, в котором информационная безопасность находится на более-менее приемлемом уровне, а еще есть филиальная сеть, где все не так просто. В каждом офисе свой системный администратор и свои погремушки. И за защиту всей этой инфраструктуры отвечает один безопасник. Ну, или ИБ-департамент, но, так или иначе, — удаленные специалисты.
Здесь обычно возникают следующие проблемы: во-первых, надо как-то контролировать действия каждого удаленного системного администратора. Во-вторых, что даже более важно, надо каким-то образом раскатить на все филиалы единые настройки средств защиты, а потом проверять, что они обновляются корректно и быстро. Многие безопасники в такой ситуации также довольно быстро приходят к идее централизовать для всех филиалов выход в интернет, что тоже весьма непросто. Для этого нужно установить связность между всеми филиалами и головным офисом (или ЦОД) и направить весь трафик с периферии в центр. Это довольно дорого, плюс, остаются не решенными первый и второй вопросы.
Наша бизнес-модель строится на том, чтобы предложить решение всех этих задач сразу. Мы организуем связность площадок заказчика через платформу виртуализованных сервисов ИБ. В итоге весь трафик из офисов в интернет и обратно идет через UTM.
Таким образом мы получаем централизованный выход в интернет, единые настройки на все филиалы и единую точку управления средством защиты информации. Это гарантирует, что не возникнет ситуаций, когда системный администратор один раз открыл порты удаленного администрирования и забыл их закрыть, а потом через них взломали компанию. Параллельно это решает задачу объединения филиалов организации в единую КСПД (про «плюшки» технологии SD-WAN мы уже говорили ранее).
Дополнительно такой подход помогает снизить риски использования запрещенных в компании приложений. Обычно после подключения заказчика к платформе мы в первую очередь смотрим на самые популярные приложения и оцениваем, сколько трафика они потребляют. Это позволяет оперативно выявить использование средств для удаленного администрирования, торрентов, хакерских утилит и пиратского ПО.
Майнил-майнил, да не вымайнил
В одной из организаций мы выявили системного администратора, который использовал Kryptex — парень майнил, не отходя от кассы используя ресурсы своей компании. Майнер был установлен на тестовом сервере и потому оставался незамеченным, пока заказчик не подключил свою инфраструктуру к нашей платформе.
Вообще я не слежу за курсами криптовалют, но, судя по всему, они снова на подъеме – в последнее время мы опять стали часто сталкиваться с кейсами, когда администраторы пытаются майнить на корпоративных серверах.
Лейтесь, файлы
Пример из другой оперы. Мы подключили к платформе очередного заказчика, который официально разрешал всем своим администраторам использовать TeamViewer. Вообще-то мы не приветствуем такую практику, но она сейчас встречается повсеместно, да и, в общем-то, наше дело — предупредить. И вот в какой-то момент мы видим, что к рабочей станции одного из админов раз в сутки устанавливается подключение через малоизвестное средство удаленного администрирования Splashtop.
Оповестили заказчика — как и ожидалось, действия не были санкционированы. Посмотрели сессии с хоста: оказалось, что в момент запуска Splashtop устанавливается соединение с внешним файлообменником, куда передается порядка 500 МБ. К сожалению, логирование на хосте настроено не было, поэтому быстро установить причину инцидента не удалось. Стали анализировать жесткие диски и обнаружили индикатор компрометации — хэш одного из файлов, занесенных в нашу базу Threat Intelligence. Этим файлом оказалась утилита PassView, которая используется для извлечения скрытых паролей. Антивирус определил ее просто как нежелательное ПО (not a virus) и не произвел никаких действий. А в сборке этой утилиты оказалось средство удаленного администрирования — Splashtop.
Из-за отсутствия логов неизвестно, как долго злоумышленник находился в инфраструктуре, но при последнем соединении из компании «ушли» многие внутренние документы, в том числе с грифом «ДСП».
Псевдоадмин местного разлива
По нашим данным, около 50% всех внутренних инцидентов ИБ — это именно утечки конфиденциальной информации. Надо сказать, за свою многолетнюю практику мы сталкивались с огромным количеством внутренних нарушений. Часто их выявление — это фактически поиск иголки в стоге сена: в условиях малого количества источников информации приходится решать множество рутинных задач, В UTM же с утечками помогает бороться модуль фильтрации веб-траффика. Так можно выявлять и/или блокировать обращения к файлообменникам.
У одного из наших заказчиков администраторам было разрешено пользоваться файлообменниками, а остальным сотрудникам — нет. При составлении отчета мы обратили внимание на то, что один из администраторов выгружает на внешние ресурсы гораздо больше информации, чем остальные. Сообщили заказчику — его данный факт немало удивил. Администратор утверждал, что вообще не пользовался файлообменником в этом месяце.
Стали анализировать логи UTM и увидели, что под учетной записью администратора происходит аутентификация с двух разных хостов. Один из пользователей украл пароль администратора и без ограничений выгружал чувствительные для организации данные. Вычислить пользователя не предоставляло труда: он заходил под учеткой админа и под своей собственной с одного и того же хоста.
Под присмотром Solar JSOC
Таки да, было бы глупо отказываться от уже имеющихся наработок, поэтому платформа ЕПСК максимально использует опыт и знания нашего SOC — например, в части сбора и агрегации информации по угрозам. Это здорово помогает выявлять и предотвращать различные инциденты.
Так, на этапе пилотного подключения у одного из заказчиков благодаря нашей базе индикаторов компрометации, накопленной в рамках расследований, мы обнаружили, что некоторые хосты обращаются к IP-адресам, которые принадлежат хакерской группировке Cobalt.
Изучили эти хосты— выяснилось, что на них больше года (всего-то!) не обновлялись антивирусные сигнатуры и машины заражены трояном. К счастью, это был не банк, поэтому компанию спасло только то, что они были банально не интересны злоумышленникам.
Другая компания пришла к нам на пилот из-за проблем со своим межсетевым экраном. Каждые два дня он «падал» без объявления войны. Точную проблему заказчик выявить не смог — предположил, что виной всему объемы трафика. Но, так как денег на новый межсетевой экран нет, решили рассмотреть вариант перехода на сервисную модель.
В первые 10 минут после подключения к нашей платформе мы увидели интересную и одновременно ужасную картину: четыре хоста организации сканируют весь Интернет по 445, 22, 3389 портам, а еще с них идут обращения к известным C&C-серверам.
Заказчика сразу же уведомили, хосты заблокировали. В ходе разбирательств выяснилось, что они принадлежат специалистам подрядчика, которые ведут какие-то работы на площадке заказчика и используют при этом свои личные ноутбуки, зараженные самым разнообразным вредоносным ПО. Если бы с публичных IP-адресов заказчика произошла атака, это было бы, мягко говоря, неслабым репутационным ударом.
Артем Кильдюшев, группа экспертного пресэйла продуктов и сервисов Solar JSOC
Автор: SolarSecurity
