Мы решили собрать наш опыт защиты АСУ ТП и рассказать о самых частых проблемах и популярных мифах о безопасности в данной области.
АСУ ТП — комплекс технических и программных средств, предназначенный для автоматизации управления технологическим оборудованием на промышленных предприятиях.
АСУ ТП, как правило, имеет многоуровневую структуру:
- Уровень операторского/диспетчерского управления (верхний уровень).
- Уровень автоматического управления (средний уровень).
- Уровень ввода/вывода данных исполнительных устройств (нижний/полевой уровень).
Количество уровней АСУ ТП так же, как и её состав на каждом из уровней, безусловно зависит от её назначения и выполняемых целевых функций. При этом на каждом уровне автоматизированной системы управления по функциональным, территориальным или иным признакам могут выделяться и другие дополнительные сегменты. Тем не менее, на текущем этапе ограничимся общим нижеприведенным представлением.
Проблема 1: миф о «воздушном зазоре»
Многие АСУ ТП строились по-настоящему давно. Тогда считалось, что технологические сети и системы полностью изолированы от внешнего мира, и в том числе поэтому обеспечение информационной безопасности в этой сфере не признавалось актуальным или, в лучшем случае, не было приоритетным. Однако сейчас грань между технологическими и корпоративными сетями всё больше стирается, и, кроме того, в технологических сетях всё больше используется Ethernet/IP и в целом технологии сетей корпоративных.
Эти процессы обусловлены потребностью бизнеса и, как следствие необходимости связности сетей, обычно мы наблюдаем у Заказчика один из нижеприведенных сценариев:
- У заказчика реализован проект сопряжения и сегментирования корпоративной и технологических сетей, предусматривающий комплексный подход к обеспечению ИБ при связности сегментов. На текущий момент самый редкий вариант, однако мы встречали его у нескольких заказчиков.
- Корпоративная и технологическая сети заказчика связаны по одной из схем, доступных и кажущихся достаточно безопасными службам ИТ, ИБ и АСУ ТП. Это могут быть как связность с использованием межсетевого экрана, использованием маршрутизатора с ACL (Access Control List) и прочие варианты вплоть до АРМ/серверов доступа с несколькими сетевыми картами (кстати, один из очень распространенных случаев). На эти схемы часто накладывается большое число доступов, в том числе и доступов извне корпоративной сети — для установленных на территории производств банкоматов, удаленной работы вендоров АСУ ТП и прочих привлекаемых подрядных организаций. Как следствие, по факту данные схемы со временем начинают трансформироваться в следующий вариант:
- Просто АСУ ТП в общей сети. Кажется невероятным, но, к сожалению, этот вариант также широко распространен.
Помимо того, сказывается и эффект развития и массовой доступности современных технологий (мобильных устройств и мобильного интернета, USB-модемов и т.п.), которые сотрудники активно используют в собственных целях. Начиная от операторов, желающих иметь доступ в интернет на рабочем месте, и заканчивая ИТ-администраторами, желающими сэкономить время поездки до конечного объекта, находящегося, как пример, в 20 км от офиса.
- Сохраненные настройки VPN-подключений к сегментам технологической инфраструктуры, считающимся изолированными (см. рис.).
- Файл, который содержал реквизиты доступа к узлам технологической инфраструктуры, включая реквизиты доступа и управления используемых SCADA-систем различных производителей. Файл был доступен в общем сетевом каталоге всем пользователям корпоративной сети без аутентификации (см. рис.).
Использование VPN-подключений с сохраненными реквизитами позволило аудитору напрямую с выявленного АРМ получить доступ к управлению сетевым оборудованием технологической инфраструктуры, а также оборудованием на конечных объектах с помощью интерфейсов управления соответствующими SCADA-системами.
Дополним картину упомянутыми выше проблемами использования на местах USB-модемов. Телефонов, как USB-модемов. Домашних маршрутизаторов, домашних серверов хранения и прочих «возможностей» современной жизни. И даже если корпоративная и технологическая сети связаны по наилучшему — первому из сценариев, к сожалению, по факту это не означает, что ситуация действительно такова, какой должна быть, и на конкретных местах нет, например, собственного выхода в интернет или неконтролируемого доступа в корпоративную сеть и обратно.
В результате получаем безрадостную картину возможности легкого проникновения злоумышленника или вредоносного ПО со связью с C&C внутрь АСУ ТП. Обобщённо можно сформулировать это следующим образом: всё, что угрожает корпоративной сети, фактически угрожает и технологическим сегментам. Это ни в коем случае не значит, что на технологическую инфраструктуру и АСУ ТП нужно переносить технологии защиты корпоративной сети, но необходимо отдавать себе отчет в том, что рисков ИБ у технологических сегментов точно не меньше, чем у корпоративных.
Проблема 2: ИБ в АСУ ТП и гигиена ИБ
Технологические сети и сегменты в то же время значительно отличаются от корпоративных сетей и систем. Так, в отличие от типовой ИТ-системы, типовая АСУ ТП:
- Является системой реального времени, в которой время реакции является критичным, а задержки и потеря данных – неприемлемыми.
- Наряду с широко распространенными ОС и протоколами в ней широко используются специализированные и специально разработанные (проприетарные).
- Продолжительность жизненного цикла составляет 10-15-20 лет, а для некоторых объектов — и до 30 лет.
- Компоненты могут быть изолированными, территориально удаленными и с физически сложным доступом.
- Перезагрузка в АСУ ТП может быть неприемлема, в т.ч. зачастую невозможна и установка каких-либо обновлений и т.д.
Как следствие, на конечных объектах у заказчика мы часто наблюдаем ситуацию, когда используется некая собственная разработка (ни производителя, ни поддержки которой уже не осталось), с общей учетной записью смены, пароль от которой невозможно изменить и который совпадает с логином (по аналогии со знаменитыми admin/admin). Если пароль вообще может быть задан, ведь, напомним, многим АСУ ТП более 10-15 лет.
Работа на данных устройствах сервиса SSH с возможностью передачи графических сессий и поддержкой SSH-туннелей позволила аудитору организовать туннелирование трафика и провести через контроллеры системы PSI выборочное сканирование узлов технологических сетей, последующую атаку на подсистему парольной защиты технологической сети и получить доступ к устройствам, изолированным от пользовательского сегмента.
В частности, аудитором был получен доступ в технологическую сеть на базе оборудования MIKRONIKA, для чего применялся доступ по протоколу Telnet с использованием реквизитов учетной записи root, не имеющей установленного пароля для удаленного привилегированного доступа к устройствам (см. рис.).
Также, в то время как в технологических системах по большей части циркулирует информация о технологических процессах и об управляющих воздействиях, акцент, как правило, делается на ее доступности и целостности, тогда как вопросу обеспечения конфиденциальности, как правило, уделяется меньше внимания. И это одна из дополнительных причин, объясняющих «задержку» с движением в направлении обеспечения информационной безопасности в сфере АСУ ТП.
Итак, мы имеем фактически незащищенную систему, работающую на устаревшем и неподдерживаемом ПО с целым веером уязвимостей. Установка обновлений на такую систему, в большинстве случаев, невозможна – из-за их отсутствия, невозможности установки, невозможности перезагрузки и другим многочисленным причинам). Отсюда следует вывод: проблемы и уязвимости в технологических сетях и системах даже выше, чем в средней корпоративной сети.
При этом даже в случае использования систем и ПО, поддерживаемых производителем, со стороны производства обычно наблюдается устойчивое сопротивление каким-либо обновлениям, направленным на устранение проблем безопасности. И практически всегда это неприятие распространяется на любые наложенные средства безопасности (к слову, возможно, вполне обоснованное, если в подобных средствах так или иначе заявлены и реализованы механизмы блокирования, даже если не предполагается их задействовать в ходе внедрения и будущей эксплуатации).
Важно отметить, что заказчикам известна большая часть этих проблем, включая возможные действия сотрудников на местах. Риски ИБ, связанные с ними, закрываются очень жесткими организационными мерами и мерами физической безопасности: запрет проноса на территорию и использования различных устройств и внешних носителей, физическое ограничение возможности использования портов оборудования и т.п. меры). Однако эти меры не способны полностью обеспечить надежную защиту АСУ ТП.
Резюмируя описанные выше ситуации и проблемы, можно отметить следующие основные тезисы: в части сложившейся ситуации с ИБ в АСУ ТП:
- «Всё сломать» в АСУ ТП можно и без сложных атак на системы, протоколы и контроллеры.
- Стартовые риски ИБ в технологической сети не только не меньше, но и значительно выше, чем в корпоративной.
- Данные риски требуют собственных ряда действий и мероприятий, как минимум учитывающих:
- колоссальную критичность и непрерывность бизнес-процессов;
- практическую невозможность обновлений;
- практическую малоприменимость или неприменимость традиционных систем ИБ и, в частности, механизмов блокирования.
Но сколько бы ни было ограничивающих факторов, защищать АСУ ТП все же необходимо. Во второй части статьи мы расскажем о том, как, учитывая указанные проблемы, осуществлять полноценный мониторинг и реагирование на кибератаки. Опять-таки, с живыми примерами и кейсами от заказчиков. Не пропустите!
Комментарии (23)
Whuthering
20.02.2018 12:00Общение с АСУТПшниками на тему безопасности, процесс весьма сложный. В отрасли среди технических специалистов бытует мнение, что всё «секьюрити» — это нечто ненужное, мешающее работать, и придуманное только для выкачивания денег из заказчиков.
Типичный диалог выглядит примерно так:
— * Рассказ об очередных дырах в контроллерах, о несовершенстве протоколов, либо о необходимости установки нормальных паролей, либо об обновлениях хотя бы там, где они возможны, и т.д. *
— Да всё это не нужно, у нас air gap / firewall!
— Безопасность системы складывается не из безопасности одной части, а системы в целом. Ваш air gap в половине случаев на самом деле никакой не air gap, и в принципе не работает. С фаерволом то же самое.
— Ну значит надо сделать так, чтобы работал! Да и вообще, если кто-то что-то сломать захочет, он инженера подкупит, чтобы тот на флешку все секреты скопировал, или электрика, чтобы тот кусачками провода перерезал.
— *facepalm*
SolarSecurity Автор
20.02.2018 18:51И такое устойчивое мнение – одна из причин появления нашей статьи. Забегая немного вперед, скажу, что мы считаем, что «слона надо есть по частям», понемногу приучая производство к безопасности.
Whuthering
21.02.2018 12:38Интересно было бы еще увидеть ваши рассуждения касательно обоснования целесообразности защит, поскольку, как я уже сказал выше, часто разговоры о безопасности разбиваются о «Да кому мы вообще нужны, чтобы нас ломать» и «Да зачем оно надо, если злоумышленникам проще и эффективнее внедрить/подкупить своего человека на месте».
SolarSecurity Автор
21.02.2018 15:17Интересно было бы еще увидеть ваши рассуждения касательно обоснования целесообразности защит, поскольку, как я уже сказал выше, часто разговоры о безопасности разбиваются о «Да кому мы вообще нужны, чтобы нас ломать»
Наши диалоги с заказчиками и соответствующие обоснования сильно разнятся в зависимости от конкретного предприятия. Например, в некоторых случаях потенциальные последствия успешной атаки на АСУ ТП настолько ужасны, что рассуждать в классической парадигме в принципе неправильно.
А есть, конечно, менее критичные объекты, и в этом случае мы апеллируем и к реальным инцидентам на аналогичных предприятиях, и, если есть возможность, к инцидентам в периметре данной компании, и к требованиям регуляторов, наконец.
«Да зачем оно надо, если злоумышленникам проще и эффективнее внедрить/подкупить своего человека на месте».
А человек на месте — это история чуть другой безопасности, и как раз она, по нашему опыту, на критичных объектах на должном уровне.
VADR
21.02.2018 21:30Чтобы общение с АСУТПшниками не было столь сложным процессом, попробуйте для начала хотя бы минимально понять, что такое АСУТП, чем отличается от обычных информационных систем. Не пытайтесь, чуть сунувшись в тему, учить людей, что и как надо делать. Лучше сами поучитесь, полезно.
evetrov
20.02.2018 15:25Слышал слышал про такое на заводах.
Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы.
По ходу любой школьник может уронить случайно какой нибудь завод или электро-станцию.SolarSecurity Автор
20.02.2018 18:52К счастью или к сожалению, но это не всегда возможно. И даже из таких самых сложных ситуаций есть выход. Но в целом в последнее время ситуация с безопасностью АСУ ТП улучшается. Мы все чаще видим, что в ТЗ на создаваемые и модернизируемые системы закладываются требования по обеспечению ИБ.
VADR
21.02.2018 10:49Хм… молодой человек, а не появлялось ли у Вас желание для начала хотя бы в минимальном объёме ознакомиться с тем, что такое АСУТП, дабы в дальнейшем… как бы это мягче сказать… более осторожно относиться к изрекаемым словам?
LorHobbit
21.02.2018 23:31Эх… Ваша ирония была бы уместна, если бы всё не было так грустно. Его слова на самом деле не так уж далеки от реальности,
Я был по-настоящему шокирован, когда N лет назад мне пришлось познакомиться с Simatic WinCC, в частности, с тем, как в означенной системе устроено сетевое взаимодействие (завязанное на высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей). И вот когда я осознал, что на ЭТОМ строят АСУ ТП (причём достаточно критичными и небезопасными ТП), мне стало не очень хорошо. А ещё года через полтора пошли публикации про Stuxnet — и я как-то совсем не удивился…
Молодой человек, скорее, недостаточно радикален. Мне кажется, что тут надо не только винду гнать ссаными тряпками, но и большинство линуксов, мейнстримовых, по крайней мере. Если только специализированные RT-решения. А объектам типа тех, которые поразил Stuxnet в Иране, ОС и SCADA общего назначения вообще противопоказаны.
(Да, мой комментарий немножко сумбурен, немножко про ОС, немножко про SCADA, но Вы же понимаете, что безопасность надо рассматривать в комплексе.)VADR
22.02.2018 00:50Какая ирония? Нет никакой иронии. Если человек говорит "Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы." — это либо стёб, либо элементарное непонимание того, что есть АСУТП и из чего состоит. Я совсем не против линуксов, более того, у меня на домашней машине федора (на ней сейчас и печатаю :) ). Но вот в АСУТП — куда???
Не, реально существуют линуксовые управляющие системы (я, кстати, с такими работаю, срециализированные RT), но это — далеко не лучший вариант, на мой взгляд. В нормальных контроллерах… я вот вообще не знаю, есть там какая-то ОС между целевым софтом и железом, или там монолитный продукт.
Тогда что? Операторский интерфейс? Допустим. Решений немного, но они существуют. Но. Это — отдельные scada-системы. Интегрировать в общий проект системы управления — не получится. То есть — каждый канальчик прописывать ручками. Живой пример (один из знакомых мне объектов): объект из 320 двигателей, 170 клапанов, 1300 сигналов в поле. На каждом двигателе — порядка 8 сигналов состояния, на клапанах — 5-6. Плюс у каждого двигателя и клапана — 15-20 блокировочных сигналов. Можно перемножить и посчитать. Молодой падаван будет это вручную делать? Сколько времени у него на это уйдёт? Сколько ошибок останутся невыловленными? И это… операторский интерфейс — ещё далеко не вся система. Я бы оценил примерно как 2-3%, вряд ли больше. Так что «всё снести и переделать» — далеко не проще.
Да, есть такое дело, MS вовремя подсуетилась со своими продуктами и теперь они везде.
Кстати, а где в WinCC вы видели "высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей"? Не то, чтобы их там не было совсем… но чтобы до них добраться, надо делать систему несколько специфичного назначения и со специфичным комплектом программного обеспечения, которое уже никак не назовёшь типовым.
kababok
20.02.2018 15:25Вы уж простите, но почему на иконке с подписью "электропривод" у вас изображён двигатель внутреннего сгорания?
Как электроприводчик интересуюсь. :)
SolarSecurity Автор
20.02.2018 18:53Да, вы правы, мы действительно не проверили точность конкретной иллюстрации. Но мы исправимся. Спасибо)
robux
20.02.2018 19:54Электропривод — это тоже "Исполнительный механизм",
так что его на схеме можно было вообще не указывать.
shadson
20.02.2018 15:26После «Пети» многие заказчики типа начали приставать «нам надо чтоб всё было безопасно».
При этом культуры, понимания и даже просто людей, которые понимают что можно сделать, почему это нужно и на что это повлияет.
Обычно всё сводится к «продайте такую штуку, что б пришло счастье. О, файрвол! А почему так дорого? Не, нам попроще бы».SolarSecurity Автор
21.02.2018 11:15Ситуации бывают разные, и, как показывает практика, кому-то будет мало и двух «Петь» подряд. Но сейчас мы видим значительно меньше подобных кейсов. Это следствие не только «Пети» и активных действий государства и регуляторов, а скорее даже совокупного движения компаний в сторону повышения уровня зрелости в вопросах обеспечения ИБ.
vilainman
20.02.2018 15:26на самом деле, нет в этом ничего необычного или америки, которую можно открыть… это тот компромисс, от которого начинаем уходить в светлое будущее или в закат )))
при реализации всех возможных и невозможных мер упираемся в самое узкое место — человеческий фактор… при создании любой технологической системы учитываются требования к обслуживающему персоналу… которые что?! правильно… как правило, нивелируются ))))SolarSecurity Автор
21.02.2018 11:21Давайте будем оптимистами. Тем более, мы с вами видим рост спроса на квалифицированные кадры в области обеспечения ИБ в АСУ ТП. Среди задач, которые ставятся перед этими людьми, помимо соответствия требованиям, мы видим задачи обеспечения реальной безопасности, снижения рисков ИБ за счет применения организационных и технических мер.
Так что скорее все же движемся в светлое будущее)vilainman
21.02.2018 11:27ООоо, конечно )))) будем оптимистами, мы движемся в указанном направлении… но будем и реалистами, прибытие в этом направлении, скорее всего, доведется увидеть нашим потомкам )))
и если вообще совсем быть реалистами, то стоит, все же, отметить, что спрос на квалифицированные кадры в данном сегменте скорее не растет, а только формируется ))))
VADR
21.02.2018 22:30Итак, очередная статья, где специалисты по ИБ знают точно, что должны делать мы, АСУТПшники. А мы, глупенькие, сопротивляемся прогрессу. Господа ИБшники, а вы ничего не забыли? К примеру, ознакомиться с тем, что собираетесь защищать — не надо? Или вы как в старом армейском анекдоте — «Подводная лодка, р-равняйсь, смирно!» (если кто не знает, могу ниже в каментах рассказать).
Итак, минимальный ликбез для ИБшника на тему того, что такое АСУТП.
Начнём с двух последних букв. ТП — это «технологический процесс». Вот первое и главное отличие АСУТП от разных «обычных» информационных систем. Если в привычных вам системах во главе угла — информация, которую надо защищать от разных напастей (потери, повреждения, несанкционированного доступа), то в АСУТП главное — технологический процесс. Информация — лишь отображение технологического процесса в виде, понятном системе управления. Что из этого следует? А то, что и защищать надо именно технологический процесс. Когда вы предлагаете анализировать информацию между контроллером и полевыми устройствами и, при наличии обоснованных подозрений, блокировать её (конкретно у вас такого не читал, но обычно все ИБшники это предлагают) — вы уверены, что ваш анализ точен и решение правильно? Вас не смущает, что именно вы можете перевести объект в неуправляемый режим с гораздо большей вероятностью, чем какой-нибудь петя или стакснет? А потому, когда суровые АСУТПшники на местах встречают вас не слишком радушно — скажите спасибо, что пинками за территорию не выгоняют.VADR
21.02.2018 22:35И собственно, обещанный старый армейский анекдот.
Командир (К) части спрашивает свежеприбывшего из училища молодого лейтенанта (Л):
К: Товарищ лейтенант, вы взводом командовать можете?
Л: Так точно!
К: А ротой, если потребуется?
Л: Так точно!
К: Полком?
Л: Так точно!
К: Кораблём, самолётом, подводной лодкой?
Л: Так точно!
К: Продемонстрируйте!
Л: Подводная лодка! Р-равняйсь! Смирно!
(это я к чему, собственно: не всегда один подход годится везде)
IvanovSV
А где будет привязка к ФСТЭК 31? Ну и 187-ФЗ для полного счастья?
SolarSecurity Автор
Возможно, в одной из следующих статей по теме. В этом цикле мы планируем рассказать о задачах практической безопасности, не концентрируясь на вопросах регулирования.