JSOC на все руки: от ловли мошенничества в интернет-магазинах и кредитных конвейерах до обеспечения безопасности АСУ ТП

В последние несколько лет угрозы информационной безопасности стремительно эволюционируют. Тенденции ИБ показывают, что происходит постоянное увеличение количества атак и внутренних утечек информации и связанный с ними рост экономического и репутационного ущерба. Сейчас, как никогда раньше, службе ИБ нужны не только средства защиты информации и противодействия атакам, но и «глаза» − системы мониторинга. Для оперативного выявления, расследования и принятия мер по противодействию угрозам требуется построение центра управления инцидентами информационной безопасности − Security Operation Center, «сердце» которого SIEM-система.

Я не буду углубляться в проблематику построения собственного SOC и сопряженные с нею трудности − об этом можно почитать в статье Владимира Дрюкова http://www.itsec.ru/articles2/Oborandteh/ib-autsorsing-zadachka-s-zhivymi-usloviyami. В данной статье речь пойдет о JSOC – коммерческом центре мониторинга и реагирования на инциденты ИБ, которому в апреле 2015 исполнилось 2 года. Сегодня на его счету уже множество выявленных атак, инсайдеров, халатностей сотрудников и даже борьба с APT в нескольких компаниях.

Особенное внимание мне хотелось бы уделить наиболее типичным инцидентам, затрагивающим как различные сферы бизнеса, так и элементы инфраструктуры компаний. В некоторых случаях мы выявляли, расследовали и вводили меры противодействия угрозам, в других − нас привлекали, как специалистов в области ИБ и хороших экспертов по продукту HP ArcSight, являющемуся основой нашего JSOC`а и изученному нами в буквальном смысле вдоль и поперек. Поэтому данная статья посвящена четырем реально произошедшим инцидентам, возможностям для их выявления и противодействия им. Порядок в повествовании следует логике «снаружи – внутрь». Таким образом, первые инциденты затрагивают периметр компании и внешние сервисы, а в конце статьи я расскажу о ключевых бизнес-системах и критически важных сегментах в корпоративной сети клиентов.

Защита интернет-магазина

Интернет-магазин − один из наиболее часто атакуемых видов ресурсов. При упоминании защиты интернет-ресурса большинство компаний обращают свой взор на Anti-DDoS решения и Web Application Firewall. Но в рассматриваемом кейсе у компании возникла другая проблема. Представьте ситуацию: злоумышленник имеет доступ к заказам интернет-магазина с возможностью полного перехвата, и знает, что некто Иван Иванович хочет купить телефон за 50 тысяч в данном магазине. При недолгом поиске выясняется, что цена в интернете составляет 30 тысяч рублей за «серый» товар. Дальнейшая последовательность действий злоумышленника такова: перезвонить клиенту, подтвердить заказ и договориться о доставке. Вслед за этим путем нехитрых манипуляций распечатываются заказ, гарантийный талон и прочие сопроводительные документы, схожие с документацией нужного интернет-магазина, и осуществляется доставка. По статистике большинство людей не слишком внимательно изучает документы, концентрируясь на осмотре самого товара на предмет повреждений и работоспособности. Так что обман не требует больших усилий и является своего рода беспроигрышной схемой. Причем самое интересное в ней то, что клиент понимает, что что-то не так только при гарантийном обращении в интернет-магазин. Да и сам магазин понимает, что заказ у него украли тогда же.

Собственно интернет-магазин и обратился к нам за помощью как раз после нескольких зарегистрированных обращений. Для выявления утечки заказов было необходимо понять контрольные точки, откуда она может идти: из базы данных заказов, во время обработки заявки, либо непосредственно с интернет-сайта. К JSOC подключили базу данных, веб-сервер на уровне приложения и на уровне ОС.

Для этого в инфраструктуре клиента расположился сервер коннекторов HP ArcSight, был настроен необходимый уровень аудита на источниках и перенаправление событий на вышеуказанный сервер. База данных была подключена на уровне приложения: контроль таблиц и номеров заявок. Веб-сервер − на уровне приложения и мониторинга сетевой активности: контроль соединений, пакетов, запущенных на сервере процессов, служб, контроль изменения критичных файлов сервера. Далее с сервера коннекторов HP ArcSight информация по защищенному site-to-site (IPSec) соединению передавалась в ядро JSOC.

Общая архитектура подключения источников клиентов к JSOC выглядела и производилась следующим образом:

Рис. 1 Общая архитектура подключения к JSOC

Далее происходил мониторинг исходящей сетевой активности и подозрительной активности в БД.

Рис. 2 Контрольные точки мониторинга утечек информации с веб-сервера

Исходящая активность из интернет-магазина может осуществляться по нескольким направлениям:

• статистика, счетчики, компании-аналитики;
• рейтинги поисковиков;
• ссылки на сайты-партнеры.

Помимо указанной выше активности, с одной ноды была выявлена активность на заграничный облачный хостинг (на пограничном межсетевом экране ежедневно выявлялось несколько сотен исходящих соединений с веб-сервера на внешний IP-адрес), объяснение которому компания дать не смогла. Поэтому было предложено сравнить слепок веб-сайта этой ноды с эталонным. В результате сопоставления было выявлено два JavaScript, основной целью которых был перехват случайно выбранных заявок (в среднем 9−10 %) и пересылка их на внешний IP-адрес. Дальнейшее расследование остается за рамками данной статьи, но в качестве резюме следует отметить, что защита любого ключевого сервиса с помощью JSOC всегда начинается с работы наших бизнес-аналитиков – выявления, совместно с клиентом, точек возможной монетизации или вывода из строя ключевого приложения и дальнейшего профилирования активностей на нем.

Псевдополезное ПО

В интернете существует огромное количество программного обеспечения, предназначенного для ускорения работы компьютера, очистки реестра, удаления вирусов и ненужных программ, которые в действительности (совсем как пресловутые йогурты из рекламы) далеко «не одинаково полезны». Около 90 % программ такого класса тем или иным образом являются не только не полезными, но скорее даже «вредными». «Вредная» активность в лучшем случае заключается в огромном количестве рекламы, которым снабжает данное ПО пользователя, в худшем – чревато заражением машины, хищением персональных данных, шифрованием информации на компьютере.

И, прежде чем переходить к развязке данного инцидента, необходимо сказать пару слов в качестве предыстории. На этапе профилирования сетевых активностей клиентов, отдельно от остальной активности проводится профилирование соединений удаленного администрирования: с пограничных межсетевых экранов собирается информация о всех соединениях по управляющим портам (3389-RDP, 22-ssh, 23-Telnet, 6129-DameWare, 5800-VNC и другие) за 1−2 недели, после чего совместно с компанией-клиентом из данного списка выявляются нелегитимные подключения. Параллельно ведется выявление «админок» с помощью контроля запускаемых процессов на рабочих станциях и категоризации «User Agent» на межсетевом экране. Делается это в первую очередь для выявления потенциальных злоумышленников, которые нередко пользуются различными Remote Administration Tools.

Компании-клиенту предоставляется таблица следующего вида:

После этого клиент согласовывает ту активность, которая разрешена сотрудникам его компании.

При проведении аналогичного профилирования в рамках одного из подключений, компанией было сказано, что кроме VPN никакие средства доступа извне (удаленного администрирования) использоваться не должны. Для профилирования необходимо было отсеять огромное количество FP, в первую очередь от использования Skype и Torrent, которые были разрешены и иногда соединялись по портам менее 10000. В рамках данной активности были выявлены случаи использования TeamViever, Radmin, VNC и DameWare. Большинство активностей было ликвидировано после беседы сотрудников службы ИБ с персоналом. Вопрос вызывала лишь одна активность по порту 6129 (DameWare) от сотрудника службы технической эксплуатации продуктов. Активность была похожа на легитимную: происходила 1−2 раза в день в рабочее время на сервер в Екатеринбурге и напоминала взаимодействие ПО с центром разработки. Однако при дальнейшей проверке компьютера аналитик JSOC выявил дату начала данной активности. Она полностью совпадала с установкой на компьютер псевдополезной программы, которая подтянула за собой средство удаленного администрирования, парочку zero-day вирусов и продукт для монетизации трафика, который предлагает пользователю получить деньги за установку плагина на АРМ, а по факту компьютеры с установленным плагином продаются различным организациям и становятся частью ботнет-сети. Если же выясняются подробности расположения машины, ее принадлежность к каким-либо компаниям – она становится точкой входа злоумышленников в корпоративную сеть предприятия. К счастью, в данном случае этого не произошло.

Сотруднику срочно была «перезалита» машина, заменены пароли, средствами JSOC был произведен поиск установки аналогичного ПО в компании, а также с помощью сканера уязвимостей был произведен поиск по рабочим станциям и серверам компании следов распространения zero-day вируса, установленного данным ПО на компьютер сотрудника. Стоит отметить, что клиент отказался от создания списка разрешенного ПО на компьютерах сотрудников, тем самым замедлив выявление данного инцидента.

Профилирование активностей производится на начальном этапе подключения клиентов к JSOC и включает как профиль количественных показателей, так и качественных. Примером первых может служить число соединений на веб-сервер при доступе к файловому серверу, количество срабатываний антивируса в компании, увеличение трафика. Качественные показатели включают в себя IP-адреса, разрешенные для VPN-соединений, список учетных записей и рабочих станций, которым разрешены подключения к определенным приложениям и базам данных. Во время профилирования происходит заполнение Active List в ArcSight. Как только профиль заполнен, он согласовывается с клиентом, и любое дальнейшее отклонение будет считаться инцидентом. Данный способ выявления инцидентов не исключает ложных срабатываний, но в подавляющем большинстве случаев это оправданная мера для обеспечения защищенности компании.

Этот случай наглядно показывает, что профилирование как сетевых, так и локальных активностей является отличным средством выявления:

1. заражения zero-day вирусами, за счет взаимодействия с управляющими центрами и запусками нелегитимных процессов;
2. установкой различного «неполезного» ПО, в том числе позволяющего вести удаленное управление компьютером.

Инциденты в технологических сетях

Один из клиентов JSOC − крупная производственная компания. Ключевой ее посыл − недопущение инцидентов в сегменте АСУ ТП, являющийся, с точки зрения компании, «изолированной сетью, доступ в которую осуществляется лишь через компьютеры инженеров, инцидентов там быть не должно». Для обеспечения замкнутости АСУ ТП сегмента при отправке логов в JSOC был использован однонаправленный шлюз в корпоративный сегмент, откуда логи направлялись с сервера коннекторов в ядро JSOC по защищенному site-to-site соединению.

Для мониторинга появления новых машин в технологическом сегменте были заведены инциденты появления новых MAC-адресов, что говорит либо о замене MAC-адреса вручную, либо о замене сетевой карты, либо о появлении новой АРМ в АСУ ТП. Учитывая редкость первых и вторых событий, любой инцидент фактически говорил о нелегитимном действии со стороны персонала. Данная задача решалась с помощью выгрузки существующего списка MAC-адресов в Active List и дальнейшей сверки любого MAC-адреса с данным белым списком.

В течение нескольких дней с момента старта сервиса, специалисты JSOC зарегистрировали несколько инцидентов подключения в технологический сегмент, о которых было проинформировано высшее руководство компании. При расследовании было выявлено подключение ноутбуков из корпоративной сети в технологическую путем переключения сетевых кабелей. По словам сотрудников это было сделано «для удобства».

Для расширения точек контроля появления новых хостов были заведены инциденты появления новых имен компьютеров (способ реализации аналогичен вышеописанному с MAC-адресами). На следующий день после введения контроля имен рабочих станций была замечена сетевая активность в технологическом сегменте на рабочую станцию инженера (10.16.2.55) с неизвестной машины 10.16.2.188, resolve имени которой был «Home PC», которая не подпадала под правила именования хостов ни в одном из сегментов сети клиента. При расследовании данного срабатывания, сопоставлении фактов подключений и анализе логов аналитиками JSOC был выявлен шлюз, представляющий из себя машину с двумя интерфейсами, которая «одной ногой торчала» в технологический сегмент, а другой − в корпоративный.

Рис. 3 Схема подключения в сегмент АСУ ТП

На терминальном сервере был настроен NAT, происходило подключение по RDP по определенному порту (например, 13389), который «форвардил» машины в технологический сегмент. При этом каждый порт соответствовал машине в сегменте АСУ ТП. Появление имен рабочих станций из корпоративного сегмента (или домашних) происходило из-за особенности работы Windows, которая выполняла resolve имени того компьютера, с которого происходит подключение по RDP в локальных логах машины, на которую осуществляется вход. Сотрудник компании с домашнего компьютера подключился по VPN к терминальному серверу и пошел в сегмент АСУ ТП по RDP.

Администраторы и владельцы рабочих станций до последнего отказывались признавать наличие данного терминального сервера, так как вышестоящее руководство не знало о нем.

Так в чем же опасность соединения технологического сегмента с корпоративным? Векторов инцидентов существует несколько:

1. попадание вирусов с домашних компьютеров в технологический сегмент и дальнейшее распространение там;
2. подключение злоумышленников, попавших в корпоративный сегмент или на домашний компьютер, к сегменту АСУ ТП;
3. ошибка в работе инженера при удаленном управлении процессом.

Если говорить о производственной компании, инциденты в АСУ ТП могут привести к простою производства и значительным финансовым потерям, а в технологических сетях большего масштаба (напр. ГРЭС, ядерные центры, крупные заводы) и к человеческим жертвам в том числе.

Данный инцидент лишний раз доказывает, что «герметичность» любых критичных сегментов должна контролироваться наложенными средствами и инциденты, происходящие в них, должны иметь наивысший приоритет расследования.

Кредитный конвейер

Многие банки запускают для своих клиентов целевые программы кредитования на специальных условиях, и это тоже является потенциальной точкой мошенничества. У одного из наших клиентов несколько месяцев назад произошел инцидент, связанный с такой акцией. Процедура получения подобных кредитов обычно выглядит следующим образом: определенным клиентам банка приходит уведомление о предодобренном кредите на специальных условиях (обычно это скидка 2−3 % от базовой ставки). Клиент приходит в банк, сотрудник банка ставит галочку на заявлении «спецусловия», и далее запускается однозвенное согласование с руководителем отделения банка и клиент получает льготный кредит.

Однако у нашего клиента данная процедура согласования спустя какое-то время перешла в формальность. В итоге в некоторых региональных офисах пароль и учетная запись к программному продукту, в котором производилось согласование, просто сообщалась замещающим руководителя сотрудникам, которые, зачастую, являлись создателями кредитных договоров. Делалось это, например, во время отпуска руководителя, либо на постоянной основе, в силу занятости руководства отделений.

Сотрудники банка, оформляющие кредитные заявки, получили возможность сделать скидку любому желающему. В некоторых случаях это были родственники и друзья, а в других – посторонние лица, нуждающиеся в кредите. Последним-то, кстати, и предлагалась льготная программа кредитования за небольшое вознаграждение в размере 0,5−1 % от суммы кредита. Спустя какое-то время соответствующие объявления даже стали попадаться в интернете.

Рис. 4 Схема получения кредита по спецусловиям

С точки зрения конечной системы все было легитимно: одна учетная запись создавала заявку на кредит по спецусловиям, другая − согласовывала его выдачу. Однако JSOC, к которому по базовому профилю на уровне аутентификации был подключен кредитный конвейер, в результате простейшей корреляции, выявил аутентификацию под разными учетными записями с одной машины (один IP-адрес и имя). Служба безопасности, проанализировав данные инциденты и выявив слишком большую активность по льготным кредитам в нескольких отделениях, приняла решение по подключению системы кредитного конвейера на уровне самого приложения. Таким образом, аналитики JSOC увидели полную картину происходящего: логины под разными пользователями осуществлялись для создания и согласования льготных заявок на кредит.

Более подробная схема инцидента выглядит так:

1. подключение к системе работы с кредитными заявками с определенного IP-адреса (источник информации – межсетевой экран);
2. аутентификация под учетной записью сотрудника, оформляющего заявку (источник информации – кредитная система);
3. создание в системе новой заявки из-под учетной записью сотрудника, оформляющего заявку (источник информации – база данных кредитной системы);
4. выход из системы сотрудника, оформляющего заявку (источник информации – кредитная система);
5. подключение к системе работы с кредитными заявками с того же IP-адреса (источник информации – межсетевой экран);
6. аутентификация под учетной записью руководителя доп. офиса банка, согласующего заявку (источник информации – кредитная система);
7. согласование в системе только что созданной заявки из-под учетной записи руководителя доп. офиса (источник информации – база данных кредитной системы).

Итогом проведенного расследования стало обнаружение более 10 сотрудников по всей России, предлагающих льготные кредиты нецелевым клиентам банка. Совокупный ущерб от их деятельности составил свыше 300 нелегитимно выданных кредитов по спецусловиям. Трое из них одобрение спецусловий поставили на поток и создали 90 % всего ущерба для банка.

***

Подводя итог, хочется отдельно рассказать о процессе обследования инфраструктуры для создания сценариев инцидентов ИБ «под конкретного клиента». На первом этапе определяются критичные активы для компании – информация, деньги и способы их получения как сотрудниками, так и злоумышленниками извне. Далее происходит выделение критичных сотрудников, обладающих доступом к ценным активам, либо тех, кто наименее защищен (как, к примеру, специалисты call-центров, с одной стороны, имеющие слабое представление об ИБ, а с другой – обладающие немалыми привилегиями в корпоративной сети компании). Завершающий этап − приоритизация инцидентов совместно с экспертами компании-клиента. В этот момент типы инцидентов делятся на те, о которых необходимо сообщать (в том числе телефонными звонками) в любое время дня и ночи, и те, о которых достаточно предоставлять информацию в сводном еженедельном отчете для формирования понятия об общем уровне защищенности инфраструктуры клиента и т.п.

После прохождения данных этапов выделенный аналитик создает и наполняет пул сценариев (как имеющихся, так и новых, в том числе с учетом пожеланий клиента), заточенных под бизнес-процессы в компании, и запускает процесс профилирования сетевых и локальных активностей для понимания легитимности действий пользователей.

После окончания этапа профилирования и согласования всех инцидентов, происходит их запуск в продакшн и начинается круглосуточный мониторинг командой JSOC. При этом процесс подключения и профилирования занимает от 3-х недель до 1,5 месяцев в зависимости от количества систем, инцидентов и размеров организации.