Проконсультируйте по вопросу безопасности

[VADR]

Кто-то настолько наивен, что по модбасу вообще, а не то что через инет, управляет техпроцессом или СПАЗ на ОПО?

Тут имеется в виду конкретно modbus tcp или любой modbus? Управления через modbus - сколько угодно, в том числе и на опасных объектах. Те же частотники, подключаемые по modbus rtu - совершенно обычное явление. В защитах - да, нечего делать, но (к примеру) обмен данными между собственно АСУТП и СПАЗ через modbus - тоже обычное явление.

Как обычно, предлагаю сначала определиться с терминами.
По моим представлениям СПАЗ наряду с САУ и ЧМИ (или даже SCADA) является составной частью АСУТП.
Поэтому ИМХО правильнее было бы говорить об использовани modbus внутри АСУТП на ОПО.

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

[dtv]

Свежая статья на предмет безопасности АСУ ТП:
http://dsec.ru/ipm-research-center/rese ... m_of_apcs/
Там же есть и сам текст исследования.

[Ivan69]

>Может есть исследования на эту тему? Я искал и не нашёл. Надеюсь моя идея ясна
Мне не попадалось. По теме ИБ в АСУТП я видел только статьи Positive Technologies на хабре, про которых все здесь так негативно отзываются. Но у них никакой конкретики, только статистика "дцать процентов АСУТП уязвимы".

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

Повторюсь, для начала возьмите хотя бы один, но конкретный проект (вот прям перед вами открыта IDE, а там код на STL или LD'шки), изучите (что уже фора перед мнимым хакером, у котрого не должно быть исходников) и взломайте его подручными средставми :) Если (когда?)) не получится - проанализируйте почему. По-моему, для диплома вполне достаточно, особенно, если получится.

>И опять же вопрос: зачем?
Я стараюсь решать задачу максимально своими силами - автоматика должна быть автоматизированной. А то там АСУТП, тут АСУТП, а обмен телеграммами :) Сами же говорите, человеческий фактор причина 99,9% аварий. Но в данном вопросе не столько аварии, сколько именно нужда управлять "отсюда" и именно независимо от "тамошнего" человеческого фактора. То есть завод "наш", а "там" на заводе "они", которые платят за пользование заводом. Такая интересная схема. Не я придумал :) Не знаю, чем закончится дело, и закончится ли в ближайшие годы, я над тем проектом уже не работаю)
upd: я про скаду в инет говорю, разумеется, плк далеко и глубоко спрятаны.

Все верно именно об этом и говорил. Спасибо.

[Ivan69]

Вопрос в вероятности - найти в интернете плк с открытым 502 портом достаточно легко.

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

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

Как раз об этом я говорил - не любая уязвимость является угрозой. Потенциальную опасность и хотел оценить таким способом.

[Ivan69]

Свежая статья на предмет безопасности АСУ ТП:
http://dsec.ru/ipm-research-center/rese ... m_of_apcs/
Там же есть и сам текст исследования.

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

Всем спасибо - нужную информацию я получил.

[Jackson]

Свежая статья на предмет безопасности АСУ ТП:
http://dsec.ru/ipm-research-center/rese ... m_of_apcs/
Там же есть и сам текст исследования.

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

Всем спасибо - нужную информацию я получил.

Это же логично. :) Если не залезть не отрывая 5 точки, а залезть надо - значит 5 точку придётся оторвать и дойти пешком. Это не экзотика а здравый смысл.

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

Поэтому, я об этом говорил в самом начале: любая техническая задача должна решаться одновременно по двум направлениям: по технике и организационно. Без организационной составляющей даже ТТ к системе толком предъявить не получится или они будут не полны. Как в известном анекдоте про "круче чем google". Это и есть то самое "зачем", без которого вся работа бессмысленна.

[VADR]

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

[Jackson]

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

Это будет ад.

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

[Ryzhij]

А что будет, если вдруг эта хрень откажет?

А что будет, если я уроню и разобью свой мобильник? Я уже никогда не смогу воспользоваться прежним абонентским номером? ;)

[VADR]

А что будет, если вдруг эта хрень откажет?

А что будет, если я уроню и разобью свой мобильник? Я уже никогда не смогу воспользоваться прежним абонентским номером? ;)

Без мобильника можно некоторое время прожить, а что будет, если на контроллере произойдёт сбой как раз в системе шифровки/дешифровки? Например, из-за перевода часов, которую система примет за атаку? А как насчёт совместимости устройств разных производителей? Если пока не касаться будущих промышленных протоколов, а вспомнить о существующих сегодня сетевых - одни и те же стандартные очень хорошо описанные протоколы Cisco, HP и Moxa реализуют совершенно по-разному (для примера - хотя бы rstp или 802.1q), в итоге надо постоянно иметь в виду эти различия.

[Romcheg]

Как уже верно заметили - 99.9% техногенных катастроф произошли по вине человеческого фактора, это не просто цифры - это реальная статистика. Когда обсуждается безопасность системы - в первую очередь ставится ее защищенность от взлома... Простите, кем??? Человеком!
Именно, сейчас тут обсуждается те десятые доли процента от "неуловимого Джо". И как всегда - один единственный грамотный вопрос, который ставит в тупик ВСЕХ "УМНИКОВ", его задающих: А ЗАЧЕМ???? Аргументируйте!
Защищенной делает систему не ее особенность, а в первую очередь - административный фактор. Если на предприятии бардак - то и система будет проходным двором. По роду деятельности я работаю на охраняемых объектах, но когда на проходной охрана е...т мозг за ноутбук, а в кармане у меня лежит мобила в 2-3 раза превышающая возможности оного, или когда у меня вынимают все, что содержит камеру и прочие причиндалы из-за возможностей устройства, а по площадкам гуляет местный персонал со своими личными флешками, меня бесят приверженцы аппарата оказания видимости действий, заботящиеся якобы о национальной безопасности ради своего кармана... Как человек, который уже 15 лет работает в автоматизации - знаю, что уронить, или сделать такое можно на 100% объектах, вопрос только: цели, затрат, и возможностей, которые окупят желания. В остальном, уже тут говорили - пустобрехня, и она будет пустой и брехней, пока те, кому она действительно нужна, не осознают, что надо в этом плане работать, а не отрабатывать деньги, которые туда выделяют. Пока им выгоднее их осваивать и иногда вкидывать что-то на вентилятор, чтобы демос не скучал. :) Простите, наболело...

[Ryzhij]

Без мобильника можно некоторое время прожить, а что будет, если на контроллере произойдёт сбой как раз в системе шифровки/дешифровки? Например, из-за перевода часов, которую система примет за атаку? А как насчёт совместимости устройств разных производителей?

И часто у Вас мобильник из-за перевода времени глючит? ;)

Что ж, буду говорить прямо и без намёков.

1. Существует масса практически применимых и испытанных способов переноса ключа шифрования с одного прибора на другой. Мобильники с их SIM-ками, кабельные и спутниковые ресиверы TV с их CAM-ами, донглы всевозможные - это только малая часть примеров.

2. Процедура (протокол) аутентификации мало имеет общего с транспортным протоколом обмена - они находятся на разных уровнях модели информационного обмена.

[VADR]

1. У мобильников вообще говоря несколько другая функция, и как следствие - другой режим работы: установление соединения, сравнительно недолгая сессия, разрыв соединения.
2. Мобильник у меня от перевода времени вроде как не глючил, а вот в движении при перехода от вышки с поддержкой 3G к вышке без 3G глючит нипадеццки.
3. Перенос ключа шифрования с одного устройства на другой - это что? Перенос сертификата на другое устройство, которое надо установить на замену вышедшему из строя? Если такое возможно, то вся эта затея с защитой канала связи превращается в баловство: никто не помешает перенести этот сертификат на "поддельное устройство", которое тут же опознается как истинное и будет принято системой. Да и mitm внедрить будет несложно. Сертификат должен содержать два ключа - открытый и закрытый (секретный). Открытый ключ может быть стандартными путями извлечён из устройства, передан устройству на другом конце, и предназначается для шифрования траффика. Закрытый ключ - для дешифровки траффика устройством, хранится в устройстве и не извлекается из него никак. В идеале - самим устройством и генерируется, а также периодически меняется.
4. Я где-то объединил аутентификацию с транспортным протоколом обмена? Я об аутентификации (и об авторизации, кстати, тоже) вообще не говорил. Я говорил о шифровании траффика и подразумевал, что при этом должна быть инкапсуляция транспортного (а возможно и вообще - канального) протокола в этот шифрованный поток.

[Ryzhij]

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

[Jackson]

Как уже верно заметили - 99.9% техногенных катастроф произошли по вине человеческого фактора, это не просто цифры - это реальная статистика. Когда обсуждается безопасность системы - в первую очередь ставится ее защищенность от взлома... Простите, кем??? Человеком!

О том как раз и речь, что этот человек - ни разу не хакер и даже не диверсант-вредитель.

Речь в топике всё-таки про хакинг. А уровень бардака на объекте и влияние его на техногенность, давайте всё же оставим, по крайней мере для другого топика.

[Exactamente]

>Когда обсуждается безопасность системы - в первую очередь ставится ее защищенность от взлома...

Отнюдь. TEB прав, защищённость от взлома и защищённость от дурака - вопросы отдельные, хотя и смежные. Любой разговор о безопасности нужно начинать со слов "комплексный подход".