Рус Eng Cn Перевести страницу на:  
Please select your language to translate the article


You can just close the window to don't translate
Библиотека
ваш профиль

Вернуться к содержанию

Электроника и электротехника
Правильная ссылка на статью:

Об информационной безопасности автоматизированных систем управления

Белозеров Владимир Валерьевич

кандидат технических наук

Технический директор, ООО "Компания ТРИТАРТ"

346735, Россия, Ростовская область, г. Ростов-На-Дону, пер. Астрономический, 22/9

Belozerov Vladimir Valer'evich

PhD in Technical Science

Technical Director, LLC "Company TRITART"

346735, Russia, Rostovskaya oblast', g. Rostov-Na-Donu, per. Astronomicheskii, 22/9

isagraf@mail.ru
Другие публикации этого автора
 

 
Кречетов Александр Леонидович

инженер, АО "НТП АВИАТЕСТ"

344000, Россия, Ростовская область, г. Ростов-На-Дону, ул. Пл. Гагарина, 1

Krechetov Aleksandr Leonidovich

Engineer at NTP AVIATEST Company

344000, Russia, Rostovskaya oblast', g. Rostov-Na-Donu, ul. Pl. Gagarina, 1

ko4kanto4ka@yandex.ru
Олейников Сергей Николаевич

кандидат технических наук

Заместитель начальника факультета, Академия государственной противопожарной службы МЧС России

129366, Россия, г. Москва, ул. Бориса Галушкина, 4

Oleinikov Sergei Nikolaevich

PhD in Technical Science

Deputy of the Head of the Faculty, Academy of State Fire Prevention service, Ministry of Emergency situations of Russia

129366, Russia, g. Moscow, ul. Borisa Galushkina, 4

vbfiremen@bk.ru
Другие публикации этого автора
 

 

DOI:

10.7256/2453-8884.2018.4.28516

Дата направления статьи в редакцию:

25-12-2018


Дата публикации:

02-02-2019


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


Ключевые слова:

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

Abstract: The subject of the research is the questions of information security and resistance to unauthorized penetration in automated process control systems. The results of statistical analysis of incidents, failures, accidents and fires on industrial facilities which have different levels of automation are presented. The solution which completely excludes an opportunity by means of a malicious code, to interfere with managing functions of industrial controllers is presented by development of the additional programming module providing data exchange in SCADA system and in managing controllers. The methodological basis of the research is the systems analysis and system synthesis of processes and means in automated systems. The main result of the research is the solution which completely excludes an opportunity by means of a malicious code, to interfere with managing functions of industrial controllers. The price of such solution is the development of additional programming module which will provide data exchange in the SCADA systems projects and in projects of managing controllers, hiding communication parameters, and also random access to memory of managing controllers.


Keywords:

information safety, interface, exchange protocol, network structures, the automated systems, management of technological processes, incident, computer aids, failure of technical means, accident

Введение

Законодательство в области безопасности производственных процессов и объектов требует постоянного совершенствования, во-первых, из-за негативной статистики инцидентов, аварий и пожаров, во-вторых, из-за интенсификации технологических процессов, обусловленных техническим прогрессом, и, следовательно, повышением их пожаровзрывоопасности, в-третьих, снижением присутствия государственного регулирования в предпринимательской деятельности, а в-четвертых, из-за необходимости гармонизации с требованиями [1-5]:

- Конвенции ООН "О трансграничном воздействии промышленных аварий",

- Кодекса и конвенции МОТ по предотвращению промышленных аварий,

- Директив № 82/501/ЕЭС и № 96/82/ЕЭС,

- Закона об аварийных ситуациях (ФРГ).

- Системы актов CIMAH по безопасности в промышленности (Великобритания).

Основными актами в сфере безопасности и охраны труда в Российской Федерации, являются Федеральные законы, определяющие общие правовые, экономические и социальные основы обеспечения безопасности в России, устанавливающие основные положения технического регулирования в этой области и общие требования безопасности к объектам защиты (продукции) повышенной опасности [3-5].

В СССР состояние безопасности в любых организационных системах определялось наличием требований в нормативных документах Госстроя и Госстандарта, а также других ведомств. Число таких документов оценивалось в несколько тысяч, а состав противопожарных требований - в десятки тысяч [5,6].

Со вступлением в силу 184-ФЗ «О техническом регулировании» [3] и соответствующих Технических регламентов, в настоящее время, кроме них, действуют десятки сводов правил и около сотни стандартов. Таким образом, и в настоящее время требования безопасности, изложены в источниках, насчитывающих несколько сотен документов. При этом следует отметить, что принятые своды правил (СП) и государственные стандарты (ГОСТ) в области безопасности, являются документами, которые применяются на добровольной основе. Добровольность применения СП и ГОСТ заключается в том, что многие Технические регламенты предоставляют выбор [5-7]:

- сделать расчет рисков и, если значения, полученные при их расчете, не превышает допустимых значений, установленных Техническими регламентами, то выполнять требования нормативных документов не требуется;

- в полном объеме выполнить требования нормативных документов по безопасности, в частности, требования, установленные ГОСТами и СП.

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

Однако, с точки зрения создания АСУТП, в т. ч. предприятиями малого и среднего бизнеса, в настоящее время имеются факторы, препятствующие исполнению требований безопасности в необходимом объеме по следующим причинам [5-10]:

- из-за конфликта интересов надзорных органов, заказчиков и независимых проектировщиков, монтажников и наладчиков систем;

- из-за низкой правовой и экономической ответственности предприятий малого и среднего бизнеса перед потенциальными заказчиками систем;

- из-за высокой стоимости работ по обеспечению безопасности и стремлении заказчика снизить себестоимость автоматизации;

- из-за «человеческого фактора», присутствующего у заказчиков, проектировщиков, монтажников и наладчиков систем.

Определенные проблемы создает и тот факт, что, за исключением некоторых работ [1,2], пока в нормативных документах не сделано попыток структурировать требования, выделив минимально необходимые, связанные с безопасностью людей. Именно поэтому актуальным остается подход, связанный с выполнением мероприятий в области безопасности в полном объеме.

Анализ статистики инцидентов, аварий, взрывов и пожаров на объектах промышленности

Рис.1 - Инциденты по отраслям промышленности

В пятерку наиболее опасных и подверженных угрозам отраслей входят (рис.1) энергетика, нефтегаз, транспорт, водоснабжение и пищевая промышленность [5,11,12].

Время простоя от инцидентов в большинстве случаев измеряется минутами (рис.2). На втором по частости месте – интервал от 1 до 4 часов. За это время, в зависимости от отрасли, в котором работает объект повышенной опасности, может произойти очень многое – например, от «утечки» бензина на НПЗ (банальной кражи) до пожара и экологической катастрофы с человеческими жертвами [12,13].

Рис.2 – Простои от инцидентов

Рис.3 – Последствия от инцидентов

Наиболее частые последствия от инцидентов предсказуемы (рис.3) - снижение объема производства/операций, потеря управления устройствами, снижение продуктивности персонала

По данным RISI [13] c финансовой точки зрения, статистика объемов потерь почти в 60% случаев не превышает 100 тысяч долларов США (рис.4) .

Рис.4 – Диаграмма масштабов финансового ущерба

С точки зрения АСУТП, чаще всего в инцидентах бывает замешаны контроллеры (PLC), распределенная система управления (DCS), Master SCADA, индустриальный ПК и HMI (рис.5). При этом обнаруживаются инциденты обычно операционным персоналом во время самого инцидента, а на втором месте - обнаружение после инцидента. Обнаружение инцидента с помощью каких-либо средств защиты (рис.6) происходит крайне редко [14].

Отсюда следует ряд важных выводов [5]:

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

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

Рис.5 – Инциденты в оборудовании

Рис.6 – Обнаружение инцидентов

Статистика аварий, несколько отличается от структуры типов и отраслей инцидентов, в т. ч. структурой потерь (рис. 7-10), в которые входят гибель и травмы персонала [2].

Рис.7 - Диаграмма аварий по отраслям промышленности

Рис.8 – Гистограмма гибели и график аварий на ОПО

Рис.9 – «Крест» показателей травматизма в СССР и в России

Рис.10 – Число пострадавших и частота травматизма на 1000 работающих в России

В последнее время, в т.ч. из-за бурного развития АСУТП, появился новый тип угрозы, именуемый информационной опасностью. Пример - пресловутый Stuxnet, работа которого заключалась в изменении работы центрифуг, отвечающих за обогащение урана. Stuxnet как раз и привел к отклонению от режима технологического процесса. А значит, если вдруг Stuxnet проявит себя у нас в России, а он присутствует на отечественных объектах повышенной опасности, то мы будем иметь дело с инцидентом-аварией, подпадающими под действие 116-ФЗ "О промышленной безопасности" [4,13].

Однако на практике сложилось так, что промышленная безопасность и информационная безопасность между собой никак не связаны, как не связаны информационная безопасность и безопасность объектов ТЭК из 256-ФЗ, как не связаны информационная безопасность и транспортная безопасность, как не связаны информационная безопасность и безопасность гидротехнических сооружений [13,14].

Иными словами, причиной инцидентов на всех этих объектах может стать вредоносная программа или иная направленная или случайная атака. Так, например, есть гипотеза, что веерное отключение электроэнергии в США несколько лет назад было связано с червем Slammer, а причиной "слепоты" центров управления авиа полетами во время событий 11-го сентября послужила направленная атака, но под действие законов о безопасности все эти события не попадают [14].

По промышленной безопасности существует огромное количество различных документов, регламентов, инструкций, выпущенных Ростехнадзором или Росатомнадзором. По безопасности объектов ТЭК также есть документы Минэнерго. А вот по информационной безопасности на этих объектах практически нет ничего, а пора бы создать систему, реализующую их взаимодействие и самоорганизацию (рис.11), и в первую очередь – при создании АСУТП объектов повышенной опасности [5].

Рис. 11 – Синергетическая структура процессов управления безопасностью

Статистика инцидентов в АСУ ТП (рис.12) свидетельствует о том, что самым распространенным протоколом, в рамках которого они происходят, все-таки является TCP/IP [5,13].

Рис. 12 – Протоколы, в рамках которых произошли инциденты

Это свидетельствует о том, что существующие средства сетевой безопасности могут быть эффективно использованы для защиты АСУ ТП. Действительно, второе, третье и четвертое место занимают индустриальные протоколы, которые должны распознаваться и фильтроваться выбираемыми средствами защиты. Однако гистограмма типов инцидентов (рис.13) показывает, что вредоносное ПО, попавшее внутрь извне, является основной проблемой даже в индустриальных сегментах. Вопросы надежности железа и системного/микропрограммного обеспечения находятся на втором и четвертом местах соответственно. Это свидетельствует о необходимости внедрения SDLC, соответствующего тестирования и приемочных испытаний АСУ ТП, наличия адекватной процедуры выбора оборудования и ПО, соответствующей процедуры управления обновлениями и т.п.[13-16].

Рис. 13 – Типы инцидентов

Учитывая, что вредоносное ПО - самый распространенный тип инцидентов, а на втором месте – отказы и на третьем - проникновение в систему, приходим к выводу, что основным типом нарушителя для индустриальных сетей является внешний нарушитель/вирусописатель. И поэтому в АСУ ТП ОПО должны в обязательном порядке предусматриваться средства идентификации и защиты [5,17,18].

Рис. 14 – Типы «нарушителей»

Требует дальнейшего изучения статистика по точкам входа в индустриальный сегмент (рис.15), которые в большинстве случаев - не определены.

Рис. 15 – Точки нарушений

Как следует из гистограммы (рис.15), на втором месте - точка соприкосновения с корпоративной сетью, а на третьем - удаленный доступ. Данная статистика опровергает мнение о том, что индустриальные сегменты не подключены никуда и изолированы от Интернета, от корпоративной сети, от сетей третьих лиц и т.п.[5,13].

Интересны данные (рис. 16,17) уязвимости АСУ ТП, представленные американской компании Red Tiger, занимающейся аудитом и тестами на проникновения в индустриальные сети [13,14].

Рис. 16 - Диаграмма по уровням инцидентов (%)

Рис. 17 - Диаграмма инцидентов (%) по процедурам ПО

Синтез возможных решений

Разработчики АСУ ТП, для уменьшения рисков проникновения в локальную сеть самой АСУ ТП либо физически исключают такую возможность путем отсутствия каналов связи с любой другой сетью [5], либо проектируют межсетевой экран (Firewall).

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

Рисунок 18 - Место межсетевого экрана в сети

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

Таблица 1. Группировка правил для обработки сетевого трафика

Группа

правил

Назначение

Правила доступа

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

Прикладные

правила

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

Системные

правила

Используются для ограничения доступа к защищаемым компьютерам по сетевым протоколам, перечень которых определен в документе RFC 1700. При использовании данного вида правил аутентификация отправителей и получателей IP-пакетов не производится, ответный трафик не отслеживается

Сетевые

протоколы

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

• IPv4;

• IPv6;

• Novell IPX;

• некоторым протоколам с устаревшим форматом Ethernet-кадра (LLC,

IPX)

Защита от

сетевых

сбоев

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

Однако по оценкам ICS-Security в 2017 году, по сравнению с 2016 годом, проведенные исследования о доступности компонентов АСУ ТП в сети Интернет показывают возрастание. Это обусловлено увеличением использования доступных протоколов семейства HTTP внутри предприятия, которые предоставляют удобство руководству для дистанционного контроля над производственными процессами. Да и разработчики SCADA систем расширяют свои архитектуры для персональных коммуникационных устройств, например смартфоны, планшеты и т.д. с использованием WEB и других технологий [19].

Самое уязвимое место в АСУ ТП с использованием SCADA-систем (а это подавляющее большинство) – это возможность добавления фрагментов кода в процессе выполнения производственных задач (Runtime), т.к. для программирования рабочего места оператора (или сервера) на базе SCADA-системы, используются скриптовые языки Си, VB и т.д. Также уязвимым местом является подключение SCADA системы напрямую к переменным промышленных контроллеров через технологию ОРС Foundation. Проникший код на АРМ оператора в SCADA-систему легко может узнать о параметрах связи с управляющими контроллерами. Зная протоколы производителей промышленных контроллеров или их порядок загрузки исполнительным кодом, хакеры могут нанести предприятию непоправимый вред, т.е. повлечь за собой инциденты, аварии, разрушения и даже человеческие жертвы [19,20].

Для невозможности вредоносному коду, с помощью SCADA систем совершить подобное, предлагается исключить возможность SCADA системы иметь прямое соединение с промышленными контроллерами еще на стадии проектирования, для чего созданы модели и алгоритмы (рис.19) для автоматизации построения таких систем [5,20].

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

Рис. 19 - Блок-схема модулей АСУ ТП

Если даже не использовать модуль представления объектов, как это было сделано на ряде ОПО [5,20], то предлагаемый модуль обмена данными можно использовать как посредник, который с одной стороны обеспечивает данными алгоритмы управляющих контроллеров от SCADA-системы, а с другой стороны доставляет необходимые данные для SCADA-системы от промышленных контролеров. Такой модуль можно спроектировать таким образом, чтобы SCADA-система находилась даже не в одной подсети с промышленными контроллерами, чтобы исключить сканирование портов в текущей подсети вредоносным кодом, для выявления адресов компонентов АСУ ТП.

Выводы

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

Библиография
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.