«Не влезай, убьет!» или вся правда о безопасности АСУ ТП +40


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

Мы решили собрать наш опыт защиты АСУ ТП и рассказать о самых частых проблемах и популярных мифах о безопасности в данной области.


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

АСУ ТП, как правило, имеет многоуровневую структуру:

  • Уровень операторского/диспетчерского управления (верхний уровень).
  • Уровень автоматического управления (средний уровень).
  • Уровень ввода/вывода данных исполнительных устройств (нижний/полевой уровень).

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



Проблема 1: миф о «воздушном зазоре»


Многие АСУ ТП строились по-настоящему давно. Тогда считалось, что технологические сети и системы полностью изолированы от внешнего мира, и в том числе поэтому обеспечение информационной безопасности в этой сфере не признавалось актуальным или, в лучшем случае, не было приоритетным. Однако сейчас грань между технологическими и корпоративными сетями всё больше стирается, и, кроме того, в технологических сетях всё больше используется Ethernet/IP и в целом технологии сетей корпоративных.

Эти процессы обусловлены потребностью бизнеса и, как следствие необходимости связности сетей, обычно мы наблюдаем у Заказчика один из нижеприведенных сценариев:

  1. У заказчика реализован проект сопряжения и сегментирования корпоративной и технологических сетей, предусматривающий комплексный подход к обеспечению ИБ при связности сегментов. На текущий момент самый редкий вариант, однако мы встречали его у нескольких заказчиков.
  2. Корпоративная и технологическая сети заказчика связаны по одной из схем, доступных и кажущихся достаточно безопасными службам ИТ, ИБ и АСУ ТП. Это могут быть как связность с использованием межсетевого экрана, использованием маршрутизатора с ACL (Access Control List) и прочие варианты вплоть до АРМ/серверов доступа с несколькими сетевыми картами (кстати, один из очень распространенных случаев). На эти схемы часто накладывается большое число доступов, в том числе и доступов извне корпоративной сети — для установленных на территории производств банкоматов, удаленной работы вендоров АСУ ТП и прочих привлекаемых подрядных организаций. Как следствие, по факту данные схемы со временем начинают трансформироваться в следующий вариант:
  3. Просто АСУ ТП в общей сети. Кажется невероятным, но, к сожалению, этот вариант также широко распространен.

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

Результаты пентеста АСУ ТП компании A (выдержка из отчета)
В процессе проведения работ аудитором был получен доступ к удаленному рабочему столу АРМ пользователя с IP-адресом 172.28.XX.YY, на котором были обнаружены:

  • Сохраненные настройки VPN-подключений к сегментам технологической инфраструктуры, считающимся изолированными (см. рис.).

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


Использование VPN-подключений с сохраненными реквизитами позволило аудитору напрямую с выявленного АРМ получить доступ к управлению сетевым оборудованием технологической инфраструктуры, а также оборудованием на конечных объектах с помощью интерфейсов управления соответствующими SCADA-системами.

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

В результате получаем безрадостную картину возможности легкого проникновения злоумышленника или вредоносного ПО со связью с C&C внутрь АСУ ТП. Обобщённо можно сформулировать это следующим образом: всё, что угрожает корпоративной сети, фактически угрожает и технологическим сегментам. Это ни в коем случае не значит, что на технологическую инфраструктуру и АСУ ТП нужно переносить технологии защиты корпоративной сети, но необходимо отдавать себе отчет в том, что рисков ИБ у технологических сегментов точно не меньше, чем у корпоративных.

Проблема 2: ИБ в АСУ ТП и гигиена ИБ


Технологические сети и сегменты в то же время значительно отличаются от корпоративных сетей и систем. Так, в отличие от типовой ИТ-системы, типовая АСУ ТП:

  • Является системой реального времени, в которой время реакции является критичным, а задержки и потеря данных – неприемлемыми.
  • Наряду с широко распространенными ОС и протоколами в ней широко используются специализированные и специально разработанные (проприетарные).
  • Продолжительность жизненного цикла составляет 10-15-20 лет, а для некоторых объектов — и до 30 лет.
  • Компоненты могут быть изолированными, территориально удаленными и с физически сложным доступом.
  • Перезагрузка в АСУ ТП может быть неприемлема, в т.ч. зачастую невозможна и установка каких-либо обновлений и т.д.

Как следствие, на конечных объектах у заказчика мы часто наблюдаем ситуацию, когда используется некая собственная разработка (ни производителя, ни поддержки которой уже не осталось), с общей учетной записью смены, пароль от которой невозможно изменить и который совпадает с логином (по аналогии со знаменитыми admin/admin). Если пароль вообще может быть задан, ведь, напомним, многим АСУ ТП более 10-15 лет.

Результаты пентеста АСУ ТП компании B (выдержка из отчета)
Изучение выявленных аудитором схем технологических сетей и способов их сопряжения с пользовательскими сегментами показало, что узлы с IP-адресами 10.65.XX.YY, 10.65.XX.ZZ выполняют функции маршрутизатора между пользовательской и технологической сетью. Доступ на данные устройства возможен по протоколу SSH с использованием реквизитов учетной записи пользователя root с легко подбираемым паролем root. Узлы с указанными выше IP-адресами после получения доступа к ним были идентифицированы и оказались контроллерами системы PSI (см. рис.).



Работа на данных устройствах сервиса SSH с возможностью передачи графических сессий и поддержкой SSH-туннелей позволила аудитору организовать туннелирование трафика и провести через контроллеры системы PSI выборочное сканирование узлов технологических сетей, последующую атаку на подсистему парольной защиты технологической сети и получить доступ к устройствам, изолированным от пользовательского сегмента.

В частности, аудитором был получен доступ в технологическую сеть на базе оборудования MIKRONIKA, для чего применялся доступ по протоколу Telnet с использованием реквизитов учетной записи root, не имеющей установленного пароля для удаленного привилегированного доступа к устройствам (см. рис.).



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

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

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

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

Резюмируя описанные выше ситуации и проблемы, можно отметить следующие основные тезисы: в части сложившейся ситуации с ИБ в АСУ ТП:

  1. «Всё сломать» в АСУ ТП можно и без сложных атак на системы, протоколы и контроллеры.
  2. Стартовые риски ИБ в технологической сети не только не меньше, но и значительно выше, чем в корпоративной.
  3. Данные риски требуют собственных ряда действий и мероприятий, как минимум учитывающих:
    • колоссальную критичность и непрерывность бизнес-процессов;
    • практическую невозможность обновлений;
    • практическую малоприменимость или неприменимость традиционных систем ИБ и, в частности, механизмов блокирования.

Но сколько бы ни было ограничивающих факторов, защищать АСУ ТП все же необходимо. Во второй части статьи мы расскажем о том, как, учитывая указанные проблемы, осуществлять полноценный мониторинг и реагирование на кибератаки. Опять-таки, с живыми примерами и кейсами от заказчиков. Не пропустите!

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (23):

  1. IvanovSV
    /#10678558

    А где будет привязка к ФСТЭК 31? Ну и 187-ФЗ для полного счастья?

    • SolarSecurity
      /#10679968

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

  2. Whuthering
    /#10678836

    Общение с АСУТПшниками на тему безопасности, процесс весьма сложный. В отрасли среди технических специалистов бытует мнение, что всё «секьюрити» — это нечто ненужное, мешающее работать, и придуманное только для выкачивания денег из заказчиков.

    Типичный диалог выглядит примерно так:
    — * Рассказ об очередных дырах в контроллерах, о несовершенстве протоколов, либо о необходимости установки нормальных паролей, либо об обновлениях хотя бы там, где они возможны, и т.д. *
    — Да всё это не нужно, у нас air gap / firewall!
    — Безопасность системы складывается не из безопасности одной части, а системы в целом. Ваш air gap в половине случаев на самом деле никакой не air gap, и в принципе не работает. С фаерволом то же самое.
    — Ну значит надо сделать так, чтобы работал! Да и вообще, если кто-то что-то сломать захочет, он инженера подкупит, чтобы тот на флешку все секреты скопировал, или электрика, чтобы тот кусачками провода перерезал.
    — *facepalm*

    • SolarSecurity
      /#10679970

      И такое устойчивое мнение – одна из причин появления нашей статьи. Забегая немного вперед, скажу, что мы считаем, что «слона надо есть по частям», понемногу приучая производство к безопасности.

      • Whuthering
        /#10681084

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

        • SolarSecurity
          /#10681410

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

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

          «Да зачем оно надо, если злоумышленникам проще и эффективнее внедрить/подкупить своего человека на месте».
          А человек на месте — это история чуть другой безопасности, и как раз она, по нашему опыту, на критичных объектах на должном уровне.

    • VADR
      /#10682084

      Чтобы общение с АСУТПшниками не было столь сложным процессом, попробуйте для начала хотя бы минимально понять, что такое АСУТП, чем отличается от обычных информационных систем. Не пытайтесь, чуть сунувшись в тему, учить людей, что и как надо делать. Лучше сами поучитесь, полезно.

  3. evetrov
    /#10679492

    Слышал слышал про такое на заводах.
    Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы.

    По ходу любой школьник может уронить случайно какой нибудь завод или электро-станцию.

    • SolarSecurity
      /#10679978

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

    • VADR
      /#10680840

      Хм… молодой человек, а не появлялось ли у Вас желание для начала хотя бы в минимальном объёме ознакомиться с тем, что такое АСУТП, дабы в дальнейшем… как бы это мягче сказать… более осторожно относиться к изрекаемым словам?

      • LorHobbit
        /#10682196

        Эх… Ваша ирония была бы уместна, если бы всё не было так грустно. Его слова на самом деле не так уж далеки от реальности,
        Я был по-настоящему шокирован, когда N лет назад мне пришлось познакомиться с Simatic WinCC, в частности, с тем, как в означенной системе устроено сетевое взаимодействие (завязанное на высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей). И вот когда я осознал, что на ЭТОМ строят АСУ ТП (причём достаточно критичными и небезопасными ТП), мне стало не очень хорошо. А ещё года через полтора пошли публикации про Stuxnet — и я как-то совсем не удивился…
        Молодой человек, скорее, недостаточно радикален. Мне кажется, что тут надо не только винду гнать ссаными тряпками, но и большинство линуксов, мейнстримовых, по крайней мере. Если только специализированные RT-решения. А объектам типа тех, которые поразил Stuxnet в Иране, ОС и SCADA общего назначения вообще противопоказаны.
        (Да, мой комментарий немножко сумбурен, немножко про ОС, немножко про SCADA, но Вы же понимаете, что безопасность надо рассматривать в комплексе.)

        • VADR
          /#10682236

          Какая ирония? Нет никакой иронии. Если человек говорит "Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы." — это либо стёб, либо элементарное непонимание того, что есть АСУТП и из чего состоит. Я совсем не против линуксов, более того, у меня на домашней машине федора (на ней сейчас и печатаю :) ). Но вот в АСУТП — куда???
          Не, реально существуют линуксовые управляющие системы (я, кстати, с такими работаю, срециализированные RT), но это — далеко не лучший вариант, на мой взгляд. В нормальных контроллерах… я вот вообще не знаю, есть там какая-то ОС между целевым софтом и железом, или там монолитный продукт.
          Тогда что? Операторский интерфейс? Допустим. Решений немного, но они существуют. Но. Это — отдельные scada-системы. Интегрировать в общий проект системы управления — не получится. То есть — каждый канальчик прописывать ручками. Живой пример (один из знакомых мне объектов): объект из 320 двигателей, 170 клапанов, 1300 сигналов в поле. На каждом двигателе — порядка 8 сигналов состояния, на клапанах — 5-6. Плюс у каждого двигателя и клапана — 15-20 блокировочных сигналов. Можно перемножить и посчитать. Молодой падаван будет это вручную делать? Сколько времени у него на это уйдёт? Сколько ошибок останутся невыловленными? И это… операторский интерфейс — ещё далеко не вся система. Я бы оценил примерно как 2-3%, вряд ли больше. Так что «всё снести и переделать» — далеко не проще.
          Да, есть такое дело, MS вовремя подсуетилась со своими продуктами и теперь они везде.
          Кстати, а где в WinCC вы видели "высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей"? Не то, чтобы их там не было совсем… но чтобы до них добраться, надо делать систему несколько специфичного назначения и со специфичным комплектом программного обеспечения, которое уже никак не назовёшь типовым.

  4. kababok
    /#10679494

    Вы уж простите, но почему на иконке с подписью "электропривод" у вас изображён двигатель внутреннего сгорания?


    Как электроприводчик интересуюсь. :)

    • SolarSecurity
      /#10679982

      Да, вы правы, мы действительно не проверили точность конкретной иллюстрации. Но мы исправимся. Спасибо)

    • robux
      /#10680110

      Электропривод — это тоже "Исполнительный механизм",
      так что его на схеме можно было вообще не указывать.

  5. shadson
    /#10679496

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

    • SolarSecurity
      /#10680880

      Ситуации бывают разные, и, как показывает практика, кому-то будет мало и двух «Петь» подряд. Но сейчас мы видим значительно меньше подобных кейсов. Это следствие не только «Пети» и активных действий государства и регуляторов, а скорее даже совокупного движения компаний в сторону повышения уровня зрелости в вопросах обеспечения ИБ.

  6. e1t1
    /#10679498

    Уже идут лидеры отечественой отрасли и скоро всё зашифруют:)

  7. vilainman
    /#10679500

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

    • SolarSecurity
      /#10680890

      Давайте будем оптимистами. Тем более, мы с вами видим рост спроса на квалифицированные кадры в области обеспечения ИБ в АСУ ТП. Среди задач, которые ставятся перед этими людьми, помимо соответствия требованиям, мы видим задачи обеспечения реальной безопасности, снижения рисков ИБ за счет применения организационных и технических мер.
      Так что скорее все же движемся в светлое будущее)

      • vilainman
        /#10680904

        ООоо, конечно )))) будем оптимистами, мы движемся в указанном направлении… но будем и реалистами, прибытие в этом направлении, скорее всего, доведется увидеть нашим потомкам )))
        и если вообще совсем быть реалистами, то стоит, все же, отметить, что спрос на квалифицированные кадры в данном сегменте скорее не растет, а только формируется ))))

  8. VADR
    /#10682138

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

    • VADR
      /#10682148

      И собственно, обещанный старый армейский анекдот.
      Командир (К) части спрашивает свежеприбывшего из училища молодого лейтенанта (Л):
      К: Товарищ лейтенант, вы взводом командовать можете?
      Л: Так точно!
      К: А ротой, если потребуется?
      Л: Так точно!
      К: Полком?
      Л: Так точно!
      К: Кораблём, самолётом, подводной лодкой?
      Л: Так точно!
      К: Продемонстрируйте!
      Л: Подводная лодка! Р-равняйсь! Смирно!

      (это я к чему, собственно: не всегда один подход годится везде)