Информационная безопасность
0,0
рейтинг
21 февраля 2013 в 14:36

Разработка → Безопасность АСУТП практика и примеры

Здесь не будет историй о проникновении кибер террористов на ядерные объекты и массовом применении кибер оружия для уничтожения инфраструктуры неприятеля. А будет несколько обыденных примеров из личной практики, по модному ныне тренду безопасности АСУТП на типичном среднем Российском производстве.

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

www.ptsecurity.ru/download/SCADA_analytics_russian.pdf

И последующий за ней гомерический хохот от специалистов АСУ ТП
.
asutpforum.ru/viewtopic.php?f=11&t=3239

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

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

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

Второй целью обеспечения безопасности АСУТП плавно вытекающей из первой, это банальная защита от дурака :).

Далее приведу типичные проблемы, с которыми сталкивался в своей практике при анализе защищенности промышленных сетей.

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

2. Отсутствие блокировки АРМ-ов на физическом уровне.
Что такое АРМ, на типичном таком среднем Российском производстве? Это банальный такой персональный компьютер, на котором крутится винда и поверх рабочего стола растянута «картинка» SCADA. Комп при этом беззащитно стоит на столе оператора.
На какие только ухищрения не идут операторы, чтобы не скучать в ночную смену. Попытки засунуть завирусованные флешки с игрушками в АРМ-ы, опробование различных комбинаций клавиш для сворачивания интерфейса SCADA (им бы терминалы оплаты ломать!). Операторы АРМ-ов это уже далеко не старички, а все больше и больше «продвинутая» молодежь.
Спасает только железный ящик с замком. Почему именно полная блокировка посредством железного ящика? В памяти свежий пример, когда потыкавшись в залитые порты USB, находчивый оператор, просто открутил винтики системника и подключился к внутренним интерфейсам материнской платы. :)

3. Недостаточное разделение между сегментами производственных сетей.
Очень часто видел, как в одной сети крутится и офисные задачи и технологические. Тут даже комментировать нечего.

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

5. Отсутствие парольной политики.
В отчете Позитивщиков говорилось о стандартных инженерных паролях. Это еще цветочки. Пароли зачастую просто не ставят — для удобства. Ни на интерфейсы контролеров и схемы SCADA, ни на административные учетные записи АРМ-ов и серверов.

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

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

Это по правильному, а по неправильному, «Работает и не трогаем, зачем еще что-то обновлять лишние проблемы наживать!» :)

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

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

Теперь немного о другой стороне медали — инсайд и закладки.

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

Не могу не привести пример статьи, когда через закрытую микропрограмму контролера производство хотели поставить «на бабки».
Хитрая подпрограмма отсчитывала временной интервал и стопорила станочек.
plc4good.org.ua/view_post.php?id=107
копия
www.sendspace.com/file/h4681k

Цитата

Присутствует код таймера на 360 рабочих смен по 8 часов. Таймер считает только тогда, когда включен какой-то выход, типа включения гидронасоса усилителя давления, то есть когда станок работает. Когда таймер досчитывает до конца, устанавливается флаг с адресом M13.0 :), типа, все ребята, платите денежки! Что это, как не вымогательство!


Судя по комментариям, случаи далеко не единичны.
Роман @Spewow
карма
44,0
рейтинг 0,0
Информационная безопасность
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (18)

  • +5
    Спасает только железный ящик с замком.

    У нас все компьютеры операторов физически находились в серверной (соседнее помещение). Мониторы и клавиатуры — через KVM.
  • +2
    А у нас операторы не косячат.
    аварийная остановка центрального сервера АСУТП на полчаса, может привести к полному перезапуску производственной линейки

    никакая остановка никаких серверов абсолютно не влияет на работу системы
    • +2
      собственно да и почти всегда, только если операторская станция и сервер ни одно и тоже. а так не критично совсем.
    • 0
      Только не все об этом знают :)
  • +3
    сам постоянно сталкиваюсь с такими же проблемами, только наш отдел на предприятии уже выработал стратегию по обеспечению безопасности. Если по вашим пунктам идти, то сделали следующее:
    1. в каждом цехе своя локальная сеть системы управления, которая связна с заводской сетью с помощью шлюзового компьютера с антивирусом корпоративным, который регулярно (где это можно, ибо есть оооочень древние станции) обновляется;
    2. тут сложнее, где-то как написано выше удаленные терминалы, где-то ящики с замком, а где сделать так невозможно, то просто отключаются внешние USB порты, вынимаются приводы и флопики, в биосе отключается загрузка с флешек и где также возможно закрываются корпуса на ключ, сервера всегда далеко от аппаратчиков в шкафах;
    3. на рабочих станциях только скады, на шлюзовых антивирь и фтп для передачи в заводскую сеть хозучета, все; ну и ребята из ОИТ не имеют на эти станции удаленного доступа;
    4. тут проще, на предприятие если постараться, то можно принести нетбук, но подключить его только удастся к шлюзовому компу и это будет заметно, вайфая нету, свичи под замком;
    5. паролей нет только у аппаратчиков, все админские и инженерные пароли свои собственные, также учетке оператора обрубаем все лишнее от командной строки и диспетчера задач, до проводника и невозможности свернуть или закрыть скаду, и т.д. и т.п., чтобы по ночам не лазили куда не нужно;
    6. обновления не ставим, только критические патчи, также почти везде у нас всё резервируется, от серверов до сети, ну и по всем станциям и серверам есть актуальные бэкапы;
    7. тут сложнее, в основном метод кнута и удар по кошельку чтобы другим не повадно было.
    Работаю вот уже пять лет и проблем было всего пару штук, так что эти методы у нас работают.
    • +1
      С грустью вспоминаю, когда система работала на венгерском D-Mon под QNX. Вот уж пихай что хочешь.
      • 0
        даже не слышал про такое. у нас на заводе целый зоопарк систем, но самое страшное — это питерский Автонит-46. мы сразу бэкапы сделали, а станции на растерзание оставили аппаратчикам — они уже год без дела сидят, так как уже два кривых вала для турбины из Питера пришло))) ждем третий…
      • 0
        Как говорится, почувствуйте разницу :)

        www.exploit-db.com/platform/?p=QNX
        www.exploit-db.com/platform/?p=windows
        • +2
          Чем-то напоминает притчу про неуловимого Джо и почему он неуловим…
          Если бы QNX стоял на каждом «углу» как и винда, то любителей его поломать было бы гораздо больше, и списочки бы были почти одинаковые. Да, конечно QNX гораздо надежнее винды, но я бы не стал особо полагаться на разницу только на основании вышеприведенных списков.
    • 0
      Хорошие методы :)
      2. Вообще стараемся применять многослойный подход при создании рекомендаций инженерам: зайца сначала утопить, потом расстрелять и тд. То есть отключение того же usb в биосе, совмещаем с отключением usb средствами ОС, совмещаем с физической изоляцией. Человеческий фактор и всякие случайности, типа забытых ключей от корпусов АРМ-ов начинают играть меньшую роль.
      4. По поводу замков, сразу вспомнился случай с очередным «дураком». Есть на заводах любители искать и сдавать медь. Вот как то один такой, вскрыл замочек хитрой проволочкой, забрался в распределительный шкаф слаботочки и порезал «ненужные» провода. Вот уж действительно, против лома нет приема.
      5. Еще очень полезно настроить белые списки SRP, особенно когда много однотипных АРМ-ов.
      6. Удобно определять, что где поставить с помощью традиционных сетевых сканеров безопасности. Это как правило применяется при плановых аудитах сети. Там уже стали появляться и проверки компонентов SCAD-а Все проблемы которые вылазят, незамедлительно закрываются. Ибо такие очевидные проблемы, рай для для потенциально занесенной вирусни. Инженеров также учим использовать локальные сканеры, там все просто, запустил и видно какие критические патчи не стоят. Вообще просветительская работа играет очень большую роль, многие просто не понимают зачем это нужно. В идеале, если инженеры с пониманием, аудиты вообще не выявляют никаких очевидных проблем.
    • 0
      Насчет отключения загрузки — как-то столкнулся с тем, что на некоторых материнках даже при отключении в биосе всё равно можно загрузиться с флэшки по нажатию какой-то функциональной клавиши.

      Метод удара по кошельку — это уже организационный вопрос, и требуется вовлеченность начальства в процесс, а также минимальное понимание важности ИБ. Лично я не видел, чтобы где-то назначались штрафы (хотя и давно не видел я реальных производств с цехами и станками, что делать)
  • 0
    1. Антивирусы.

    Если АСУТП уровня станков с ЧПУ (утрирую конечно) — то нет проблем или есть, но они не фатальны. В противном случае отсутствие антивируса вполне понятная вещь (говорю из практики, а не теоретизирую). Производитель АСУТП говорит — не гарантирую совместимость моего софта и антивирусных решений. И точка. И никто не рискнет вопреки рекомендации производителя что-то делать там, где на АСУТП действительно завязано что-то серьезное. И это резонно.
    Выбирать же из производителей средств автоматизации не всегда возможно.
    Вот случится что-то вроде forum.kaspersky.com/index.php?showtopic=255519&st=0 и нарушит работу АРМ-а. И по ссылке еще достаточно безобидный пример. Бывают и хуже, типа полного отсутствия сети, ложных срабатываний, аварийных перезагрузок. И свои тараканы не только у Касперского. Кто пойдет на такой риск?

    2. Есть промышленное защищенное исполнение АРМ-ов. И многие их используют. Да, их тоже можно вскрыть. Но есть разумный предел всему. В конце концов, если человек сойдет с ума, вооружившись инструментом он может много натворить на объекте. Здесь уже другая история и другие меры.

    3. Справедливо. Но не надо обобщать. Воздушный зазор (а не то, что просто сегментация с фв на границе) встречается достаточно часто.

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

    Про «поставить на бабки» — опять же пример по ссылке из разряда «станок с ЧПУ». На серьезных объектах (КСИИ) такое теоретически тоже возможно, но каков риск для желающих подзаработать? Если поймают за руку — мало не покажется. Все же серьезные области курируются и ФСБ и ФСТЭК и прочими серьезными дядями.

    На счет организационных мер — опять же вопрос критичности и масштаба. Если из-за неуемного желания начальника смены станции, допустим, посмотреть кино, не будет выдержена нужная мощность или какая команда РДУ не отработна — будет много всего неприятного для больших дядь, вплоть до всяких там коммисий министерских. И получат по башке все, начиная от руководства и кончая рядовыми. И штрафами там может не ограничиться.
    • 0
      По 6 пункту действительно весьма полезно контролировать сетевой трафик. Может идти как дополнительная мера на особо критичных и серьезных объектах, ибо в системе могут быть дыры удаленной эксплуатации неизвестные производителю, но известные черным шляпам.
      Но обычное Российское производство таким людям врятли интересно, там больше нужна именно защита от дурака.

      По 1. Дело в том что когда «припрет», деваться то некуда будет (тоже из практики). И в авральном режиме будет установка патчей, поскольку сетевой червяк через древние дыры пролезает, где только можно, и установка антивируса с актуальными базами.

      Вот кстати интересная ссылка, по теме заражений.

      цитата
      ***********************
      Началось с жалоб на потери связи клиент-сервер. И еще были жалобы, по симптомам смахивающие на результат действия вредоносного ПО. Если учесть, что я полгода назад лечил этот объект от Conflickera, то я подумал, что опять началось. Хотя уже всех диспетчеров повздрючивали материально, усилили меры безопасности и т.д. вплость до того, что повыдирали USB порты на самых стремных АРМах. Как потом выяснилось, заразу привезла одна из подрядных организаций… Объект распределенный, около 30 САУ на 315 ПЛК, и часть из них у разных подрядчиков. И каждый без спроса норовит всунуть свой программатор в сеть. История банальна до безобразия. Кстати, флешка заражалась только с ихнего программатора, а вот уже мои сервера и АРМы заразились по сети, и воткнутую в них флешку не заражали.
      ***********************

      iadt.siemens.ru/forum/viewtopic.php?t=14276&postdays=0&p=75091
      • 0
        На моей практике при разумном (я даже не говорю — профессиональном и исчерпывающем по мерам) подходе вреда от ав бывает больше. Могу наблюдать уже более 5 лет несколько закрытых техносетей с более-менее вменямым руководством. Ав нет, вирусов тоже. По факту, а не по фантазиям. На счет тех же червяков. Если для работы технологии не требуется tcp 135,139,445 и прочее — как червь пролезет? Запрещаем все, открываем избранное. Веб для тонкого клиента, нужные спефичные порты технософта и все. Никаких конфликеров ака кидо. Или, если подцепили локально — изоляция проблемы за счет жестких acl. Я даже в офисной сети в рамках одного влан-а трафик между юзерами полностью душу, а уж в техносети это просто обязательно делать. Другой вопрос, что решения технические бывают разные и где-то RPC необходим для работы.
      • 0
        Началось с жалоб на потери связи клиент-сервер.

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

    Спустимся чуть ниже. Вот стоит хороший такой контролер, который отпахал уже десяток лет, к нему полно запасных блоков, в свое время за это хозяйство было заплачено немало денег. Отпашет еще десяток лет.
    А вот сетевая часть реализована в нем на огрызке linux-а.
    Внутри стоит
    linux_kernel — 2.4 (сборка 2003 года).

    Подняты и торчат наружу.
    mini_httpd — 1 версии (2003)
    Порт RCP.

    Все крутится под root-ом.

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

    Получается, если строить защищенные сети АСУТП, производитель должен рассматривать с точки зрения ИБ все компоненты системы, а не только акцентироваться на уровне SCADA.
    • 0
      В итоге мы приходим к тому, что интегрированная безопасность нам не светит, потому что всегда там будет линукс, который сегодня свежий-актуальный, завтра там найдут дыры. Итого развиваем безопасность навесную, которая нам прикроет наши дыры и в которой знание дыр обновлять легче-проще, чем прошивки контроллеров и длл-ки винды.
    • 0
      Как правило, системные сервисы выведены на отдельный lan разъем на контроллере (у нас так). Поэтому что-то ломать можно только физически присоединившись к контроллеру.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.