Евгений Гончаров: до 4 млн промышленных устройств по всему миру используют уязвимый фреймворк CODESYS

Евгений Гончаров: до 4 млн промышленных устройств по всему миру используют уязвимый фреймворк CODESYS

Евгений Гончаров

15 лет занимается информационной безопасностью.

В «Лаборатории Касперского», где работает с 2007 года,  руководил разработкой нескольких продуктов и сервисов, возглавлял команду защиты инфраструктуры Олимпийских Игр Сочи 2014.

С 2014 года занимается различными задачами защиты промышленных предприятий, и с 2016 года руководит командой исследования угроз и реагирования на инциденты промышленных информационных систем Kapsersky Industrial Control Systems Cyber Emergency Response Team (Kaspersky ICS CERT).

...

На прошедшей конференции Kaspersky Industrial CyberSecurity Conference 2019 Евгений Гончаров, руководитель Kaspersky ICS CERT, рассказал об основных целях и результатах работы его подразделения, о громких уязвимостях в программном обеспечении для промышленных систем и о результатах новых исследований.

Хотелось бы начать интервью со следующего вопроса: зачем «Лаборатории Касперского» понадобился ICS CERT, и откуда появилась идея создания этого подразделения?

Е.Г.: Когда мы занялись промышленной безопасностью, в какой-то момент поняли, что продвижение наших продуктов и сервисов на рынке наталкивается на некоторое непонимание того, зачем это нужно, со стороны разных индустрий. И, как оказалось, представление людей о ландшафте угроз для промышленных предприятий было в лучшем случае основано на публикациях об атаках типа Stuxnet на тематических сайтах и на появлявшихся время от времени в СМИ различных, часто спекулятивных, новостях об инцидентах, произошедших на промышленных объектах. К сожалению, промышленные предприятия, в гораздо большей степени, чем какие-либо другие, очень ревниво относятся к информации о проблемах и происшествиях, с которыми они сталкиваются. Достоверной можно, пожалуй, назвать только информацию от исследователей технических средств, использованных в атаках. Но её совсем немного (такие средства попадают в руки экспертов крайне редко), она суха и сложна для прочтения и понимания неспециалистами, а по тем часто недостоверным и искажённым сведениям, которые просачиваются через медиа, судить о том, что происходит на самом деле, и что угрожает промышленным объектам, крайне сложно.

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

Источники информации, которыми располагает Kaspersky ICS CERT, — это только данные телеметрии продуктов «Лаборатории Касперского», или что-то ещё? Есть ли какой-то информационный обмен?

Е.Г.: Одним из основных источников данных о ландшафте угроз являются данные телеметрии, поступающие от наших клиентов. Честно говоря, здесь нет ничего уникального. Данные, которые мы получаем через Kaspersky Security Network, являются основным источником информации, которую «Лаборатория Касперского» использует, чтобы обнаруживать новые угрозы, включая новые целевые атаки и APT в других областях и отраслях, например, в финансовом секторе.

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

Меня лично всегда интересовал такой вопрос. Допустим, у вас есть некоторое количество исследователей. Как вы определяете, каким софтом или какими системами заняться с точки зрения анализа и провести исследование их защищенности? С позиции вендора (например, АСУ ТП) это может выглядеть странно: по непонятным мотивам «Лаборатория Касперского» взяла и стала «ковырять» наши продукты. Мы хорошо жили, существовала некая безопасность по незнанию, а потом пришли какие-то белые хакеры и всё испортили.

Е.Г.: Красно-зеленые (смеется). Отчасти эта картина может быть близкой к реальности, по крайней мере, какой она была несколько лет назад. Действительно, многие производители систем промышленной автоматизации, промышленного интернета вещей первое время «в штыки» воспринимали результаты наших исследований, думали, что мы пытаемся не то чтобы их очернить, но по крайней мере использовать их имя для создания репутации себе. Это было весьма далеко от правды. Продукты для исследований выбирались очень просто: мы исходили из потребностей клиентов. Всякий раз, когда мы шли выполнять пентест, мы выясняли, какие системы автоматизации для клиента являются наиболее серьезными и важными, какие продукты там стоят, и в его интересах исследовали состояние безопасности именно этих продуктов. Соответственно, важным фактором является распространённость продукта или технологий. Существует много общих технологий, которые мы встречаем в продуктах большого количества наших клиентов. Это, например, фреймворки для создания ПЛК (программируемых логических контроллеров), средства контроля лицензионных ограничений, средства удалённого администрирования, другие компоненты, которые используются в большом количестве систем автоматизации и не только. Для нас это – важный предмет исследования: во-первых, потому, что уязвимости в них сразу оказывают влияние на состояние безопасности большого количества продуктов и инсталляций наших клиентов, а во-вторых, потому, что разработчики таких технологий часто не в состоянии самостоятельно скоординировать исправление уязвимостей во всех использующих их продуктах.

Мы видим то же самое и в обычном софте для корпоративных задач, когда уязвимость в одном из программных компонентов может использоваться для атаки на «цепочку поставки» или «цепочку разработки». Например, как было в OpenSSH.

Е.Г.: Мы как-то исследовали продукты нескольких вендоров систем автоматизации и обнаружили, что они имеют общий компонент, используемый в подсистеме лицензирования. Стали исследовать его, обнаружили некое количество уязвимостей, а потом поняли, что это — крайне распространённая технология. Ей пользовалось на тот момент, по самым скромным оценкам, больше 40 000 вендоров по всему миру. Так что масштаб бедствия, действительно, сравним с OpenSSH. Потом у нас было подобное исследование по OPC UA. Дело в том, что мы являемся членами OPC Foundation и участниками Security Working Group, которая занимается безопасностью стандарта. Мы посчитали, что должны внести свою лепту, и сделали исследование состояния стека протоколов OPC UA на тот момент — нашли несколько уязвимостей, помогли с координацией их исправления и написали соответствующую статью. Затем был ещё ряд подобных историй. В сентябре у нас вышло новое исследование об уязвимостях в CODESYS Runtime. К счастью, уязвимости исправлены, и соответствующие два патча уже выпущены, но масштаб бедствия до сих пор сложно оценить, потому что это — одна из технологий, которые используются очень большим количеством организаций-разработчиков ПЛК и прочих продуктов для промышленной автоматизации и промышленного интернета вещей.

CODESYS — это библиотека?

Е.Г.: Это целый фреймворк, который используется для создания ПЛК. Для того чтобы вендор ПЛК мог свою «железку» превратить в финальный продукт, чтобы программируемый логический контроллер, собственно, стал программируемым, и для него можно было написать программу на одном из стандартизованных языков, существует вот такой, пожалуй, самый распространённый фреймворк — CODESYS Runtime. И если верить информации на сайте производителя, то сейчас порядка 400 вендоров используют это решение для разработки продуктов ПЛК и других систем промышленной автоматизации. Это – около 4 млн устройств по всему миру, внутри которых есть этот самый фреймворк. Вот ещё один пример нашего вклада в безопасность большого количества продуктов.

Как происходит раскрытие информации о серьёзной уязвимости? Оповещаются производители? Их же много, всех тяжело оповестить. Всегда ли это публикуется у вас на сайте, и в какой момент это происходит?

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

Когда производитель готов к тому, чтобы эту информацию оглашать, мы выходим с публикацией: иногда с одной совместно с вендором, иногда с двумя согласованными и так далее. Когда случаются истории, похожие на ту, что я описывал — с уязвимостями в общих технологиях, — ситуация может быть намного сложнее. Иногда бывает так, что все конечные потребители этих технологий не известны ни нам, ни вендору. Иногда оказывается, что цепочки поставки весьма сложны, а коммуникационные каналы с клиентами у вендора налажены неидеально. В таких случаях мы совместно можем принять решение о том, чтобы просто уведомить превентивно все сообщество разработчиков, сообщив им, что в такой-то технологии есть такая-то уязвимость — она уже к этому моменту исправлена разработчиком, и всем надо перейти на новую версию. К сожалению, такая проблема не может быть решена в одночасье, и мы видим, что информация по различным каналам до конечных потребителей, то есть других вендоров, которые используют эти технологии, может добираться месяцы и даже годы. Например, по некоторым уязвимостям мы обнаруживаем, что уже три года прошло, но все еще есть вендоры, которые не обновили в своих продуктах уязвимые компоненты. Разумеется, всякий раз, когда мы сталкиваемся с такой ситуацией, мы сообщаем о ней вендору и ждём (либо со всей настойчивостью добиваемся) исправления уязвимостей прежде, чем опубликовать что-то по их поводу. Мы не можем и не хотим позволить себе алгоритмы поведения, которые взяли себе за правило некоторые другие команды исследователей, считающие, что вендор, не обновивший в своём продукте уязвимый компонент, поступает тем самым безответственно, и выходящие с публикацией спокойно, никого ни о чём не уведомляя. Конечно, нам приходится подобное делать в тех случаях, когда вендор осознанно и безосновательно пренебрегает безопасностью своих (и наших) клиентов, например, отказываясь исправлять уязвимость или даже её признавать. Но такие случаи в мире разработчиков систем промышленной автоматизации, к счастью, уже стали очень редки. Хотя, к сожалению, они всё ещё часто встречаются в других областях, например, среди производителей автомобилей. Но это – уже совсем другая история.

Всё ранее сказанное в принципе очень хорошо согласуется с миссией «Лаборатории Касперского» — сделать мир более безопасным. А что касается коммерческих услуг, на чем зарабатывает CERT? Какие услуги он оказывает на данный момент?

Е.Г.: Мы действительно предоставляем в том числе и коммерческие сервисы, которые требуют нашего вовлечения в проект с каким-то конкретным клиентом. Например, проведение тренингов в рамках Kaspersky Industrial CyberSecurity — это наша забота. Мы тренируем и ИТ-специалистов (инженеров, операторов), и специалистов информационной безопасности, одних – тому, как правильно себя вести на предприятии, чтобы не подвергнуть его риску киберинцидента, других - как осуществлять деятельность по обеспечению безопасности именно промышленной инфраструктуры наиболее эффективно и без рисков, что уже меры безопасности повредят его работе. У нас есть и другие услуги. Например, мы занимаемся сервисами incident response, когда речь идёт об инцидентах, которые касаются технологических сетей промышленных предприятий. Мы делаем то, что называется «tailored research» — заказные исследования по ландшафту угроз или по каким-то конкретным угрозам, которые специфичны для определенной отрасли, группы предприятий или страны в целом. Мы готовим коммерческие отчеты, которые идут в нашу платформу Threat Intelligence Portal, а также фиды — результаты нашей работы по обнаружению атак и уязвимостей, доступные для встраивания крупным организациям или сервисным командам, SOC-ам, или же другим производителям решений по информационной безопасности, у которых не такой хороший фут-принт с точки зрения количества клиентов и телеметрии.

Эти фиды у вас можно купить?

Е.Г.: Да, эти фиды у нас можно купить. Кстати, на выставочной части Kaspersky Industrial CyberSecurity Conference некоторые из партнёров уже демонстрируют интегрированные фиды. В частности, компания «Инфосистемы Джет» использует их в своем Jet CSIRT.

Хотел бы ещё узнать немного больше подробностей: сегодня была анонсирована услуга Kaspersky ICS Vulnerabilities Database, которая будет доступна к концу года. Что это за услуга? Кто сможет ей воспользоваться? На кого она ориентирована?

Е.Г.: Это — довольно простая концепция. Для того чтобы осуществлять постоянный мониторинг состояния безопасности промышленного предприятия, нужно это делать, к сожалению или к счастью, пассивными методами. Активно опрашивать промышленные устройства – не совсем безопасно, это может иногда приводить к плохим для них последствиям. Соответственно, оценка состояния весьма сильно усложнена с технической точки зрения, потому что нужно с достаточной точностью сформировать список версий продуктов, которые подвержены какой-либо уязвимости в той или иной степени. Также нужно понять, для каких из этих версий существуют решения: для некоторых доступны патчи, для других — проработанные и согласованные с вендором дополнительные меры безопасности, третьи версии по каким-то причинам не покрыты ни патчами, ни дополнительными мерами защиты, и для них тоже нужно что-то предложить. Это — большая интеллектуальная работа, которую нужно проделать. Мы проанализировали информацию об уязвимостях, которая доступна в публичных источниках: чаще всего она агрегирована с сайтов вендоров и частично адаптирована, то есть «причёсан» формат, сделаны косметические изменения, выполнен перевод с одного языка на другой. При этом, хотя в целом первоисточником всегда являются сайты производителей, оказывается, что даже те вендоры, которые тратят на информационную безопасность максимальное количество ресурсов, времени, сил, которые уже видят в этом перспективы даже для нового направления бизнеса, тем не менее, все ещё недостаточно аккуратны при публикации такой информации. Ошибки могут быть очень значительными. Если измерять в количестве версий продуктов, подверженных той или иной уязвимости, то ошибка, которая появляется при прямом прочтении сайта вендора, по сравнению с реальной картиной может составлять порядки.

Т.е. кто-то что-то недоговаривает?

Е.Г.: Не обязательно. Отклонения могут быть как в одну сторону, так и в другую. Были, например, случаи, когда из 107 продуктов вендора, про которые он написал, что они как будто уязвимы, реально уязвимы только 10, а ещё есть 19 других, которые вендор забыл упомянуть.

Возвращаясь к сказанному ранее: всё это — довольно интеллектуальная работа. Ее можно автоматизировать, и мы это делаем, но она требует некоторых ресурсов. Мы решили эти ресурсы потратить для такой благородной задачи и представить новый сервис. Конечно, Kaspersky ICS Vulnerabilities Database будет также предоставлять информацию и о тех уязвимостях, которые мы сами обнаружили, которые когда-то были уязвимостями нулевого дня, о которых мы сообщили вендорам, и в том числе — об изъянах в компонентах общего назначения, используемых большим количеством производителей. Соответственно, встаёт существенная задача — понять, какие продукты каких вендоров этим уязвимостям подвержены. Мы посчитали, что такая работа должна быть сделана, и мы уверены, что она будет востребованной нашими потенциальными клиентами. Во-первых, это, конечно, крупные промышленные организации. Многие из них в соответствии с требованиями регуляторов периодически обязаны делать пересмотр состояния безопасности своей инфраструктуры или даже на постоянной основе отслеживать информацию о появлении новых уязвимостей. Некоторые из них сами для себя сформулировали такую необходимость в виде требований и внутренних процессов. Во-вторых, это — сервисные команды, которые предоставляют услуги managed security-сервисов или услуги SOC-ов, а также национальные команды реагирования на инциденты, типа CERT. И в-третьих, это — разработчики продуктов по информационной безопасности, которые нуждаются в такой дополнительной экспертизе от нас.

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

Е.Г.: В принципе, это очень актуальный вопрос, на который у экспертов по информационной безопасности пока нет однозначного ответа. В целом, когда оказываются услуги по тестированию на проникновение или по оценке состояния ИБ, команда исследователей обычно использует информацию об уязвимостях, которые ещё не исправлены вендорами. Для этого есть причина. Мы должны работать в интересах потребителей: законный пользователь продукта вправе знать об объективных оценках состояния его безопасности. Скрывать эту информацию от потребителя мы не можем. С другой стороны, не можем мы и раскрывать некоторые детали, которые могут повредить процессу исправления этих изъянов либо навести злоумышленников на идею использовать описываемые уязвимости. К этому вопросу нужно подходить очень аккуратно: дать возможность клиенту узнать о проблеме и оценить её важность, но не раскрыть достаточного количества деталей, чтобы кто-нибудь смог её эксплуатировать. К тому же, всё должно происходить по согласованию с вендором продукта, потому что у них тоже могут быть свои причины раскрывать или не раскрывать сведения. В общем, это — сложный вопрос. Да, такая информация в нашей базе будет содержаться, но возможно, что она будет предоставляться по некоторым специальным условиям: для того, чтобы получить информацию об уязвимости в каком-то продукте, нам нужно убедиться, что обратившаяся к нам организация является его законным владельцем. По крайней мере, клиент, обратившийся за такой информацией, должен обосновать своё право её получить.

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

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

В случае с технологическими сетями и промышленным оборудованием дополнительная сложность заключается в том, что очень трудно их обновлять: просто так не остановишь, не «накатишь» новую прошивку. Здесь встаёт вопрос: каким может быть разрыв между обнаружением и закрытием уязвимости?

Е.Г.: На самом деле, есть очень много разрывов: разрыв между обнаружением и выпуском исправления вендором, между исправлением уязвимости в общей технологии и исправлением всех продуктов, которые используют эту технологию. Следующая серьезная задача для владельцев продуктов — обнаружить у себя в инфраструктуре наличие уязвимых версий этих продуктов, потому что большинство предприятий развиваются эволюционно, иногда покупают активы других компаний и т.д. Полного инвентаря всего оборудования, тем более с точностью до версий продуктов, часто не бывает. И, конечно же, та проблема, о которой Вы сказали — попробовать и перейти на новую версию не всегда возможно из-за проблем совместимости, из-за некоторых ограничений, характерных для данной индустрии или производства, для данной технологической линии. К сожалению, патч-менеджмент для промышленных предприятий — это не всегда установка патча, это ещё и в большей степени применение компенсационных мер (закрытие портов на фаерволе или использование других специальных средств). Но самое важное здесь — то, что предприятие должно узнать о существовании проблемы и принять какое-то осознанное решение по её поводу, а не выбирать «страусиную» стратегию: «пока я не знаю о проблеме, её для меня не существует».

Kaspersky ICS CERT подготовил новый отчет о защищенности промышленных систем. Можете ли Вы изложить какие-то основные итоги, выводы из этого отчета? Что кардинально изменилось в ландшафте угроз за прошедший год?

Е.Г.: Прямо-таки кардинальных изменений, где что-то вдруг перевернулось с ног на голову, не бывало как будто и раньше. Однако, несомненно, есть довольно много интересных наблюдений, которыми нам хотелось поделиться с сообществом. Во-первых, есть динамика, и мы видим некую устойчивость этой динамики. Наблюдается небольшой, но всё-таки рост доли компьютеров в промышленной автоматизации, которые были атакованы за отчётный период. Мы немного углубились в изучение ландшафта угроз для некоторых конкретных индустрий, например, для энергетики, и рассказали о важных, с нашей точки зрения, находках в этой области. В отчёте мы попытались ответить на вопрос о том, как объяснить то, что мы видим. Почему в одних странах мы наблюдаем больший процент компьютеров, подверженных атакам, а в других странах — меньший? Почему в той стране вредоносная активность в большей степени затрагивает одни индустрии, а в этой — другие? Также мы стремились разобраться в факторах, которые оказывают наиболее существенное влияние на ландшафт угроз для промышленных систем автоматизации на уровне страны. В первую очередь мы пытались понять, как различные типы вредоносного программного обеспечения, которое распространено в той или иной стране, оказывают влияние на состояние промышленной безопасности. В частности, мы коснулись влияния самостоятельно распространяющегося программного обеспечения в конкретной стране, а также попытались обнаружить и другие закономерности.

Какие страны и индустрии наиболее подвержены этой зависимости?

Е.Г.: Если посмотреть по странам, то мы ещё в прошлом отчёте писали, что есть статистическая зависимость между уровнем дохода в стране на душу населения и процентом компьютеров в промышленности, которые подвергаются атакам. Попытались копнуть глубже и обнаружили, что рейтинг стран, где промышленные компьютеры атакуются наиболее часто, возглавляют государства, которые активно развиваются и становятся основными фабриками планеты, на которых производится всё больше и больше различных товаров потребления. С другой стороны, мы выяснили, что есть корреляция между общим вредоносным фоном в стране и тем, как часто атакуются компьютеры в корпоративной среде и в промышленных сетях. Там было несколько довольно неожиданных находок. Я советую с этим материалом ознакомиться. Мне кажется, что это будет интересно многим: глобальным и просто крупным компаниям, государственным регуляторам и просто сообществу исследователей.

По вертикалям кто сейчас наиболее подвержен атакам?

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

За годы существования Kaspersky ICS CERT увидели ли Вы какие-то положительные изменения в восприятии потенциальными заказчиками важности защиты промышленных систем?

Е.Г.: Можно говорить о том, что в среднем появилось осознание важности проблемы или, как минимум, признание ее существования. Это видно и по статистическим данным, и по результатам опросов, и по тому, насколько активизировались разные работы над коммерческими продуктами и сервисами. И сами промышленные организации, и транспортные и логистические компании, и производители продуктов для систем автоматизации этой темой не просто заинтересовались, а занялись вплотную. Разрабатываются и внедряются решения, проектов весьма много. То есть обеспечение безопасности, совсем недавно бывшее только дискуссионной темой, сейчас для очень многих, если не для большинства промышленных организаций, стало частью повседневной жизни.

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