Александр Русецкий: Если предлагать EDR всем подряд, то большинство его возможностей для заказчиков будет бесполезно

Александр Русецкий, руководитель направления защиты от направленных атак Центра информационной безопасности «Инфосистемы Джет» рассказал Anti-Malware.ru о внутреннем рынке Anti-APT, о том, какие EDR-решения чаще всего используются в России и как проверить реальную эффективность защиты от целевых атак.

Насколько востребованы средства защиты от целенаправленных атак в России? Какая наблюдается динамика — растет ли их популярность?

А. Р.: Мы начали активно работать с решениями класса Anti-APT, в т. ч. с песочницами как одним из базовых инструментов этого направления, в 2016 году. С того момента их востребованность, безусловно, выросла. Пик спроса мы фиксировали в 2018 году после массовой волны вирусов-шифровальщиков. Сегодня рост продолжается и даже превосходит большинство других направлений по ИБ, но аналогичного прошлогоднему скачка спроса мы не наблюдаем.

О популярности темы говорит и многообразие решений, предлагаемых вендорами: это могут быть и периметровая защита со шлюзами безопасности и подпиской на песочницу, и отдельные Anti-APT-решения в виде песочниц или сенсоров, и сервисы Threat Intelligence, позволяющие подгружать индикаторы компрометации, проводить расследования киберинцидентов и т. д.

В своей практике мы придерживаемся комплексного подхода. Он включает в себя периметровую защиту (NGFW, прокси и т. д.), мониторинг сети на основе NetFlow и защиту рабочих станций на базе продвинутого антивируса и EDR-решения. В качестве базового инструмента выступает песочница. Все это может работать комплексно — события записываются в логи, которые отправляются на SIEM-систему. Такие проекты для меня самые интересные, потому что они позволяют максимально раскрыть потенциал средств защиты.

Можно ли сказать, что на данный момент для крупных компаний в России уже де-факто стало стандартом иметь хотя бы песочницу для защиты от целевых атак? Как насчет EDR?

А. Р.: На конец 2018 — начало 2019 года песочница стала must-have-решением. Абсолютное большинство наших крупных заказчиков либо пилотируют песочницы, либо уже реализовали такой проект. Особенно это касается защиты почтового трафика как основного вектора атак.

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

Вообще многие игроки на российском рынке, к сожалению, EDR не до конца понимают и поэтому неправильно позиционируют. Мы предлагаем этот класс решений в основном высокотехнологичным компаниям с высоким уровнем зрелости ИБ, где с EDR будет работать не один-единственный безопасник, а полноценный отдел, который может своевременно принимать меры по реагированию на инциденты и проводить по ним расследования. Либо же должен использоваться аутсорсинговый сервис по эксплуатации системы. Если предлагать EDR всем подряд, то большинство функциональных возможностей решения будут для заказчиков бесполезными.

Выходит, подразумевается уровень зрелости ИБ именно в техническом плане?

А. Р.: Да. То есть sandbox — must-have, EDR — только для продвинутых компаний.

А контроль сетевого трафика?

А. Р.: Естественно, мониторинг трафика на внутренние и внешние аномалии осуществляется, но это тоже, по сути дела, один из источников. Опять же, здесь можно говорить и о периметровой защите в виде NGFW или безопасном прокси-сервере.

Можете ли вы сказать, что именно пользуется спросом, например, из числа песочниц — не обязательно именно у ваших клиентов, а в целом по рынку? Какие EDR можно выделить как чаще всего используемые?

А. Р.: Динамику можно проследить по нашим обзорам, которые мы начали выпускать с 2016 года. Так, в первом обзоре Anti-APT было 4 основных игрока: FireEye, Trend Micro Deep Discovery, Check Point SandBlast и Kaspersky Anti Targeted Attack Platform (KATA). В 2018 году, помимо перечисленных решений, мы включили в обзор также продукты FortiSandBox, Multiscanner и TDS. Другими словами, решения развиваются, и рынок растет.

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

Во-вторых, есть и другая ситуация: игроки присутствуют на российском рынке, и мне где-то раз в месяц поступают от них звонки и предложения из серии «давайте встретимся, мы вам привезли убийцу» — не буду говорить кого...

...всех!

А. Р.: Да. Я говорю им: «Приезжайте, рассказывайте». Они приезжают, мы, естественно, отсекаем маркетинг, т. к. его слишком много, и переходим к технике. Задаем буквально 3-4 вопроса, чтобы понять, о чем решение, как работает, и в итоге они берут все это на домашнюю проработку. К сожалению, у нас был негативный пример — представитель в России одного из «топов» Gartner уже два года готовится отвечать на наши дополнительные вопросы. Поэтому, с одной стороны, игроков много, но с другой — мы бы хотели видеть еще. И есть игроки, которые практически не известны в России по причине недостаточно высоких компетенций местных команд.

В части EDR на текущий момент игроков на рынке очень много. В нашем обзоре отметились cледующие продукты: FireEye HX, Cyberbit, Carbon Black Response, Check Point SandBlast Agent, Kaspersky EDR, Symantec EDR, Trend Micro Apex One. Мы составили довольно большую линейку, но опять-таки, если смотреть тот же Gartner, при выходе ряда игроков на рынок РФ этот список вполне может быть расширен.

Как заказчики подходят к выбору оптимальной системы защиты? Полагаются ли на ваш опыт как интегратора, или, возможно, тестируют сами?

А. Р.: Бывает так, что заказчик уже «словил» какой-то инцидент — например, пропустил фишинговое письмо, из-за которого атака прошла дальше. И тогда он обращается к нам напрямую, просит оперативно закрыть этот вопрос и предложить какое-то решение. Естественно, когда мы рекомендуем Anti-APT, то предлагаем его под конкретную инфраструктуру конкретной компании, а самое главное — под те задачи и критерии, которые она бы хотела закрыть.

Но бывает и так, что мы сами приходим к заказчику с идеей. Например, у него есть антивирус, но при этом мы понимаем, что его отдел реагирования достаточно сильный, что позволяет нам предложить ему продвинутую защиту на основе EDR. Такая практика тоже есть.

Например, был случай с одним заказчиком из промышленности. Я приехал на встречу с нашим обзором Anti-APT, и директор компании по информационной безопасности при мне открыл этот обзор и предложил «пробежаться» по интересующим его критериям. Что-то он вычеркивал... получилось, что мы в таком «шахматном» порядке пришли с ним к одному решению, которое после тестирования в итоге ушло в закупки — то есть пользователь, по сути дела, выбрал систему самостоятельно.

Иногда заказчики предпочитают тестировать сразу несколько решений в параллели, и тут в последнее время наблюдаются некоторые изменения. Так, еще два-три года назад в одном пилоте могли участвовать сразу несколько интеграторов. Заказчик предлагал свои критерии, мы — свои, все это компоновалось, и составлялась единая картина сравнения. Сегодня же компании часто делают выбор с одним интегратором и несколькими вендорами. У нас есть немало таких кейсов, когда все настройки и подключения выполняли специалисты производителей, а мы выступали в роли экспертов — вместе с заказчиком согласовывали схему тестирования, анализировали результаты и составляли критерии успешности. Например, в одном из случаев так было протестировано сразу 5 решений.

Интересная трансформация. Раньше ведь звучала критика, что интегратор приходит с конкретным продуктом, ему это выгодно, он ничего более не предлагает... Получается, на вашем примере этот подход и сама модель в целом становятся иными.

А. Р.: Да. Расскажу еще интересный пример из прошлого. Как-то мы приехали на Anti-APT-пресейл в один банк, заказчик сформулировал свои задачи, и мы сказали, что с их учетом готовы предложить несколько решений на выбор, перечислив плюсы каждого из них. Но когда мы спросили, на чем стоит остановиться для тестирования, заказчик ответил, что первое решение уже тестируется, второе тоже, и третье в том числе... В итоге нам осталось только одно из решений, и, скажу без лишней скромности, мы победили.

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

Получается, что вашу экспертную помощь можно назвать консалтингом на уровне пресейла. Он оплачивается отдельно или учитывается в составе проекта?

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

Защита от целевых атак — это сложная система, как проверить ее реальную эффективность?  

А. Р.: Действительно, выявить APT-атаку в ходе тестирования сложно. Я часто слышу на конференциях, как люди рассказывают, что в рамках одного пилота им удавалось поймать 5-10 APT-атак... В такое верится с трудом, потому что практически любой пилот по Anti-APT-решению проходит на каком-то определенном выбранном сегменте.

В рамках пилота появление какой-либо угрозы или аномалии в трафике носит вероятностный характер. Мы в подобной ситуации действуем так: ставим систему Anti-APT в режиме мониторинга на почту (на реальный трафик), т. к. она является основным вектором, подключаемся на SPAN, если это анализ веба, и проводим исследование на рабочем трафике. Обычно этот процесс занимает недели две; если тестируются конкурентные решения, то мы ставим их в параллели. Далее, если в процессе тестирования удается что-то обнаружить (обычно по почте прилетают разные шифровальщики, майнеры и прочее), то заказчик видит, что текущие средства защиты, будь то антиспам либо NGFW, не справились, и иногда ему этого достаточно. Есть заказчики, которые уже «схватили» какую-то угрозу, и им понятно, для чего нужно решение; они просто тестируют его и выбирают по функциональным возможностям нужный вариант. Есть еще и третий случай тестирования, когда дополнительно мы предлагаем использовать семплы. Это, по сути дела, синтетика, не вполне настоящие вредоносы. Зато данный подход позволяет быстро посмотреть, как работают решения в различных режимах и ситуациях.

Это такой синтетический тест на наборе семплов?

А. Р.: Да. Есть три варианта тестовых семплов. Первый — заказчик самостоятельно, через свой ИТ/ИБ-отдел, запускает различные семплы, механизмы, технику и т. д. и проверяет все это в песочнице — сейчас большинство решений поддерживают и ручную загрузку, и возможность отправки по почте. Второй вариант — мы как интегратор используем различные собственные базы с доработками, отправляем файлы, письма с архивами, ссылками на проверку и опять же смотрим, как отработали решения. Третий подход — мы называем его «вендорским» — состоит в том, что каждый из вендоров тестируемых решений отправляет свой пул семплов. В итоге на основании результатов анализа и реального трафика, и семплов выносится вердикт о выборе. В российской действительности немалую роль в этом процессе также играет и стоимость решения, от этого тоже никуда не уйти.

Наверное, описанный подход наиболее эффективен для оценки песочниц. А как оценить, например, комплексную систему Anti-APT или ту же EDR? Ведь атака — это не семпл, ее трудно обнаружить «напрямую», нужно искать аномалии.

А. Р.: Да, но опять же, при анализе на основании того же NetFlow вешается проверка на SPAN, информация собирается месяц, а то и два; естественно, решения работают и в претесте, и в режиме мониторинга, мы по умолчанию связываем их с SIEM-системой и в процессе анализа просто смотрим, что происходит. Уверяю вас, аномалии выявляются. Это может быть не целевая, а массовая атака, но следы мы увидим, если, например, сенсор подключен к корневому маршрутизатору. Чем качественнее подключим, тем более полным будет результат.

Если говорить о EDR, ситуация следующая: есть решения, которые производители предлагают испытывать в облаке, — подгружать туда различные семплы и смотреть, как отрабатывает продукт. С точки зрения продаж это отлично, поскольку мы можем буквально в течение дня показать заказчику функциональность, не вкладываясь сильно в пресейл. Но самим заказчикам это зачастую не особо интересно, потому что им важно посмотреть, как EDR будет работать с другими агентами на рабочей станции (антивирусом, DLP и т. д.). Для решения этой задачи EDR, как правило, разворачивают на нескольких виртуальных машинах. Если угроза не будет заблокирована на уровне антивируса, мы сможем увидеть реальную эффективность системы: как она отреагирует и как быстро передаст информацию на сервер. А совместимость агентов при этом проверяется на реальной рабочей станции.

Существует много разных критериев выбора: некоторые заказчики отслеживают время реакции и передачи информации об инциденте на сервер, так как для них критично, чтобы группа реагирования могла сразу вмешаться; есть мультиплатформенность как ключевой критерий, ведь многие топ-менеджеры сидят на «маках», и поэтому компаниям нужна поддержка и macOS, и Windows, и Linux. VDI-агенты и поддержка виртуальных рабочих мест сейчас тоже очень актуальны: многие банки переходят на виртуализацию, и им требуются агенты, способные реагировать на ту или иную угрозу. Это также отрабатывается на этапе пилота.

Естественно, при тестировании решений мы всегда готовы помочь и с интеграцией. Например, в одном из случаев мы внедряли Anti-APT-решение в режиме мониторинга с тикет-системой, и админы в реальном времени получали тикет на конкретный алерт и начинали быстро принимать меры — потому что во время пилота тестируемый продукт, повторюсь, только наблюдает, и если по почте, например, придет шифровальщик, то песочница его, конечно, обнаружит, но он все равно попадет на рабочую станцию.

За 1-2 месяца пилота можно гарантированно увидеть эффективность Anti-APT-решения?

А. Р.: Если грамотно подойти к выбору места для подключения, можно увидеть угрозы, которые пропустили текущие средства защиты. Если говорить именно о целевой атаке, то, в зависимости от подключения и снятия информации с того или иного сенсора, мы, вероятнее всего, увидим ее артефакты. Например, это могут быть попытки обращений к вредоносным, фишинговым и URL-адресам, замеченным ранее в целенаправленных атаках.

К тому же в конечном итоге мы упираемся в вопрос о том, что именно считать целевой атакой. В широком смысле, уникальный шифровальщик, собранный для конкретной жертвы, тоже может рассматриваться как APT.

А. Р.: Конечно. Кстати, появление шифровальщика может быть и началом замаскированной атаки, на которую заказчик не обратил внимания — а в это время у него увели денежные средства.

Какие сложности и типичные ошибки в выборе систем защиты от APT? Возможно, есть какие-то яркие примеры?

А. Р.: Anti-APT-решение обязательно должно тестироваться в инфраструктуре заказчика. Демонстрации на отдельных стендах у вендоров, интеграторов и дистрибьюторов — это, по сути дела, просто красивая картинка. Если вы выбираете решение, его обязательно нужно поставить и протестировать у себя. Естественно, исходя из задач, можно прийти к одному решению; но обычно тестируется несколько продуктов в параллели, как я уже рассказывал, и на основании созданной таблицы критериев делается выбор.

По поводу ошибок — одним из краеугольных камней является расшифровка SSL. Несмотря на то, что объемы зашифрованного веб-трафика постоянно увеличиваются, многие до сих пор не инспектируют SSL на скрытые угрозы и аномалии. Поэтому обязательно требуется устройство для расшифровки SSL, даже во время пилота. И когда с заказчиком обсуждается тестирование веб-трафика, этот момент стоит очень остро. Кто-то готов отдать со шлюза, кто-то с прокси, а кто-то не готов отдавать — и тут мы можем привезти свою «железку» или «виртуалку» и поставить в разрыв. Однако здесь снова возникают серьезные препятствия: нужны согласования и со стороны ИБ-, и со стороны ИТ-отдела. Это может затянуться на несколько месяцев. Но без расшифровки всегда есть очень большой риск вообще ничего не показать, поэтому мы стараемся в таких пилотах не участвовать, чтобы не терять время впустую.

Помимо этого, бывают ситуации, когда заказчик ставит решение и никак его не мониторит, что тоже неправильно. Такое часто происходит, когда в компании не налажено эффективное взаимодействие ИТ- и ИБ-отделов. У нас были случаи — руководство ставило задачу протестировать решение, «безопасники» согласовывали пилот, но айтишникам это было не очень интересно или они просто об этом не знали, что сильно затягивало процесс. Чтобы исключить подобные сценарии и провести тестирование максимально «бесшовно», мы всегда стараемся выезжать на наши пилоты, знакомимся и общаемся не только с ИБ-, но и с ИТ-отделами.

Были ли случаи, когда почти сразу удавалось показать эффективность таких систем уже на стадии пилота?

А. Р.: В одном из первых пилотов мы поставили песочницу в финансовой организации на почтовый трафик в режиме мониторинга. Прилетел шифровальщик, система его задетектировала и отправила алерт. Текущие средства защиты пропустили зловред. Так как это был вечер пятницы, пользователь не открыл его на рабочей станции, и в понедельник коллеги быстро все поправили. В случае установки в продуктив песочница бы заблокировала прохождение такого письма.

Задумываются ли заказчики об экономической эффективности внедрения таких систем, делается ли расчет ROI?

А. Р.: Есть заказчики, которые уже пострадали от какой-то угрозы, потеряли денежные средства или значимую информацию и поэтому могут просчитать риски. Второй вариант — когда задача приходит от бизнеса по принципу: «Вася и Петя уже внедрили, почему этого нет у нас?» В таких случаях денежные средства тоже выделяются, и вопросов здесь обычно не возникает. Но есть третья группа, с которой действительно надо работать, доказывать целесообразность, и она достаточно большая.

Есть ли какие-то технические или регуляторные особенности внедрения систем защиты от целенаправленных атак в России?

А. Р.: Да. На сегодняшний день, общаясь с вендорами, мы заметили следующую тенденцию: все по максимуму уходят в облака. Это касается и Anti-APT в целом, и тех же EDR в частности. В облаке все анализируется, и при необходимости можно подключить центр реагирования. Но в России с этим все гораздо сложнее. Все чаще на пилотах мы сталкиваемся с ситуацией, когда заказчик говорит, что ему необходима «приватная база обновлений». Грубо говоря, хеши, обновления и прочее прилетают в некую «коробку», и оттуда уже идет распространение на рабочие станции, или с этого локального сервера запрашиваются хеши файлов. С этим мы столкнулись при пилотировании не только песочниц, но и EDR. Банки сейчас выдвигают такое условие — приватная база обновлений без передачи данных вовне. Соответствующая возможность становится одним из критериев выбора.

А зарубежные вендоры готовы на такое идти?

А. Р.: Да. Большинство зарубежных вендоров идут навстречу. У финансовых организаций популярна также рассылка индикаторов компрометации ФинЦЕРТ, и мы столкнулись с тем, что не все EDR-агенты могут их читать (формат JSON). Действительно, есть решения, которые до сих пор «в лоб» не умеют этого делать. В некоторых случаях нам приходилось писать парсер вместе с вендорами, но каждый производитель, у которого возникла такая проблема, предоставил обновления, и мы теперь ФинЦЕРТ в принципе читаем.

Кроме того, различные госучреждения требуют сертификации. В общем, своя специфика действительно существует, и каждый вендор справляется с этим по-своему: кто-то получает сертификат, кто-то открывает локальное производство, кто-то размещает локальное облако в России, кто-то обновляет и выпускает приватную базу. Так что многие подстраиваются, хотя есть и вендоры, которые наш рынок не считают для себя актуальным и продолжают работать «как есть».

Если продолжить тему взаимодействия с регуляторами: я знаю, что некоторые Anti-APT-решения уже имеют или прорабатывают возможность напрямую отправлять информацию в центры ГосСОПКА. Эта функциональность на данный момент востребована, или это скорее экзотика?

А. Р.: Я скажу так: она набирает популярность. Во-первых, теперь это требование регуляторов, и в том или ином виде передача данных будет осуществляться. У компаний есть варианты: они могут отправлять данные сразу в ГосСОПКА или делать это через корпоративные центры, такой, например, мы сейчас создаем на базе нашего Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT.

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

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

А. Р.: Большинство вендоров добавляет машинное обучение или искусственный интеллект в свои решения. Это касается в том числе и песочниц, и EDR-агентов. Но тут следует пояснить, что, во-первых, тому же машинному обучению требуется время, и мы можем получить довольно большое число ложных срабатываний. С другой стороны, ИИ и ML — это лишь один из механизмов помощи в обнаружении угроз, в дополнение к антивирусу, статическому, динамическому и поведенческому анализу. То есть полагаться полностью на эти технологии сейчас, конечно, никто не будет.

У нас недавно вышел обзор deception-решений: продвинутый вариант ханипотов, позволяющий обнаруживать и целевые атаки в том числе. Насколько активно используется этот класс решений и ловушки вообще? Каков их потенциал на данный момент?

А. Р.: Здесь складывается парадоксальная ситуация. Ханипоты были известны и 3, и 5 лет назад, тогда они начинали движение вверх, но затем произошел серьезный спад. Сегодня мы наблюдаем очень большой рост. По сути, это сигнализация, «кнопка» в сети, которая предупреждает о том, что идет атака и нужно срочно принять меры. Мы расширили свой портфель решений — у нас есть несколько протестированных вариантов (например, TrapX) — и активно развиваем эту тему, в том числе в рамках Anti-APT-решений. Недавно у нас был пилот, на котором мы интегрировали ханипот с EDR и показали заказчику такую интересную схему. Фактически это хорошо забытое старое, сейчас многие вендоры прорабатывают эту тему и добавляют ханипоты в продуктовые линейки, хотя при желании их можно создать и самостоятельно.

Спасибо за интервью! Желаем успехов.