Вообще говоря, в своём комментарии я всё это дело расписал. И тем не менее, уже сейчас люди имеют кучу проблем из-за того, что некоторые сайты перестали работать с почтой не в зоне .ru.
Как тогда определить принадлежность сервиса? Приходит ко мне на форум новый пользователь регистрироваться, а регистрация - с подтверждением по электронной почте (это, кстати, не авторизация, а аутентификация, если быть точным в формулировках). Вводит свою почту. Как мне узнать, что владелец домена - гражданин РФ или российское юрлицо? По имени домена - нет. У меня, к примеру, рабочий адрес в зоне .com, а владелец - российское юрлицо. Брать из whois информацию о владельце? Так там для физлиц - "Private Person", а у юрлиц - называние, не всегда однозначно определяющее владельца. У того же Яндекса, например, в поле org стоит YANDEX LLC, а в базе егрюл такого названия нет. В то же время - в том же егрюл целая куча юриц со словом Яндекс в названии (даже Яндекс Антон Антонович есть), как определить, кому из них домен принадлежит? И вообще - принадлежит ли кому-либо из них или какому-то YANDEX LLC из Нидерландов?
А что, если пользователь - не гражданин РФ, но находится на территории РФ? Приехал, например, человек из Казахстана в командировку, и срочно ему потребовалось зарегистрироваться на моём форуме. А почта у него - только рабочая в зоне .kz. И других вариантов регистрации у меня нет. Ему что, временный ящик на Яндексе создавать?
Ну, тогда продукт под названием KICS и его разработчиков Вы отнесли к числу неадекватных ИБшников :)
Предлагалась следующая схема:
1. Пассивная часть. Берётся все сетевое оборудование, на каждом из свитчей зеркалится весь трафик на один из портов, из которого идёт на внешний сервер для анализа. Оставим за скобками то, что нередко протоколы проприетарны и внутренности их производитель вот так просто разглашать не будет. Ограничились для пилотного проекта объектом с заведомо поддерживаемым оборудованием — системой от Siemens (опять же, если посмотреть в список поддерживаемого оборудования и ПО — там от Siemens только WinCC OA, который не совсем WinCC и не совсем Siemens, ну да ладно). То, что изменения в конфигурации мы не будем делать и не разрешим делать без согласования с разработчиком системы — пришлось объяснять. Хотя на мой взгляд такие требования — из области «само собой разумеется». Опять же, оставим за скобками то, что установленное оборудование такого зеркалирования делать не умеет. Ну вот не характерно это для промышленного сетевого оборудования. Вариант поменять всё на cisco… блин, где cisco, а где profinet… кого я там, Вы говорите, недопонял? Вариант внедрить туда ещё устройства для выдёргивания трафика из каждого физического линка… ну как бы это сказать… интересно, людям знакомо понятие «надёжность»?
Далее, опять же касаясь пассивной части. Анализ этого самого трафика на «легитимность». Уже хорошо, что нам не предложили какой-либо «эвристический анализатор» (либо ещё какой «думатель»). То есть — правила прописываются вручную. То есть — человек, прописывающий эти правила, по сути должен повторить проект АСУТП в виде этих правил. Учитывая количество устройств, вариантов блокировок на них, алгоритмов управления — количество правил на объекте получилось бы где-то к сотне тысяч. ИБшники готовы к такому объёму? Уверены? А отследить все косяки в таком объёме они в состоянии? Точно? А работу правил, которые нельзя опробовать, они готовы гарантировать?
2. Активная часть. От которой отказались сразу и безоговорочно. Предлагалось на основе того, что наанализоровала вышеописанная пассивная часть, блокировать трафик, признаваемый нелегитимным. Не знаю, каким образом. Дополнительные устройства? Отрубание портов, откуда идёт «атака» на существующих свитчах? Бред, вы говорите? Что я здесь «неправильно понял»? Открытым текстом — блокирование нелегитимного трафика.
3. Также активная часть. Тут уже, в отличие от п.1, нужны не зеркальные порты свитчей, а доступ в сеть со стороны внешнего сервера. Сервер периодически залезает в контроллеры и сверяет версии и контрольные суммы загруженных модулей. Где гарантия, что этот самый сервер не будет скомпрометирован и использован для атаки на эти самые контроллеры? Ведь его предлагается оставлять в сети постоянно, в отличие от инженерной станции/программатора, подключаемых в случае необходимости выполнения каких-либо работ. И, в отличие от операторского интерфейса (также постоянно подключенного), этот сервер уже имеет в себе необходимые для доступа к «потрохам» контроллера компоненты. Ну и нафиг нам эта пороховая бочка? «Предложения и меры обычно лежат в совершенно в других плоскостях и с другими обоснованиями.». В каких, интересно? Или «у нас есть такие приборы, но мы вам про них не расскажем»?
17 лет в АСУТП, количество сданных проектов после 10-го считать перестал. Чем ещё меряться будем? :)
По сути:
— Дыры в контроллерах. Есть и будут. Постепенно фиксятся производителями, но специфика такова, что быстро это не сделать — в продакшн выводить можно только то, что уже хорошо откатано на стендах. Технологическая установка — не база данных, из бэкапа не восстановишь. Проблема всех «привносимых извне» систем закрывания этих дыр в том, что они не решают имеющихся проблем, и при этом в лучшем случае — просто не ухудшают характеристик системы. И зачем такая радость?
— Несовершенство протоколов. Да, несовершенны. Разработаете совершенный — вам памятник при жизни поставят. Но когда ИБшники мне принесли схему с 19 (!) файрволами между DCS и ПАЗ — были посланы искать SFP-модуль для Profibus DP :). Ну вот использовали они его в схеме. Что такая схема могла улучшить?
— Нормальные пароли. «Нормальные» — это 16 знаков со спецсимволами, переменным регистром и прочими радостями жизни? Ну так это само по себе офигенная дыра в безопасности: никто таких паролей не помнит (особенно, когда их минимум 2 на устройство, количество устройств в системе — не меньше десятка, количество систем в обслуживании — 15-20 штук, и требование смены всех этих паролей раз в 3 месяца). Отсюда — файлы с паролями на компьютерах. В лучшем случае. В более плохом — пароли на стикерах, приклеенных к мониторам. В худшем — единая на все объекты интегратора схема придумывания паролей, зная которую можно подобрать пароль к любому устройству любого объекта. Кстати, наиболее часто используемая схема.
— Обновления хотя бы там, где возможны. Только после официального подтверждения производителя оборудования и ПО, что это обновление опробовано и ничего в системе не ломает.
— «Ваш air gap в половине случаев на самом деле никакой не air gap, и в принципе не работает.» На любую защиту от дурака отдел кадров найдёт более талантливого идиота. Если air gap не работает — такова же будет судьба 19 файрволов.
Какая ирония? Нет никакой иронии. Если человек говорит "Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы." — это либо стёб, либо элементарное непонимание того, что есть АСУТП и из чего состоит. Я совсем не против линуксов, более того, у меня на домашней машине федора (на ней сейчас и печатаю :) ). Но вот в АСУТП — куда???
Не, реально существуют линуксовые управляющие системы (я, кстати, с такими работаю, срециализированные RT), но это — далеко не лучший вариант, на мой взгляд. В нормальных контроллерах… я вот вообще не знаю, есть там какая-то ОС между целевым софтом и железом, или там монолитный продукт.
Тогда что? Операторский интерфейс? Допустим. Решений немного, но они существуют. Но. Это — отдельные scada-системы. Интегрировать в общий проект системы управления — не получится. То есть — каждый канальчик прописывать ручками. Живой пример (один из знакомых мне объектов): объект из 320 двигателей, 170 клапанов, 1300 сигналов в поле. На каждом двигателе — порядка 8 сигналов состояния, на клапанах — 5-6. Плюс у каждого двигателя и клапана — 15-20 блокировочных сигналов. Можно перемножить и посчитать. Молодой падаван будет это вручную делать? Сколько времени у него на это уйдёт? Сколько ошибок останутся невыловленными? И это… операторский интерфейс — ещё далеко не вся система. Я бы оценил примерно как 2-3%, вряд ли больше. Так что «всё снести и переделать» — далеко не проще.
Да, есть такое дело, MS вовремя подсуетилась со своими продуктами и теперь они везде.
Кстати, а где в WinCC вы видели "высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей"? Не то, чтобы их там не было совсем… но чтобы до них добраться, надо делать систему несколько специфичного назначения и со специфичным комплектом программного обеспечения, которое уже никак не назовёшь типовым.
И собственно, обещанный старый армейский анекдот.
Командир (К) части спрашивает свежеприбывшего из училища молодого лейтенанта (Л):
К: Товарищ лейтенант, вы взводом командовать можете?
Л: Так точно!
К: А ротой, если потребуется?
Л: Так точно!
К: Полком?
Л: Так точно!
К: Кораблём, самолётом, подводной лодкой?
Л: Так точно!
К: Продемонстрируйте!
Л: Подводная лодка! Р-равняйсь! Смирно!
(это я к чему, собственно: не всегда один подход годится везде)
Итак, очередная статья, где специалисты по ИБ знают точно, что должны делать мы, АСУТПшники. А мы, глупенькие, сопротивляемся прогрессу. Господа ИБшники, а вы ничего не забыли? К примеру, ознакомиться с тем, что собираетесь защищать — не надо? Или вы как в старом армейском анекдоте — «Подводная лодка, р-равняйсь, смирно!» (если кто не знает, могу ниже в каментах рассказать).
Итак, минимальный ликбез для ИБшника на тему того, что такое АСУТП.
Начнём с двух последних букв. ТП — это «технологический процесс». Вот первое и главное отличие АСУТП от разных «обычных» информационных систем. Если в привычных вам системах во главе угла — информация, которую надо защищать от разных напастей (потери, повреждения, несанкционированного доступа), то в АСУТП главное — технологический процесс. Информация — лишь отображение технологического процесса в виде, понятном системе управления. Что из этого следует? А то, что и защищать надо именно технологический процесс. Когда вы предлагаете анализировать информацию между контроллером и полевыми устройствами и, при наличии обоснованных подозрений, блокировать её (конкретно у вас такого не читал, но обычно все ИБшники это предлагают) — вы уверены, что ваш анализ точен и решение правильно? Вас не смущает, что именно вы можете перевести объект в неуправляемый режим с гораздо большей вероятностью, чем какой-нибудь петя или стакснет? А потому, когда суровые АСУТПшники на местах встречают вас не слишком радушно — скажите спасибо, что пинками за территорию не выгоняют.
Чтобы общение с АСУТПшниками не было столь сложным процессом, попробуйте для начала хотя бы минимально понять, что такое АСУТП, чем отличается от обычных информационных систем. Не пытайтесь, чуть сунувшись в тему, учить людей, что и как надо делать. Лучше сами поучитесь, полезно.
Хм… молодой человек, а не появлялось ли у Вас желание для начала хотя бы в минимальном объёме ознакомиться с тем, что такое АСУТП, дабы в дальнейшем… как бы это мягче сказать… более осторожно относиться к изрекаемым словам?
Первое, что сделала бы супер-квалифицированная команда хакеров, блестяще подготовившая операцию по нескольким направлениям (вплоть до перегрузки колл-центра) — подчистила бы логи (или отключила бы их нафиг, перенаправила куда-нибудь в /dev/null, оставила скрипт очистки… да мало ли что можно сделать, имея доступ, достаточный для перепрошивки аппаратуры). Здесь это сделано не было, так что «команда хакеров» оказалась одновременно супер-профи и банальными ламерами. Странно, да?
Второе. «Мышка гуляла по рабочему столу и клацала по кнопкам» (лень выдёргивать точную цитату — сути это не меняет). При обычном подключении по rdp локальная сессия отключается и оператор не видит «гуляния мышки». Через «удалённый помощник»? Может быть. Кто создал приглашение? Понятно: хакеры сами для себя. То есть доступ к АРМ таки был практически полный. Ну или какой-нибудь vnc или radmin поставлен. Но зачем, имея такой доступ, что-то там по экрану елозить? Не проще ли добраться до структуры данных скады (наверняка инженерная станция тоже либо постоянно в сети, либо появлялась там во время «подготовки атаки», и тоже взломана) и закидывать данные непосредственно куда надо, чтобы местные операторы вообще нифига не понимали. Или скопировать скаду на удалённый компьютер и рулить извне — тогда тоже никакой курсор никуда не победит.
Это так, навскидку по мелочи, если детально в этот «шедевр» не вчитываться. Детский лепет.
Вообще говоря, в своём комментарии я всё это дело расписал. И тем не менее, уже сейчас люди имеют кучу проблем из-за того, что некоторые сайты перестали работать с почтой не в зоне .ru.
Как тогда определить принадлежность сервиса? Приходит ко мне на форум новый пользователь регистрироваться, а регистрация - с подтверждением по электронной почте (это, кстати, не авторизация, а аутентификация, если быть точным в формулировках). Вводит свою почту. Как мне узнать, что владелец домена - гражданин РФ или российское юрлицо? По имени домена - нет. У меня, к примеру, рабочий адрес в зоне .com, а владелец - российское юрлицо. Брать из whois информацию о владельце? Так там для физлиц - "Private Person", а у юрлиц - называние, не всегда однозначно определяющее владельца. У того же Яндекса, например, в поле org стоит YANDEX LLC, а в базе егрюл такого названия нет. В то же время - в том же егрюл целая куча юриц со словом Яндекс в названии (даже Яндекс Антон Антонович есть), как определить, кому из них домен принадлежит? И вообще - принадлежит ли кому-либо из них или какому-то YANDEX LLC из Нидерландов?
А что, если пользователь - не гражданин РФ, но находится на территории РФ? Приехал, например, человек из Казахстана в командировку, и срочно ему потребовалось зарегистрироваться на моём форуме. А почта у него - только рабочая в зоне .kz. И других вариантов регистрации у меня нет. Ему что, временный ящик на Яндексе создавать?
Предлагалась следующая схема:
1. Пассивная часть. Берётся все сетевое оборудование, на каждом из свитчей зеркалится весь трафик на один из портов, из которого идёт на внешний сервер для анализа. Оставим за скобками то, что нередко протоколы проприетарны и внутренности их производитель вот так просто разглашать не будет. Ограничились для пилотного проекта объектом с заведомо поддерживаемым оборудованием — системой от Siemens (опять же, если посмотреть в список поддерживаемого оборудования и ПО — там от Siemens только WinCC OA, который не совсем WinCC и не совсем Siemens, ну да ладно). То, что изменения в конфигурации мы не будем делать и не разрешим делать без согласования с разработчиком системы — пришлось объяснять. Хотя на мой взгляд такие требования — из области «само собой разумеется». Опять же, оставим за скобками то, что установленное оборудование такого зеркалирования делать не умеет. Ну вот не характерно это для промышленного сетевого оборудования. Вариант поменять всё на cisco… блин, где cisco, а где profinet… кого я там, Вы говорите, недопонял? Вариант внедрить туда ещё устройства для выдёргивания трафика из каждого физического линка… ну как бы это сказать… интересно, людям знакомо понятие «надёжность»?
Далее, опять же касаясь пассивной части. Анализ этого самого трафика на «легитимность». Уже хорошо, что нам не предложили какой-либо «эвристический анализатор» (либо ещё какой «думатель»). То есть — правила прописываются вручную. То есть — человек, прописывающий эти правила, по сути должен повторить проект АСУТП в виде этих правил. Учитывая количество устройств, вариантов блокировок на них, алгоритмов управления — количество правил на объекте получилось бы где-то к сотне тысяч. ИБшники готовы к такому объёму? Уверены? А отследить все косяки в таком объёме они в состоянии? Точно? А работу правил, которые нельзя опробовать, они готовы гарантировать?
2. Активная часть. От которой отказались сразу и безоговорочно. Предлагалось на основе того, что наанализоровала вышеописанная пассивная часть, блокировать трафик, признаваемый нелегитимным. Не знаю, каким образом. Дополнительные устройства? Отрубание портов, откуда идёт «атака» на существующих свитчах? Бред, вы говорите? Что я здесь «неправильно понял»? Открытым текстом — блокирование нелегитимного трафика.
3. Также активная часть. Тут уже, в отличие от п.1, нужны не зеркальные порты свитчей, а доступ в сеть со стороны внешнего сервера. Сервер периодически залезает в контроллеры и сверяет версии и контрольные суммы загруженных модулей. Где гарантия, что этот самый сервер не будет скомпрометирован и использован для атаки на эти самые контроллеры? Ведь его предлагается оставлять в сети постоянно, в отличие от инженерной станции/программатора, подключаемых в случае необходимости выполнения каких-либо работ. И, в отличие от операторского интерфейса (также постоянно подключенного), этот сервер уже имеет в себе необходимые для доступа к «потрохам» контроллера компоненты. Ну и нафиг нам эта пороховая бочка?
«Предложения и меры обычно лежат в совершенно в других плоскостях и с другими обоснованиями.». В каких, интересно? Или «у нас есть такие приборы, но мы вам про них не расскажем»?
По сути:
— Дыры в контроллерах. Есть и будут. Постепенно фиксятся производителями, но специфика такова, что быстро это не сделать — в продакшн выводить можно только то, что уже хорошо откатано на стендах. Технологическая установка — не база данных, из бэкапа не восстановишь. Проблема всех «привносимых извне» систем закрывания этих дыр в том, что они не решают имеющихся проблем, и при этом в лучшем случае — просто не ухудшают характеристик системы. И зачем такая радость?
— Несовершенство протоколов. Да, несовершенны. Разработаете совершенный — вам памятник при жизни поставят. Но когда ИБшники мне принесли схему с 19 (!) файрволами между DCS и ПАЗ — были посланы искать SFP-модуль для Profibus DP :). Ну вот использовали они его в схеме. Что такая схема могла улучшить?
— Нормальные пароли. «Нормальные» — это 16 знаков со спецсимволами, переменным регистром и прочими радостями жизни? Ну так это само по себе офигенная дыра в безопасности: никто таких паролей не помнит (особенно, когда их минимум 2 на устройство, количество устройств в системе — не меньше десятка, количество систем в обслуживании — 15-20 штук, и требование смены всех этих паролей раз в 3 месяца). Отсюда — файлы с паролями на компьютерах. В лучшем случае. В более плохом — пароли на стикерах, приклеенных к мониторам. В худшем — единая на все объекты интегратора схема придумывания паролей, зная которую можно подобрать пароль к любому устройству любого объекта. Кстати, наиболее часто используемая схема.
— Обновления хотя бы там, где возможны. Только после официального подтверждения производителя оборудования и ПО, что это обновление опробовано и ничего в системе не ломает.
— «Ваш air gap в половине случаев на самом деле никакой не air gap, и в принципе не работает.» На любую защиту от дурака отдел кадров найдёт более талантливого идиота. Если air gap не работает — такова же будет судьба 19 файрволов.
Не, реально существуют линуксовые управляющие системы (я, кстати, с такими работаю, срециализированные RT), но это — далеко не лучший вариант, на мой взгляд. В нормальных контроллерах… я вот вообще не знаю, есть там какая-то ОС между целевым софтом и железом, или там монолитный продукт.
Тогда что? Операторский интерфейс? Допустим. Решений немного, но они существуют. Но. Это — отдельные scada-системы. Интегрировать в общий проект системы управления — не получится. То есть — каждый канальчик прописывать ручками. Живой пример (один из знакомых мне объектов): объект из 320 двигателей, 170 клапанов, 1300 сигналов в поле. На каждом двигателе — порядка 8 сигналов состояния, на клапанах — 5-6. Плюс у каждого двигателя и клапана — 15-20 блокировочных сигналов. Можно перемножить и посчитать. Молодой падаван будет это вручную делать? Сколько времени у него на это уйдёт? Сколько ошибок останутся невыловленными? И это… операторский интерфейс — ещё далеко не вся система. Я бы оценил примерно как 2-3%, вряд ли больше. Так что «всё снести и переделать» — далеко не проще.
Да, есть такое дело, MS вовремя подсуетилась со своими продуктами и теперь они везде.
Кстати, а где в WinCC вы видели "высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей"? Не то, чтобы их там не было совсем… но чтобы до них добраться, надо делать систему несколько специфичного назначения и со специфичным комплектом программного обеспечения, которое уже никак не назовёшь типовым.
Командир (К) части спрашивает свежеприбывшего из училища молодого лейтенанта (Л):
К: Товарищ лейтенант, вы взводом командовать можете?
Л: Так точно!
К: А ротой, если потребуется?
Л: Так точно!
К: Полком?
Л: Так точно!
К: Кораблём, самолётом, подводной лодкой?
Л: Так точно!
К: Продемонстрируйте!
Л: Подводная лодка! Р-равняйсь! Смирно!
(это я к чему, собственно: не всегда один подход годится везде)
Итак, минимальный ликбез для ИБшника на тему того, что такое АСУТП.
Начнём с двух последних букв. ТП — это «технологический процесс». Вот первое и главное отличие АСУТП от разных «обычных» информационных систем. Если в привычных вам системах во главе угла — информация, которую надо защищать от разных напастей (потери, повреждения, несанкционированного доступа), то в АСУТП главное — технологический процесс. Информация — лишь отображение технологического процесса в виде, понятном системе управления. Что из этого следует? А то, что и защищать надо именно технологический процесс. Когда вы предлагаете анализировать информацию между контроллером и полевыми устройствами и, при наличии обоснованных подозрений, блокировать её (конкретно у вас такого не читал, но обычно все ИБшники это предлагают) — вы уверены, что ваш анализ точен и решение правильно? Вас не смущает, что именно вы можете перевести объект в неуправляемый режим с гораздо большей вероятностью, чем какой-нибудь петя или стакснет? А потому, когда суровые АСУТПшники на местах встречают вас не слишком радушно — скажите спасибо, что пинками за территорию не выгоняют.
Второе. «Мышка гуляла по рабочему столу и клацала по кнопкам» (лень выдёргивать точную цитату — сути это не меняет). При обычном подключении по rdp локальная сессия отключается и оператор не видит «гуляния мышки». Через «удалённый помощник»? Может быть. Кто создал приглашение? Понятно: хакеры сами для себя. То есть доступ к АРМ таки был практически полный. Ну или какой-нибудь vnc или radmin поставлен. Но зачем, имея такой доступ, что-то там по экрану елозить? Не проще ли добраться до структуры данных скады (наверняка инженерная станция тоже либо постоянно в сети, либо появлялась там во время «подготовки атаки», и тоже взломана) и закидывать данные непосредственно куда надо, чтобы местные операторы вообще нифига не понимали. Или скопировать скаду на удалённый компьютер и рулить извне — тогда тоже никакой курсор никуда не победит.
Это так, навскидку по мелочи, если детально в этот «шедевр» не вчитываться. Детский лепет.