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

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

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


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

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

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

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



    Проблема 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. Данные риски требуют собственных ряда действий и мероприятий, как минимум учитывающих:
      • колоссальную критичность и непрерывность бизнес-процессов;
      • практическую невозможность обновлений;
      • практическую малоприменимость или неприменимость традиционных систем ИБ и, в частности, механизмов блокирования.

    Но сколько бы ни было ограничивающих факторов, защищать АСУ ТП все же необходимо. Во второй части статьи мы расскажем о том, как, учитывая указанные проблемы, осуществлять полноценный мониторинг и реагирование на кибератаки. Опять-таки, с живыми примерами и кейсами от заказчиков. Не пропустите!
    Ростелеком-Solar 165,56
    Безопасность по имени Солнце
    Поделиться публикацией
    Комментарии 28
    • 0
      А где будет привязка к ФСТЭК 31? Ну и 187-ФЗ для полного счастья?
      • 0
        Возможно, в одной из следующих статей по теме. В этом цикле мы планируем рассказать о задачах практической безопасности, не концентрируясь на вопросах регулирования.
      • +1
        Общение с АСУТПшниками на тему безопасности, процесс весьма сложный. В отрасли среди технических специалистов бытует мнение, что всё «секьюрити» — это нечто ненужное, мешающее работать, и придуманное только для выкачивания денег из заказчиков.

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

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

              «Да зачем оно надо, если злоумышленникам проще и эффективнее внедрить/подкупить своего человека на месте».
              А человек на месте — это история чуть другой безопасности, и как раз она, по нашему опыту, на критичных объектах на должном уровне.
          • –1
            Чтобы общение с АСУТПшниками не было столь сложным процессом, попробуйте для начала хотя бы минимально понять, что такое АСУТП, чем отличается от обычных информационных систем. Не пытайтесь, чуть сунувшись в тему, учить людей, что и как надо делать. Лучше сами поучитесь, полезно.
            • 0
              6 лет в АСУТП, из них последние полтора года — ведущим инженером, 6 сданных проектов в сфере нефтегазодобычи, как нижний (в зависимости от проекта от 10 до 150 удаленных объектов на контроле + отдельные площадочные объекты), так и верхний уровень (OPC с драйверами, HMI, плюс интеграция с другими системами предприятия). Этого достаточно, чтобы учить людей, что и как нужно делать?)
              • 0
                17 лет в АСУТП, количество сданных проектов после 10-го считать перестал. Чем ещё меряться будем? :)
                По сути:
                — Дыры в контроллерах. Есть и будут. Постепенно фиксятся производителями, но специфика такова, что быстро это не сделать — в продакшн выводить можно только то, что уже хорошо откатано на стендах. Технологическая установка — не база данных, из бэкапа не восстановишь. Проблема всех «привносимых извне» систем закрывания этих дыр в том, что они не решают имеющихся проблем, и при этом в лучшем случае — просто не ухудшают характеристик системы. И зачем такая радость?
                — Несовершенство протоколов. Да, несовершенны. Разработаете совершенный — вам памятник при жизни поставят. Но когда ИБшники мне принесли схему с 19 (!) файрволами между DCS и ПАЗ — были посланы искать SFP-модуль для Profibus DP :). Ну вот использовали они его в схеме. Что такая схема могла улучшить?
                — Нормальные пароли. «Нормальные» — это 16 знаков со спецсимволами, переменным регистром и прочими радостями жизни? Ну так это само по себе офигенная дыра в безопасности: никто таких паролей не помнит (особенно, когда их минимум 2 на устройство, количество устройств в системе — не меньше десятка, количество систем в обслуживании — 15-20 штук, и требование смены всех этих паролей раз в 3 месяца). Отсюда — файлы с паролями на компьютерах. В лучшем случае. В более плохом — пароли на стикерах, приклеенных к мониторам. В худшем — единая на все объекты интегратора схема придумывания паролей, зная которую можно подобрать пароль к любому устройству любого объекта. Кстати, наиболее часто используемая схема.
                — Обновления хотя бы там, где возможны. Только после официального подтверждения производителя оборудования и ПО, что это обновление опробовано и ничего в системе не ломает.
                «Ваш air gap в половине случаев на самом деле никакой не air gap, и в принципе не работает.» На любую защиту от дурака отдел кадров найдёт более талантливого идиота. Если air gap не работает — такова же будет судьба 19 файрволов.
          • 0
            Слышал слышал про такое на заводах.
            Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы.

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

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


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

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

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

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

                            (это я к чему, собственно: не всегда один подход годится везде)
                            • 0
                              А вы сами ничего не забыли? Например, ознакомиться и разобраться с тем, о чем говорят ИБшники?
                              Ибо
                              Когда вы предлагаете анализировать информацию между контроллером и полевыми устройствами и, при наличии обоснованных подозрений, блокировать её

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

                              Всё очень просто. Если ИБшники уже оказались на предприятии, значит, руководители и тех. специалисты «наверху» понимают, зачем это надо (распильно-откатные случаи не рассматриваем, они бывают, но, к счастью, не в большей части).
                              А неприязнь «суровых АСУТПшников» на объекте идет исключительно из-за неграмотности и непонимания, откуда и вытекают всякие убеждения вида «вы только мешаете» и «менеджеры опять дичь впарили».
                              • +1
                                Ну, тогда продукт под названием KICS и его разработчиков Вы отнесли к числу неадекватных ИБшников :)
                                Предлагалась следующая схема:
                                1. Пассивная часть. Берётся все сетевое оборудование, на каждом из свитчей зеркалится весь трафик на один из портов, из которого идёт на внешний сервер для анализа. Оставим за скобками то, что нередко протоколы проприетарны и внутренности их производитель вот так просто разглашать не будет. Ограничились для пилотного проекта объектом с заведомо поддерживаемым оборудованием — системой от Siemens (опять же, если посмотреть в список поддерживаемого оборудования и ПО — там от Siemens только WinCC OA, который не совсем WinCC и не совсем Siemens, ну да ладно). То, что изменения в конфигурации мы не будем делать и не разрешим делать без согласования с разработчиком системы — пришлось объяснять. Хотя на мой взгляд такие требования — из области «само собой разумеется». Опять же, оставим за скобками то, что установленное оборудование такого зеркалирования делать не умеет. Ну вот не характерно это для промышленного сетевого оборудования. Вариант поменять всё на cisco… блин, где cisco, а где profinet… кого я там, Вы говорите, недопонял? Вариант внедрить туда ещё устройства для выдёргивания трафика из каждого физического линка… ну как бы это сказать… интересно, людям знакомо понятие «надёжность»?
                                Далее, опять же касаясь пассивной части. Анализ этого самого трафика на «легитимность». Уже хорошо, что нам не предложили какой-либо «эвристический анализатор» (либо ещё какой «думатель»). То есть — правила прописываются вручную. То есть — человек, прописывающий эти правила, по сути должен повторить проект АСУТП в виде этих правил. Учитывая количество устройств, вариантов блокировок на них, алгоритмов управления — количество правил на объекте получилось бы где-то к сотне тысяч. ИБшники готовы к такому объёму? Уверены? А отследить все косяки в таком объёме они в состоянии? Точно? А работу правил, которые нельзя опробовать, они готовы гарантировать?
                                2. Активная часть. От которой отказались сразу и безоговорочно. Предлагалось на основе того, что наанализоровала вышеописанная пассивная часть, блокировать трафик, признаваемый нелегитимным. Не знаю, каким образом. Дополнительные устройства? Отрубание портов, откуда идёт «атака» на существующих свитчах? Бред, вы говорите? Что я здесь «неправильно понял»? Открытым текстом — блокирование нелегитимного трафика.
                                3. Также активная часть. Тут уже, в отличие от п.1, нужны не зеркальные порты свитчей, а доступ в сеть со стороны внешнего сервера. Сервер периодически залезает в контроллеры и сверяет версии и контрольные суммы загруженных модулей. Где гарантия, что этот самый сервер не будет скомпрометирован и использован для атаки на эти самые контроллеры? Ведь его предлагается оставлять в сети постоянно, в отличие от инженерной станции/программатора, подключаемых в случае необходимости выполнения каких-либо работ. И, в отличие от операторского интерфейса (также постоянно подключенного), этот сервер уже имеет в себе необходимые для доступа к «потрохам» контроллера компоненты. Ну и нафиг нам эта пороховая бочка?
                                «Предложения и меры обычно лежат в совершенно в других плоскостях и с другими обоснованиями.». В каких, интересно? Или «у нас есть такие приборы, но мы вам про них не расскажем»?
                                • 0
                                  При всем при этом необходимо уложить коэффициенты надежности и время восстановления в ГОСТ ))))

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

                            Самое читаемое