Пять распространенных изъянов в защите АСУ и как с ними бороться

Давайте рассмотрим изъяны в защите АСУ и способы их устранения.

Слабые пароли

По возможности вводите и поддерживайте политики безопасности, требующие использования сильных паролей. Это может включать в себя политики блокирования учетных записей для уменьшения вероятности взлома путем перебора паролей: для среды АСУ это не идеальный вариант, но он подходит для системы, которая должна быть подключена к Интернету.

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

Плохое управление патчами

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

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

Неструктурированная архитектура сети и/или ненужная связь с корпоративными ресурсами и Интернетом

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

Одна из важных мер — как можно скорее внедрить стандарт ISA 62433 и сегментировать вашу среду. Это само по себе обеспечит изоляцию критически важных ресурсов и позволит провести четкую демаркационную линию.

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

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

Отсутствие аутентификации ресурсов

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

Учетные записи с именами и паролями по умолчанию

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

Конечно, вы скажете: «Нужна целая вечность, чтобы сменить пароли на всех объектах». Но все-таки стоит придумать пароли для всех пятидесяти и установить их, особенно на тех, которые имеют выход на интранет/Интернет. Время и энергия, потраченные на смену паролей с самого начала, окупятся, ведь на поиск и ликвидацию прорыва уйдет куда больше работы, не говоря уже о необходимости объяснять руководству, почему из-за проблемы с паролями произошло  проникновение в среду управления.