Информационная безопасность энергетического объекта: Вредные советы

Оглавление:

• Про VPN и шифрование
• Про сегментацию сети
  
• Про разделение корпоративной и технологической сети
  
• Про пароли и про контроль доступа
  
• Про сложность эксплуатации
  
• Про коммутаторы
  
• Про диагностику
  
• Заключение
  

Информационная безопасность за последнее время стала очень мощным трендом и только ленивый про нее не говорит. Сейчас уже ни для кого не секрет, что любую локальную вычислительную сеть необходимо защищать, в том числе и промышленную. Но на данный момент, несмотря на то, что разработан Приказ №31 ФСТЭК от 31.06.2014 г. и вступил в силу Федеральный Закон №187 от 01.01.2018 г., еще нет полностью сформулированных шаблонов проектирования, которые бы емко дали понятие, каким образом создать ЛВС, защищенную от всех информационных угроз. Из-за этого часто можно встретить в проектах различные устаревшие шаблоны, которые заведомо создают уязвимости в сети. Phoenix Contact собрал наиболее часто встречающиеся ошибки и представляет их Вашему вниманию в виде вредных советов.

Про VPN и шифрование

Вредный совет: 

Если Вам необходимо передавать данные через Интернет (например, в РДУ), то ни в коем случае не нужно передавать эти данные через VPN-канал и, тем более, шифровать их. И, конечно же, делать этого не нужно и для передачи данных по изолированному каналу. 

Пояснение: 

К любым данным, которые передаются через внешние каналы, существует возможность получить доступ. Чаще всего для этого используется атака Man in the middle («атака посредника» или атака «человек посередине»). Подобная атака подразумевает, что канал связи был изменен таким образом, что данные начинают передаваться непосредственно через злоумышленника и злоумышленник имеет возможность эти данные читать при помощи программ-сниферов. Более того, имея представление об архитектуре сети объекта, злоумышленник сможет отправлять различные управляющие воздействия на первичное оборудование.

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

Про сегментацию сети

Вредный совет: 

Какая бы большая сеть в Вашем проекте ни была, ни в коем случае не разделяйте ее на подсети! Пусть весь траффик передается внутри этой большой сети – ничего страшного, если BPDU-пакет (Bridge Protocol Data Unit пакет) из одного RSTP-кольца (Rapid spanning tree protocol) попадет в другое кольцо. Самое страшное, что может произойти в этом случае, – остановка передачи данных.

Рис. 1 Пример коммутаторов с функцией сегментации сети

Пояснение: 

Действительно несегментированная сеть представляет собой источник самых неприятных проблем – проблем, которые нельзя явно определить. Сценариев возникновения подобных проблем достаточно много. Например, при использовании нескольких колец резервирования на основе протокола RSTP, сеть может вести себя нестабильно из-за того, что BPDU-пакеты из одного кольца попадают в другое. При такой конфигурации топология будет спонтанно перестраиваться, будут теряться пакеты данных и все это может повторяться с совершенно разными интервалами времени. 

Поэтому необходимо на стадии проектирования предусмотреть сегментирование сети путем разделения ее на разные VLAN’ы (Virtual Local Area Network) или разные подсети. 

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

Про разделение корпоративной и технологической сети

Вредный совет: 

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

Пояснение: 

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

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

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

Про пароли и про контроль доступа

Вредный совет: 

Лучше всего – не использовать пароли совсем. В случае, если использование паролей жестко прописано в техническом задании, то используйте простые пароли – password, admin, private, 11111 и т. д. 

Идеально, если к любому АРМу, независимо от его назначения (АРМ инженера релейной защиты, АРМ сетевого инженера и т. д.), будет иметь доступ каждый работник эксплуатирующего персонала, вне зависимости от области его компетенций. Ничего страшного, если инженер релейной защиты попробует поработать с сетью – самым страшным следствием мы можем получить неработающую сеть или, что лучше, неадекватно работающую сеть.

Рис. 2 Межсетевой экран mGuard

Пояснение: 

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

Помимо сложных индивидуальных паролей для всех работников хорошо было бы принять дополнительные меры по обеспечению контроля доступа. Например, сконфигурировать индивидуальный доступ к сети. Это можно сделать при помощи функции User Firewall межсетевого экрана mGuard. Эта функция позволяет, подключив АРМ к ЛВС через mGuard, давать доступ пользователю исключительно к той части сети, с которой ему позволено работать. Таким образом, если администратор сети будет работать за АРМом и авторизуется на mGuard под своим логином и паролем, то будет иметь доступ ко всей сети, а если на данном АРМе будет работать инженер РЗиА, то он получит доступ только к терминалам релейной защиты.

Про сложность эксплуатации

Вредный совет: 

Нет смысла думать о том, как сделать эксплуатацию сети более удобной, лучше всего все действия с оборудованием во время сервиса или эксплуатации производить посредством командной строки. Нет смысла использовать функционал оборудования, который позволяет менять правила фаервола или управлять VPN-туннелями посредством обычных физических кнопок или переключателей на щите управления.

Пояснение: 

Сложность эксплуатации также может сказываться на информационной безопасности. Если каждый раз для проведения сервиса эксплуатирующему персоналу приходится вспоминать, какие правила фаервола включить, а какие отключить, или вспоминать, как организовывать VPN-туннель, то велика вероятность, что при достаточно низкой частоте повтора сервисного обслуживания, после окончания всех процедур, какое-нибудь правило останется открытым, что создаст потенциальную угрозу. Поэтому, по возможности, подобные процедуры необходимо упрощать. MGuard позволяет управлять правилами фаервола с помощью обычных физических переключателей, которые можно разместить на щите управления, а VPN-туннель включать при помощи кнопки. Подобные «упрощения» позволяют облегчить эксплуатацию сети и сделать ее более надежной.

Про коммутаторы

Вредный совет: 

Для построения локальной вычислительной сети лучше всего использовать неуправляемые коммутаторы. И, конечно же, коммутаторы не должны поддерживать стандарт МЭК 61850. Для использования коммутаторов на подстанции нет необходимости в повышенных требованиях к электромагнитной совместимости, механической прочности или климатике.

Пояснение: 

Всегда важно понимать, для каких задач создается ЛВС. Если это будет небольшая сеть, в которой два контроллера собирают по двадцать сигналов с РУСН 0,4 кВ и общаются между собой через один коммутатор, то достаточно будет одного неуправляемого коммутатора. Если мы имеем дело с большой сетью для организации передачи данных в АСУ ТП электрической станции и нам необходимо объединить в рамках одной АСУ ТП десятки терминалов РЗА, предназначенных для работы на различных напряжениях, то необходимо использовать управляемые коммутаторы с поддержкой МЭК 61850. Неуправляемые коммутаторы просто не смогут справиться с тем объемом информации, который необходимо передать, а также не смогут обеспечить должный уровень надежности. Управляемые коммутаторы позволяют организовать резервированную топологию, использовать технологию VLAN или IGMP для работы с потоками данных, диагностировать коммутаторы с помощью SNMP. Поддержка МЭК 61850 обеспечивает уверенность, что оборудование сможет работать в условиях электроэнергетического объекта и, более того, явно говорит о том, что эти коммутаторы передают GOOSE-сообщения с определенной задержкой по времени (что позволяет избежать GOOSE-лавины) и явно поддерживает энергетические протоколы резервирования.

Про диагностику

Вредный совет: 

Нет никакого смысла удаленно диагностировать сеть. Достаточно использовать релейный контакт коммутатора и, в случае неисправности, зажигать соответствующую лампочку на шкафу. Не нужно разбираться с настройкой протокола SNMP для удаленного диагностирования. Все эти данные в SCADA-системе будут излишними. 

Тем более не нужно устанавливать систему обнаружения вторжения для постоянного мониторинга трафика и обнаружения любых угроз в сети. Это значительно усложнит систему и удорожит ее стоимость.

Пояснение: 

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

Заключение

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

Источник: Phoenix Contact