Какие решения защищают промышленность от киберпреступников и катастроф
Безопасность
08.09.2020, Вт, 11:00, Мск
Проблемы обеспечения информационной безопасности в АСУ ТП сегодня оказались как никогда актуальными. Источник этих проблем заключается не только в постоянно растущем количестве информационных атак на системы автоматизации и ужесточении требований по защите таких объектов (например, законодательные требования по защите значимых объектов критической информационной инфраструктуры и критически важных объектов), но и в недостатке практических наработок по защите подобных систем.
В СМИ представлен широкий спектр теоретических и зачастую недостаточно подкрепленных практикой материалов о подходах к разработке и созданию систем защиты информации АСУ ТП. Авторы данной статьи решили восполнить этот недостаток, поделиться не только своим подходом к решению этой задачи, но и практическими кейсами эксплуатации специализированных систем защиты информации в АСУ ТП.
Какие риски несет нарушение безопасности АСУ ТП:
- локальные аварии и крупные техногенные катастрофы;
- крупные экономические риски вследствие нарушения технологических и производственных процессов предприятия;
- мошенничество и хищение посредством скомпрометированных АСУ ТП.
Подход УЦСБ к решению задачи заключается в построении комплексной системы защиты информации АСУ ТП, неотъемлемой функцией которой является непрерывный и всесторонний мониторинг состояния ИБ АСУ ТП. При этом учитываются такие особенности защищаемых систем, как:
- наличие специализированного оборудования, программного обеспечения (ПО) и протоколов передачи данных;
- наличие распределенных, изолированных АСУ ТП и других особенностей архитектуры;
- требование обеспечить отсутствие влияния средств защиты информации на технологический процесс.
Описанный подход реализован в DATAPK — отечественном решении, разработанном компанией УЦСБ и сертифицированном ФСТЭК России.
Основной принцип функционирования DATAPK — непрерывное отслеживание различных показателей функционирования защищаемого объекта на предмет отклонений от безопасного эталонного состояния. С точки зрения функциональности DATAPK позволяет проводить автоматизированную инвентаризацию объектов защиты, управлять событиями безопасности, связанными с АСУ ТП, выявлять связанные с ними сетевые аномалии и контролировать компоненты АСУ ТП на предмет соответствия требованиям информационной безопасности предприятия.
Особенностью DATAPK является связывание результатов анализа разнородных данных (сетевой трафик, события, конфигурации, состояние защищенности) воедино с целью получения полной картины состояния ИБ в АСУ ТП и реализации широкого перечня мер по обеспечению безопасности КИИ, в т. ч. приведенных в приказе ФСТЭК России №239 от 27 декабря 2017 г.
«Массовые внедрения DATAPK на объектах заказчиков из различных сфер промышленности начались в 2017 году. С первыми внедрениями мы начали решать реальные проблемы, с которыми сталкиваются заказчики на действующих производствах и непрерывно функционирующих АСУ ТП», — рассказывает Алексей Шанин, директор лаборатории DATAPK.
Что дает аудит сети АСУ ТП
В УЦСБ отмечают, что одной из основополагающих функций DATAPK является пассивный анализ сетевого трафика, который позволяет получать сведения о составе узлов, подключенных к сети передачи данных, потоках данных, которыми узлы обмениваются между собой, а также о наличии признаков атак киберпреступников или небезопасных настройках компонентов АСУ ТП.
В ходе одного из внедрений DATAPK, несмотря на то, что специалисты компании-заказчика полагали, что они осведомлены о том, какие сетевые устройства подключены к сети АСУ ТП и каким сетевым трафиком они обмениваются, проведенный анализ показал, что службе автоматизации известны лишь 20% этого трафика, а еще столько же было распознано как стандартный служебный трафик сети. Вместе с тем, некоторая часть трафика являлась нарушением политик безопасности, другая — вызвала сомнения в легитимности. Был и такой трафик, о котором служба автоматизации не знала ничего.
В нелегальном трафике были обнаружены потоки данных двух видов: созданные средствами удаленного администрирования и созданные смартфонами, слабо относящимися к функционированию АСУ ТП.
«Попутно мы выявили ряд нарушений политики безопасности, в частности, нелегитимное использование общих файловых ресурсов, а также использование небезопасных протоколов (SNMP v1, telnet и пр.). Дальнейшие действия компании-заказчика были направлены на устранение выявленных недостатков, и, как следствие, повышение уровня защищенности АСУ ТП», — уточняет Алексей Шанин.
Что можно найти в характеристиках объектов защиты
Понятно, что в АСУ ТП зачастую применяются не только не самые современные средства вычислительной техники, но и даже откровенно устаревшие. На них работают аналогичные версии общего и специального ПО, которые могут быть весьма уязвимы. Их обновление — рискованная затея, которая может обернуться серьезными нарушениями в работе аппаратных платформ и самих автоматизированных систем. Кроме того, обновление не всегда возможно, поскольку речь может идти о программном обеспечении, разработанном уже несуществующим производителем. Модернизация же оборудования требует дополнительного финансирования и экономически не всегда оправдана.
Вследствие указанных причин, а также из-за, к сожалению, часто оправданных опасений потенциального негативного влияния на технологические процессы многие предприятия отказываются от использования антивирусов в промышленных сегментах своей сети. Риск заражения вредоносным программным обеспечением при этом остается, и для его снижения необходимо принимать иные компенсирующие меры.
«Один из наших заказчиков на АРМ (автоматизированное рабочее место) АСУ ТП косвенными способами выявил наличие вирусного заражения, как оказалось, довольно старым вредоносным ПО. Наша задача заключалась в том, чтобы найти все зараженные АРМ и серверы, в которые «червю» удалось проникнуть. Поиск осуществлялся централизованно с помощью комплекса DATAPK по спискам процессов всех объектов защиты, подключенных к системе мониторинга ИБ АСУ ТП. Нужно было найти все объекты защиты, на которых появлялись процессы вредоносного ПО», — вспоминает Алексей Шанин.
В итоге на предприятии были обнаружены зараженные АРМ и серверы на различных производственных площадках нескольких заводов заказчика, после чего были приняты меры по удалению вредоносного ПО. Антивирусное решение при этом не потребовалось.
Как собрать данные с устаревшего оборудования
Другая грань проблемы устаревшего оборудования — сбор данных с нетрадиционных устройств (чересчур современных в сравнении с остальной инфраструктурой или наоборот) при построении системы мониторинга безопасности АСУ ТП. Ситуация может усугубляться отсутствием альтернативных способов получения хотя бы косвенной информации о значимых с точки зрения информационной безопасности параметрах устройств: скудность информации, передаваемой по SNMP, и отсутствие поддержки Syslog. ИБ-вендоры в подобных ситуациях делают заключение о том, что следовало заменить такое оборудование несколько лет назад, либо обещают закрыть вопрос патчами, но этот процесс растягивается на годы. К решению проблемы компанию это никак не приближает, более того — делает риски куда более очерченными.
«В комплексе DATAPK реализован конфигурируемый сбор данных (конфигурации, события, состояние защищенности). Без привлечения разработчиков — силами проводящего внедрение интегратора или даже самостоятельно с помощью консультаций технической поддержки — можно реализовать сбор данных с произвольного объекта защиты путем создания скрипта сбора данных, либо модификации существующего скрипта. Единственное ограничение — объект защиты должен быть доступен по одному из протоколов: MSRPC (в т. ч. WMI), WinRM, SSH, Telnet, SNMP, SMB, SCP, FTP, NFS, MSSQL, Oracle DB, MySQL, PostgreSQL, Firebird, S7comm, PROFINET, Modbus TCP, OPC UA и некоторых других», — указывает Алексей Шанин.
При этом скрипты сбора данных подписываются электронной подписью, вследствие чего их несанкционированное изменение и запуск на DATAPK невозможны.
«В продолжение разговора о гибкости DATAPK приведу пример из одного из пилотных внедрений, когда АСУ ТП одного из именитых производителей не использовала стек протоколов TCP/IP. В данном случае нам потребовался образец трафика и 15 минут работы нашей лаборатории для того, чтобы обеспечить разбор протокола средством глубокой инспекции пакетов и выявление запрещенных команд в адрес ПЛК (программируемый логический контроллер)», — заключает Алексей Шанин.
Полный текст статьи читайте на CNews