Железный ад
Автор
Илья Медведовский
Уровень зрелости подавляющего большинства вендоров промышленной автоматики по отношению к ИБ близок к нулю.
С 2010-го года теме информационной безопасности АСУ ТП обеспечено повышенное внимание. Попробуем выяснить, насколько далеко за минувшее время удалось продвинуться в решении проблем и в чем же основные практические трудности обеспечения информационной безопасности промышленных систем.
У семи нянек дитя без глазу
Начнем с того, кто должен заниматься решением этого вопроса. Традиционно АСУ ТП находится в ведении инженеров, специалистов по промышленной автоматике. За последние десятилетия вектор развития таких систем давно сместился от механических, электромеханических и релейных устройств к сложным промышленным сетям, буквально пронизанным современными информационными технологиями, в том числе и на базе семейства IP-протоколов. А потому сегодняшняя АСУ ТП является сложнейшим многоуровневым инженерным комплексом, в котором предусмотрено все — от исполнительных механизмов и датчиков на нижнем уровне до систем визуализации и управления на верхнем.
И здесь возникает первая проблема. С одной стороны, инженеры и проектировщики АСУ ТП прекрасно знают специфику самих систем с технологической точки зрения, но не очень представляют, что же такое информационная безопасность — они не профессионалы в данной сфере и не должны ими быть. С другой — специалистам по ИБ все отлично известно про межсетевые экраны, а некоторым из них — даже про уязвимости. Однако они совершенно ничего не понимают в промышленной автоматике, целиком и полностью построенной сегодня с помощью современных информационных технологий, а значит, нуждающейся в их безопасности, как в воздухе. Но как защищать то, в чем ты не разбираешься? Подобная «защита» в столь критичной области как минимум может вызвать презрительную усмешку инженеров — владельцев систем, а то и вовсе привести к крайне неприятным последствиям, вплоть до нарушения технологического процесса. Вот почему именно эта проблема значительно сдерживает развитие вопросов, связанных с обеспечением ИБ промышленной автоматики и до сих пор толком не решена — разрыв между классическими информационными безопасниками/хакерами и инженерами по промышленной автоматике и сейчас, к сожалению, огромен. Слишком разная ментальность, образование и практика. Специалистов, обладающих знаниями в обеих сферах, считанные единицы.
Капитан Очевидность, или «Не тронь, пока работает»
Представим, что случилось чудо и инженеры с ибэшниками нашли общий язык или появился такой мессия — инженер и безопасник в одном лице. Это значит, что теперь мы решим все наши проблемы? Увы, нет.
Проводя аудит защищенности АСУ ТП, мы регулярно ловим себя на мысли, что такая работа гораздо больше подходит для «капитана Очевидность». И хуже того, результаты подобного аудита на 95%, скорее всего, просто пойдут в корзину. Почему? Все просто. Системы АСУ ТП всегда находились даже не на второй или третьей, а на гораздо более дальней «линии обороны». Основной принцип был и остается простой: максимальная изоляция от любых других сетей общего назначения. И это не только разумный, но и единственно возможный и правильный вариант в данной ситуации. То есть главный постулат, который до сих пор серьезно сдерживает развитие информационной безопасности промышленной автоматики, звучит так: извне (из обычной компьютерной сети предприятия или Интернета) в сеть АСУ ТП попасть невозможно, а внутри — да как угодно. При такой логике развития нетрудно понять, что собой представляет внутренняя сеть АСУ ТП с точки зрения ИБ.
Это полнейший ад безопасника, причем на любой вкус. MS DOS — пожалуйста; древняя Windows NT без сервис-паков — сколько хочешь и т. д и т. п. Почему? Да потому что софт был написан под них 15–20 лет назад и никто его менять не собирается. Часто потому, что нет другого: его поддержка закончилась 10 лет назад, а разработчики разбежались. Не тронь, пока работает — второй основной принцип всех систем промышленной автоматики. И что со всем этим диким зоопарком делать крутому хакеру/аудитору ИБ? Давать очевидные советы из серии «станьте ежиком»? Это и так понятно, только ежиком-то никак не стать — никто просто так ничего менять не будет из-за рисков, что кто-то внутри может что-то сломать. Логика вроде ясна: защита по периметру, посторонние внутрь не попадают. А уж если кто-то внутри, то у него есть все возможности сломать и без АСУ ТП. Беда в том, что иранцы думали так же. Вот только вирус попал во внутреннюю сеть через флешку, принесенную инженером. Так ли в наших реалиях помогает изоляция? Об этом мы поговорим поподробнее чуть ниже.
Да и как поменять? Останавливать непрерывный технологический процесс — сложно, убыточно, а иногда просто невозможно. Приобретать новое ПО и «железо» — это огромные деньги плюс смотри предыдущий пункт. Вопросов масса. А потому, оценив после аудита ситуацию, заказчики обычно стараются действовать «легкими мазками», минимально вмешиваясь в технологический процесс — антивирусы (да и то далеко не везде: какой смысл устанавливать антивирус в систему, где он никогда не будет обновляться?), сегментация сети, использование специализированных файроволов и для особо продвинутых — специализированные «песочницы» для контроллеров (здесь у Symantec конкурентов нет). Подчеркиваю: в данном случае речь идет об анализе ситуации со стороны заказчика. В итоге с его точки зрения получается довольно безрадостная картина: безопасностью заниматься нужно, но в ряде случаев совершенно непонятно как. И с кем — специалистов-то нет.
А если посмотреть на ситуацию глазами вендора АСУ ТП? Может, хотя бы там все хорошо?
«Безнадега точка ру»
Описанная картина в виде устаревших и непропатченных операционных систем — это проблема на стыке заказчика и вендора (которого или уже нет или у которого софт не работает под другими, более новыми версиями ОС). А что же с защищенностью самих АСУ ТП, много ли в них уязвимостей? Несложно догадаться, что там творится аналогичный ад. Всему виной политика изоляции и отношение вендоров АСУ ТП к своим системам как системам четвертой (и далее) «линии окопов». И какой в этом случае для них смысл и мотивация заниматься безопасностью? Добро пожаловать в старые добрые 90-е, где из-за уязвимостей в ОС Windows процветали массовые эпидемии вирусов. Причем ад творится на всех уровнях — от SCADA до контроллеров и даже датчиков. Простые уязвимости в SCADA- и MES-системах находим буквально пачками — было бы желание. Но это еще хоть как-то можно простить, поскольку они представляют собой обычные высокоуровневые программы, к которым все привыкли и которые «ломать» достаточно легко, — для этого не требуются никакие специфичные инженерно-технические навыки в области АСУ ТП. Но ведь хуже того, на нижнем уровне, там, где находятся контроллеры, «умные» датчики и их протоколы, тоже ничего нет хорошего. Никому в голову не приходило, что, оказывается, даже датчик можно... сломать через уязвимости. Естественно, не простой аналоговый датчик типа 4–20 мА, а «умный», имеющий свои «мозги» для обработки поступающего сигнала с дальнейшей его передачей. А еще, как это недавно показало наше исследование датчиков и протокола HART, — вполне реально даже атаковать через датчики SCADA- и MES-системы, а в отдельных случаях вплоть до обычной сети предприятия!
В процессе исследования, занявшего почти год, удалось придумать принципиально новый вектор атаки, о котором мы раньше нигде не слышали. Все относительно привыкли, что можно атаковать условно «сверху вниз»: от сети — к контроллерам и датчикам, если попадешь и их «увидишь». А здесь речь идет об атаке «снизу вверх»: через датчик удалось атаковать системы выше — MES и далее в корпоративную сеть! Связка «уязвимость датчика + XML-инъекция» приводит к тому, что, когда PAS-система начнет взаимодействовать с датчиком, данные, содержащие инъекцию XML, передаются на уровень выше — в MES или другие системы. На этом уровне происходит внедрение ссылки на XML-документ, находящийся на внешнем или локальном веб-сервере, затем выполняется загрузка внешней схемы XML. Таким образом, атакующий может читать произвольные файлы на сервере MES-системы или использовать методы SSRF для расширения диапазона атаки. И именно это было реализовано на практике. Раньше мы не слышали про такой вектор атаки — от датчика к контроллеру домена. И пришли к неожиданному выводу: при некоторых условиях атака на датчик способна привести в корпоративную сеть.
Возвращаясь к вендорам. О какой защищенности здесь может идти речь? SDLC — нет, не слышали. Уровень зрелости подавляющего большинства вендоров промышленной автоматики по отношению к ИБ близок к нулю. Это печальный факт.
Изоляция — наше все. А вы в этом уверены?
Теперь поговорим об изоляции сетей АСУ ТП от сетей общего пользования и Интернета. На самом деле есть множество вариантов обойти даже самую лучшую изоляцию. Wi-Fi-роутеры, флешки и 3/4G-модемы, игры могут и любят приносить операторы на промышленные объекты. Результат ясен. Выход в Интернет из сети АСУ ТП —тоже все очевидно. Впрочем, это тривиально. Нарушение изоляции изнутри — с ним так или иначе удается бороться, это неинтересно. А что же снаружи? Тут сложнее, но есть варианты. Иногда для работы некоторых систем вендорам нужно пропилить дырочку снаружи, которая случайно может оказаться туннелем метро, — но это тоже неинтересно, поскольку ее легко закрыть. Доступ из Интернета? Здесь труднее и интереснее. Не так давно мне попался очередной отчет об исследовании, где утверждалось, что после сканирования всего Интернета было обнаружено свыше 60 тысяч систем промышленной автоматики, напрямую подключенных к Сети. Авторы намеренно умалчивают (ну как же — больше ада!) или просто не знают, что подавляющее большинство из этих 60 тысяч являются не заводами и электростанциями, а обычными «умными домами» (им доступ из сети Интернет просто необходим — для того они и строятся; часто для устройства качественного «умного дома» применяются вполне «взрослые» промышленные контроллеры) и демоверсиями различных SCADA-систем, которые должны быть видны из Интернета. Также часто «торчат в сеть» реальные системы, находящиеся в процессе пусконаладки, из-за необходимости удаленного доступа персонала вендоров, но эта «дырка» пропадает сразу после запуска системы в эксплуатацию. Хотя ясно и то, что иногда, в редких случаях, в Сети можно увидеть и реальные системы. Да, представить себе, что кто-то в здравом уме и твердой памяти предоставил прямой доступ (без VPN) из Интернета к промышленной сети электростанции — довольно сложно. Но случаи, как говорится, бывают разные. Однажды в ходе аудита мы обнаружили случайно оставленную админку к интернет-банкингу, выставленную в Сеть без пароля (!). И ничего — всякое бывает. В любом случае в сфере промышленной автоматики подобное происходит не столь часто, потому что просто не нужно. А когда нужно — существует VPN. Но и это все не очень интересно. Гораздо привлекательнее — удаленные атаки на «умные» датчики, когда атакующий находится вне зоны физически защищенного периметра. Многие думают, будто такое нереально. Реально, и наше исследование HART это подтвердило. Ведь и при использовании проводных технологий, когда все датчики расположены на токовой петле (провод до 2,5 км), существует возможность подключиться к линии, которая из-за своей протяженности находится вне охраняемого периметра, и успешно атаковать датчики, а затем — все, что выше, вплоть до SCADA и MES. При этом вендоры в очередной раз фееричны. Они начинают постепенно... отказываться от проводных технологий, переходя к беспроводным, считая их на словах (внимание!) более защищенными, а на самом деле просто более удобными. То есть теперь для атаки не нужно искать провод — достаточно мощной направленной антенны. Занавес.
«Всемогущие» механические системы контроля
В итоге с точки зрения информационной безопасности промышленной автоматики мы имеем двойной ноль у заказчиков и у вендоров, помноженный на очень условно относительную изоляцию промышленных сетей. Как же оно все живет? Почему мы ежедневно не слышим новостей об очередном инциденте? Прежде всего, потому что все это достаточно сложно и организация целевой атаки предполагает значительные средства и потребность, а специалистов мало. Хотя бывают и относительно простые исключения: забытый Wi-Fi, подсоединение к Интернету и т. д. Но все равно, чтобы успешно атаковать с причинением реального ущерба (даже при наличии такой возможности) — нужен кто-то, кто хорошо знает внутреннюю кухню и способен реально воздействовать на систему. Например, бывший инженер. И среди подобных инцидентов именно таких случаев, получивших огласку, большинство. Но основная защита систем промышленной автоматики даже не в их сложности и относительной изоляции. Главный аргумент всех инженеров, из-за которого большинство из них смотрят свысока на хакерские шалости с уязвимостями в SCADA и датчиках, — это устройства механической защиты. Устройства, обязанные предотвращать все опасные ситуации, вне зависимости от автоматизированных систем. Например, клапаны, которые должны сбрасывать давление, если оно выше нормы, а автоматика почему-то продолжает его увеличивать, релейные блокировки и т. п.
Все системы промышленной автоматики, особенно критичные, спроектированы с большой степенью надежности и обязательно имеют подобные системы механической защиты. Означает ли это, что заниматься ИБ в данном случае никому не нужно? Конечно, нет. Ведь никто не гарантирует, что при определенных условиях эти механические устройства не выйдут из строя. А самое главное, что давно известно: прямой атакой на контроллеры, датчики или систему управления параметрами технологического процесса при условии, что атакующий детально знает физику процесса и способен его эмулировать (или дезинформировать операторов), можно ввести систему в крайние положения или в резонанс, когда никакие механические ограничения не спасут и система выйдет из строя.
Так, в частности, и произошло со Stuxnet, который физически уничтожил иранские центрифуги, и никакая механика не помогла. Центрифуги с ураном — вещь, скажем прямо, не очень распространенная, да и сама атака была целевой и прекрасно подготовленной, но сути это не меняет. Инцидент совершенно необязательно должен закончиться катастрофой — достаточно нарушения техпроцесса и дорогостоящего простоя. Ведь практически никто не тестирует всю систему промышленной автоматики в целом на критичных или закритичных значениях, не говоря уже о наличии серых и малоизученных зон, куда систему можно ввести соответствующими манипуляциями, в том числе через уязвимости АСУ ТП — этого не происходит на испытаниях, поскольку слишком велик риск. Обычно тестируются отдельные элементы системы, которые, и правда, делаются с повышенным запасом. Поэтому инженерам не стоит столь явно уповать на механические защиты, считая их панацеей, и свысока относиться к деятельности каких-то там хакеров-исследователей, после какого-то года кропотливой работы сломавших очередной датчик. Действовать нужно сообща. Только надежная комбинация в виде безопасной среды, отсутствия уязвимостей в программном и программно-аппаратного обеспечении, надежных механических защит и организационных мер (о которых мы не упомянули в статье) сделает системы АСУ ТП по-настоящему безопасными. И двух мнений здесь быть не может.
Опубликовано 30.04.2014