Удаленный доступ: 17 важных правил

Дата: 15.06.2020. Автор: Игорь Б. Категории: Статьи по информационной безопасности
Удаленный доступ: 17 важных правил

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

Существует несколько форм удаленного доступа:

  • Внешний удаленный доступ, например, поставщика услуг. Для него требуется интерактивный доступ, часто с привилегированным доступом к критическим функциям ICS.
  • Внутренний удаленный доступ, например, для инженеров технической службы или IТ-персонала. Им также часто нужен привилегированный доступ.
  • Удаленное управление, что обеспечивает возможность управлять производственным процессом дистанционно. В отличие от удаленного доступа для поддержки этого типа соединения требуется наличие постоянной связи, что, конечно, не должно мешать оператору технологических процессов выполнять свои задачи.
  • Удаленный мониторинг, например, мониторинг работоспособности турбин или генераторов, устья скважины; а также доступ к аналогичным диагностическим и контрольным функциям.
  • Удаленный мониторинг технической инфраструктуры, например, обеспечение производительности сети, или удаленное подключение к центру управления безопасностью (SOC).
  • Удаленное обновление, например, ежедневные обновления антивирусника, вакцины IPS или осуществления некоторых поправок в работе системы безопасности.

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

Удаленное соединение рассматривается как соединение с сетью с другим уровнем «доверия». Слово «доверие» стоит в кавычках, потому что есть множество дискуссий по этому поводу: что такое «доверие» в информационной безопасности, как стоит верно называть это явление. Не хочется вступать в дискуссию, связанную с определением этого понятия.

Правило 1. Каскадный риск. Применение раздельных протоколов при передаче DMZ.

Удаленный доступ: 17 важных правил

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

Недавно было выявлено несколько уязвимостей RDP, которые считаются «червивыми», то есть сетевой червь может воспользоваться ими для заражения сети. Таким образом, это позволит ему заразить корпоративную сеть, добраться до терминального сервера и оттуда захватить всю управляющую сеть. Подобная опасность является очень актуальной во времена распространения различными вымогателями сетевых червей.

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

Правило 2. Риск взлома. Предотвращение входящих подключений.

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

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

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

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

Правило 3. Риск получения учетных данных для входа. «Принудительная» двухфакторная аутентификация.

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

Это сильно укрепляет защиту сети. Лучше всего доверять такому физическому токену, как «брелок», который будет генерировать код. Альтернативными вариантами являются токены, установленные на ПК или в виде программного обеспечения, или с помощью USB-устройства.

Правило 4. Риск несанкционированного доступа.

Применение определенного механизма для подтверждения, когда кто-то «доверенный» имеет право запустить работу удаленного доступа. Обычно после запроса по телефону или оператор (супервайзер), или инженер технической службы должен одобрить доступ для человека, чтобы соединение было установлено.

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

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

Правило 5. Риск запрещенного трафика.

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

Зашифрованные туннели не позволят брандмауэру просматривать трафик, поэтому не вызовут детальных проверок. Лучше всего «сломать туннель», чтобы он был проверен брандмауэром, и потом привязать его к узлу доверенной сети. Где именно «сломать туннель» – это спорный вопрос, но предпочтительно это сделать в DMZ. Туннельный трафик может содержать незащищенный текстовый обмен данными, поэтому нужно быть осторожным, когда вскрываешь туннель.

Правило 6. Риск несанкционированной активности.

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

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

Правило 7. Риск несанкционированной активности.

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

Правило 8. Риск несанкционированной деятельности.

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

Правило 9. Риск несанкционированного доступа.

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

Правило 10. Риск получения конфиденциальных данных.

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

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

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

Правило 11. Риск получения конфиденциальных данных.

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

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

  • Учетные данные доступа для конкретного сайта не будут раскрыты. Если доступ больше не требуется, достаточно отключить или удалить доступ к функции прокси-сервера, чтобы заблокировать человека.
  • Принудительный доступ с помощью такой прокси-функции блокирует возможность перехода между серверами, поскольку пользователь не знает пароля. Это требует соблюдения определенных ограничений доступа для пользователей в целом.

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

Правило 12. Риск несанкционированной активности.

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

Правило 13. Риск несанкционированной активности.

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

Правило 14. Риск несанкционированной активности. Ее обнаружение.

Нужно развивать ситуационное сознание. Вся идея создания зоны DMZ состоит в том, чтобы иметь ту зону, где можно провести подробные проверки, прежде чем впустить трафик. В правиле 5 уже упоминалось о том, что есть возможность вскрыть туннель, чтобы осмотреть его, но, конечно, есть еще много чего, что стоит проверить. Если не применяются механизмы обнаружения, должно быть исключительное внимание к профилактике. Пользователь понимает, что все в порядке, когда он «открывает дверь».

Но, к сожалению, это не совсем так. Необходим механизм обнаружения, чтобы проверить, не происходит ли ничего подозрительного. Сосредоточение исключительно на профилактике — это обычная ловушка!

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

Правило 15. Риск взлома, каскадный риск. Патчинг, патчинг, патчинг.

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

Правило 16. Риск заражения вредоносными программами, каскадный риск.

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

Правило 17. Риск несанкционированных действий

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

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

Автор переведенной статьи: Sinclair Koelemij

Игорь Б

Об авторе Игорь Б

Автор на портале cisoclub.ru. Добавляйте ваш материал на сайт в разделе "Разместить публикацию".
Читать все записи автора Игорь Б

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *