Comments 3
Еще бывают такие злоумышленники
Мне кажется, стыдно для рекламы своего устройства давать абсолютно противоречащие реальности советы. Маркетинг должен иметь пределы — нагнать FUD, а потом упомянуть, что у нас есть устройство за $$$$, которое может быть полезно* — это обычное дело. Но с кучей, казалось бы, технически грамотных подробностей продвигать свою сверхкрутую систему охраны для ворот, которые стоят посреди поля и не упомянуть даже, что вообще-то ворота там для красоты стоят, а злоумышленник их просто вокруг обойдёт — это некрасиво.
Не было, нет и не будет никакой безопасности в системах автоматизации. Они не для того. Не имеет значения, правильно ли там проверяется пароль. Наплевать, есть ли в убогом веб-интерфейсе уязвимости. Не обнаружили вы «уязвимость эскалации привилегий» — не должно там быть пользователей с какими-нибудь другими привилегиями, кроме полного доступа.
Сегментация, отсутствие либо строжайшая защита шлюзов во внешний мир (не шлюзов протоколов внутри системы, о которых пол статьи, а высокоуровневых: портала отчётов или шлюза удалённого доступа на границе системы) — единственные способы обеспечения безопасности таких систем. Если злоумышленник получил доступ к любому компоненту внутри таких систем — всё, дело сделано. Играть в безопасность внутри — поздно. Там каждый компонент имеет только одно предназначение — кое-как с тормозами худо-бедно выполнить свою функцию. Все остальные украшения, которые на них навесят маркетологи — «контроль доступа» и т.д. — всё заведомо фальшивка, никто этим в этой сфере реально не занимается.
О да! Создайте отдел pentest-еров в вашей компании, закупите оборудование десятка брендов, проведите изыскания. Да там всё через шаг не по стандарту и криво работает! Дело производителя — обеспечить совместимость внутри системы и возможность доступа извне (например, показанный на первой диаграмме Historian, пишет в MS SQL).
Собственно, для чего и написана статья — создать новую нишу для устройства, которое не решает никаких реальных проблем.
Нет, изолируйте все внутренние шлюзы протоколов, отключите облачную интеграцию, минимизируйте потоки данных за пределы сегмента, вот их уже шифруйте, проверяйте и т.д. Например, односторонняя MS SQL-репликация из базы Historian стандартными либо своими стредствами, но ни в коем случае не «фирменной утилитой» от производителя систем автоматизации.
Зависит от ситуации, но, как правило, никто не даст вам обновлять прошивку на рабочей системе без полного останова всего и полной пуско-наладки с нуля. И, по большому счёту, это нормально. Ненормально такие системы выставлять в какой-либо общий доступ и позволять им «облачную интергацию», а вот изолировать их внутри сегмента и тщательнейшим образом организовать сегментацию и контроль всех потоков через границу сегмента — вот об этом могла бы быть не-маркетинговая статья, но «так ты корову не продашь».
Не было, нет и не будет никакой безопасности в системах автоматизации. Они не для того. Не имеет значения, правильно ли там проверяется пароль. Наплевать, есть ли в убогом веб-интерфейсе уязвимости. Не обнаружили вы «уязвимость эскалации привилегий» — не должно там быть пользователей с какими-нибудь другими привилегиями, кроме полного доступа.
Сегментация, отсутствие либо строжайшая защита шлюзов во внешний мир (не шлюзов протоколов внутри системы, о которых пол статьи, а высокоуровневых: портала отчётов или шлюза удалённого доступа на границе системы) — единственные способы обеспечения безопасности таких систем. Если злоумышленник получил доступ к любому компоненту внутри таких систем — всё, дело сделано. Играть в безопасность внутри — поздно. Там каждый компонент имеет только одно предназначение — кое-как с тормозами худо-бедно выполнить свою функцию. Все остальные украшения, которые на них навесят маркетологи — «контроль доступа» и т.д. — всё заведомо фальшивка, никто этим в этой сфере реально не занимается.
1. Устройства разных производителей по-разному обрабатывают недействительные пакеты. Некоторые из них не обладают адекватными возможностями фильтрации пакетов или ведут себя непредсказуемо. В связи с этим при выборе продукта следует в обязательном порядке учитывать эти функциональные аспекты.
О да! Создайте отдел pentest-еров в вашей компании, закупите оборудование десятка брендов, проведите изыскания. Да там всё через шаг не по стандарту и криво работает! Дело производителя — обеспечить совместимость внутри системы и возможность доступа извне (например, показанный на первой диаграмме Historian, пишет в MS SQL).
2. Используйте специализированный брандмауэр для промышленных протоколов — он обнаруживает пакеты, которые не соответствуют стандартам протокола, и обеспечивает административный доступ к шлюзам протокола только с авторизованных конечных точек. Наличие ICS-брандмауэра помогает обеспечить целостность трафика. В линейке продуктов Trend Micro есть соответствующее решение — TXOne Networks, обеспечивающее защиту в режиме реального времени для сетей OT и критически важных устройств.
Собственно, для чего и написана статья — создать новую нишу для устройства, которое не решает никаких реальных проблем.
3. Выделите достаточное количество времени на настройку и защиту шлюза, особенно это важно для станций обработки данных — слишком велика цена ошибки при настройке таблицы отображения ввода/вывода, которая может предоставить злоумышленнику платформу для проведения незаметных атак. Отключите ненужные сервисы и включите шифрование везде, где оно поддерживается, например, в облачной интеграции MQTT.
Нет, изолируйте все внутренние шлюзы протоколов, отключите облачную интеграцию, минимизируйте потоки данных за пределы сегмента, вот их уже шифруйте, проверяйте и т.д. Например, односторонняя MS SQL-репликация из базы Historian стандартными либо своими стредствами, но ни в коем случае не «фирменной утилитой» от производителя систем автоматизации.
4. Рассматривайте шлюзы протоколов как критический актив OT и применяйте к ним соответствующие процедуры управления безопасности, включая аудит настроек и своевременную установку обновлений прошивок.
Зависит от ситуации, но, как правило, никто не даст вам обновлять прошивку на рабочей системе без полного останова всего и полной пуско-наладки с нуля. И, по большому счёту, это нормально. Ненормально такие системы выставлять в какой-либо общий доступ и позволять им «облачную интергацию», а вот изолировать их внутри сегмента и тщательнейшим образом организовать сегментацию и контроль всех потоков через границу сегмента — вот об этом могла бы быть не-маркетинговая статья, но «так ты корову не продашь».
Sign up to leave a comment.
Трудности перевода: уязвимости шлюзов промышленных протоколов