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

Описание

В большинстве случаев состояния предупреждений являются логическими (True, False) и запускаются определенными условиями, как показано ниже. Например, бит триггера для предупреждения "Избыточное давление" становится ИСТИННЫМ, если "Condition 1", "Condition 2", "Condition n", являются ИСТИННЫМИ. 

Чтобы замаскировать атаку, противник может подавить бит триггера оповещения и вызвать ложное отрицание (не срабатывание). 

Ловушка для ложных отрицаний (не срабатываний) отслеживает условия для бита триггера и самого отрицательного бита триггера. С помощью этой простой настройки обнаруживается ложный отрицательный результат. Смотрите следующее изображение: 

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

Таким же образом могут быть обнаружены ложные срабатывания - путем мониторинга бита триггера предупреждения и выполнения условий триггера. Если условия НЕ выполняются, но бит триггера активен, обнаруживается ложное срабатывание, см. следующее изображение: 

Примеры

Пример1: Siemens предлагает в своих продуктах Siemens S7-1200/1500 веб-сервер с широким спектром функций, например, отображение состояния ПЛК, времени цикла или объема записей. Он также имеет возможность просматривать и изменять таблицы данных и переменные. Права доступа к веб-серверу могут быть изменены в настройках аппаратного обеспечения ПЛК. В случае неправильно настроенных прав доступа злоумышленник может получить доступ к переменным ПЛК и блокам данных. Чтобы создать ложное срабатывание, злоумышленник выбирает бит триггера и изменяет состояние. 

Пример 2: В атаке Triton/Trisys/Hatman мошеннический код подавлял состояние оповещения. 

Пример 3: Атака с внедрением в линию обмена данными позволяет отправить ложноположительное предупреждение высокоуровневому клиенту SCADA. 

Безопасность

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

О проекте Secure PLC Programming

В течение многих лет программируемые логические контроллеры (ПЛК) были небезопасны по своей архитектуре. Несколько лет отладки и применения лучших практик IT привели к созданию безопасных протоколов, зашифрованных коммуникаций, сегментации сети и т.д. Однако на сегодняшний день не уделялось особого внимания использованию аналогичных функций в ПЛК (или SCADA/DC) для обеспечения безопасности или тому, как программировать ПЛК с учетом безопасности. Этот проект, вдохновленный существующими методами безопасного кодирования для IT, заполняет этот пробел. 

Кому следует прочитать и внедрять методы безопасного кодирования ПЛК?

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

Какова область применения этого списка / как вы определяете программирование ПЛК?

Чтобы соответствовать объему списка 20 лучших методов безопасного кодирования ПЛК, методы должны включать изменения, внесенные непосредственно в ПЛК. То, что вы видите в этом документе — это 20 лучших вариантов из большого числа потенциальных методов безопасного кодирования ПЛК. Существуют также дополнительные проекты практик, относящиеся к общей архитектуре, HMI или документации. Они не вписываются в рамки безопасного программирования ПЛК, но могут быть включены в будущий список по безопасности среды для ПЛК. 

Каковы преимущества применения правил из данного списка?

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

От себя

Проект proPoll

Стартовал опрос специалистов области промышленной автоматизации, благодаря которому планируем составить общее представление о состоянии индустрии, а также попытаться заглянуть в будущее. Расскажите о своем опыте, что займет у вас буквально 5 минут.

Результаты опроса будут опубликованы в telegram-канале @pro_PLC в конце декабря 2021. Просим помочь в распространении данного опроса, делитесь ссылкой в рабочих и профессиональных чатах. https://forms.gle/VKNf21VCSPjSXGSa8

Сообщество

Приглашаю всех в telegram чат и telegram канал для специалистов в области промышленной автоматизации. Здесь можно напрямую задать очень узкоспециализированный вопрос и даже получить ответ.

Жду ваше мнение и опыт относительно данного пункта в комментариях. Всего было 20 пунктов из "Top 20 Secure PLC Coding Practices".

Безопасность ПЛК: 16-19) Отслеживайте длительность циклов, потребление памяти, логируйте аварийные ситуации.

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


  1. anonymous
    00.00.0000 00:00


    1. Efi-fi Автор
      03.12.2021 07:35
      +2

      В некоторых случаях ПЛК должны быть подключены к сети, для удалённого мониторинга и управлния.


  1. anonymous
    00.00.0000 00:00


  1. Efi-fi Автор
    03.12.2021 08:40
    +2

    Разные ситуации требуют разных подходов к безопасности. Зачастую дополнительные меры безопасности, заложенные в ПЛК себя оправдывают, если на кону большие деньги или жизни/здоровье людей -- лучше перестраховаться.


  1. anonymous
    00.00.0000 00:00


  1. F0iL
    03.12.2021 10:56
    +1

    Пример Stuxnet показывает, что даже Air Gap не является стопроцентной защитой. А в вопросах кибербезопасности всегда работает принцип швейцарского сыра.


  1. SergeyT-hh
    03.12.2021 11:39

    Чтобы замаскировать атаку, противник может подавить бит триггера оповещения и вызвать ложное отрицание (не срабатывание). 

    Чем отличается действие противника (хакера?) по подавлению бита триггера оповещения и вызову ложного отрицания (не срабатывания) от, например, разрыва кабеля между шкафами?


    1. Efi-fi Автор
      03.12.2021 11:46

      При обрыве кабеля не будет сообщения по не срабатыванию оповещения. А в случае с подавлением бита программа сможет обнаружить это с помощью описанного выше алгоритма.

      Отслеживание физических разрывов -- это другая задача.


      1. SergeyT-hh
        03.12.2021 17:38

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