Комментарии 28
Давно я так не смеялся. А теперь давайте поговорим про: беспроводные датчики для системы ПАЗ (и сколько они там проработают с опросом минимум 1 раз в секунду), работу беспроводных датчиков в условиях окружения их металлоконструкциями, и про обеспечение бесперебойной передачи данных в этих условиях. Применительно к НПЗ. Раз уж беспроводные датчики это такое благо.
Так вроде про ПАЗ тут автор и не пишет. Проводные решения ПАЗ реализованы на пром.предприятиях с применением проводов и контроллеров (В рамках достижений третьей промышленной революции). Индустрия 4.0 - это про следующий этап, не отменяющий этапы предущие: пусть ПАЗ останутся в проводном исполнении :)
В части беспроводки на том же НПЗ наблюдал ситуации, когда пожаром на одном из участков были повреждены проводные линии передачи данных, идущие от неповреждённой и работающей установки В итоге операторы не могли получить информацию с проводных датчиков до окончания ремонтных работ. Беспроводные датчики (да хоть Wireless HART, не говоря уже про упомянутые LoRa/NB-IoT) в этой ситуации были бы очень кстати.
Мда? "Анализ данных о вибрации, температуре", "Совместный контроль вибрации и температуры подшипниковых узлов" - намекает о контроле состояния подшипников, что для насосов перекачивающих лвж автоматически означает подключение в ПАЗ.
Про повреждение транзитных кабелей - это кто-то накосячил, знатно накосячил: "Согласно ПУЭ п.7.4.37 «Через пожароопасные зоны любого класса, а также на расстояниях менее 1 м по горизонтали и вертикали от пожароопасной зоны запрещается прокладывать не относящиеся к данному технологическому процессу (производству) транзитные электропроводки и кабельные линии всех напряжений»."
Несколько раз перечитал статью и не нашёл в ней юмора. Не туда смотрю? Зачем сравнивать ПАЗ и беспроводные системы мониторинга — непонятно. Каждая система полезна по-своему и приносит пользу. Одно другому не мешает, а дополняет.
"Благо" и "панацея" не одно и то же. Хотя по рекламным статьям это не всегда заметно.
Меня LoRaWN много лет кормит и поит, что не мешает мне регулярно кому-нибудь доказывать, что под его задачи не подойдет ни LoRaWAN, ни что-нибудь еще беспроводное. Зачастую, кстати, не удается доказать, и результат бывает прискорбный. Одна радость, что без моего участия.
Совместный контроль вибрации и температуры подшипниковых узлов" - намекает о контроле состояния подшипников, что для насосов перекачивающих лвж автоматически означает подключение в ПАЗ.
Сам придумал интерпретацию, сам посмеялся, весело живёте!
Действительно, если на нефтеперерабатывающем заводе все контрольные точки охвачены проводными датчиками, заведёнными в АСУТП/ПАЗ, это впечатляет. На практике же значительная часть технологических процессов по-прежнему зависит от «обходчиков» — сотрудников, которые контролируют оборудование вручную.
Насосы, особенно те, что используются для вспомогательных процессов (охлаждение, дренаж, циркуляция), часто не оснащены постоянными датчиками. Их состояние проверяется обходчиками с помощью переносных приборов, таких как виброручки. Аналогичным образом контролируется температура на удалённых участках паропроводов.
У такого подхода есть очевидные недостатки: низкая частота измерений, субъективность результатов и высокие трудозатраты. В этой ситуации беспроводные промышленные датчики представляют собой эффективную альтернативу традиционным методам контроля.
Концепции «Индустрии 4.0» и промышленного интернета вещей (IIOT), зародившиеся за рубежом, давно перестали быть просто трендом. Они активно внедряются в Европе, США и Китае благодаря реальной практической пользе. В России эта тема развивается медленнее — возможно, из-за консерватизма или недостаточного понимания преимуществ технологий.
Радует, что появляются отечественные производители промышленных IOT-решений и процесс цифровизации в России начинает набирать обороты.
Если Вас впечатляет охват всех контрольных точек датчиками РСУ/ПАЗ возможно стоит осмотреть современный завод? Там везде так.
Датчики вибрации на современных установках устанавливаются на все насосы (проекты за 15 лет), а контроль температуры подшипников - на насосы с лвж. Это уже де-факто стандарт. Да и нормы требуют :"пункт 5.4.9 Федеральных норм и правил в области промышленной безопасности "Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств" (далее Правила) в установках с технологическими блоками I и II категорий взрывоопасности центробежные компрессоры и насосы с торцевыми уплотнениями должны оснащаться системами контроля за состоянием подшипников по температуре с сигнализацией, срабатывающей при достижении предельных значений, и блокировками, входящими в систему ПАЗ, которые должны срабатывать при превышении этих значений."
Так что я отлично представляю как и что работает на современных нпз. Если на тех установках где вы были куча местных приборов и нет дистанционных - ну чтоя могу сказать? Печально это, очень.
Да и может быть Вам уже стоит ознакомиться с нормативной документацией и не писать всякое-разное?
А X-COM то жару дает, я даже напрягся, что за 2 недели отпуска мир перевернулся. Ан нет, все нормально
В первых: X-COM – где Вы нашли в «Общих правилах взрывобезопасности…» пункт 5.4.9? В этом документе всю жизнь сквозная нумерация пунктов (от 1 до 371) без сяких подпунктов. То, о чем Вы говорите, это пункт 192. На фоне этого Ваша фраза «Да и может быть Вам уже стоит ознакомиться с нормативной документацией и не писать всякое-разное?» выглядит, мягко говоря, странно (признайтесь, ИИ за Вас комментарии пишет?)
Во вторых: Зачем смешивать кучу разных тем? Есть частные темы, правила работы оборудования I и II категории (чрезвычайно высокой и высокой опасности) и ПАЗ. Тут живем с проводными системами контроля и АСУТП. А есть отдельная огромная тема - Индустрии 4.0. Сейчас предприятия кучу сил в нее вкладывают и получают кучу профита, о чем и пишет автор
В правилах "по температуре". В статье "по вибрации". Вы все смешиваете в кучу.
иллюстрации впечатляют...
К сожалению, реализация концепции беспроводных датчиков на производственных площадках сталкивается с серьезными вызовами в области информационной безопасности. Специалисты по ИБ, как правило, настаивают на отключении всех протоколов беспроводной передачи данных, что существенно ограничивает возможности внедрения данной технологии.
Уважаемый коллега, благодарю вас за столь содержательное замечание!
Действительно, обеспечение информационной безопасности становится одним из ключевых факторов, влияющих на процесс внедрения инновационных решений, включая беспроводные датчики на производстве. Ваша точка зрения совершенно справедлива: часто специалисты по ИБ придерживаются консервативных взглядов, считая необходимым минимизировать любые потенциальные угрозы. Особенно ярко это проявляется там, где подразделение безопасности возглавляет специалист с опытом работы в силовых структурах, привыкший следовать принципу "все, что не разрешено, запрещено".
Однако, важно отметить, эффективное решение вопроса возможно при правильной постановке задачи и поддержке руководства организации. Если высшие руководители понимают ценность внедряемых решений и видят реальные выгоды, такие как экономия ресурсов и повышение производительности, тогда специалисты по информационной безопасности получают конкретные цели и задачи, которые помогают организовать защищенную инфраструктуру.
Что касается конкретных мер, предлагаю рассмотреть два направления:
Во-первых, многое можно решить путем изменения подходов к классификации информации. Разделение данных на категории позволяет снижать уровень контроля над теми видами информации, которые не представляют существенной ценности с точки зрения кибербезопасности. К примеру, использование термина "индикатор" вместо "датчик" способно значительно облегчить прохождение согласования проектов, связанных с внедрением беспроводных устройств.
Во-вторых, создание собственных частных сетей стандарта IIoT, таких как LoRaWAN, позволяет полностью контролировать весь цикл передачи данных. Благодаря использованию отечественного оборудования удается снизить затраты на проект и повысить степень защиты данных. Так, установка базовой станции LoRaWAN позволит предприятию самостоятельно управлять всеми аспектами своей инфраструктуры, не прибегая к сторонним провайдерам связи.
Таким образом, уверяю вас, что необходимые технические и организационные меры существуют и успешно применяются на практике. Разумеется, потребуется определенное усилие для реализации указанных шагов, однако полученный эффект в виде улучшенной системы мониторинга и управления производственными процессами оправдает себя сполна.
Насколько знаю от коллег, такие сети разделяют, как минимум сеть мониторинга и сеть, отвечающую за критичные части тех. процесса, разделяют. Да, часто ИБ тормозит процесс, в силу новизны подходов. Пока изучат, пощупают, посмотрят на опыт других предприятий... :)
Современные IIoT сети строятся на беспроводных стандартах, которые сложно ломаются. Глушить всегда можно, это открытый эфир, ничего тут не сделаешь. И тут нужно взвешивать все риски от "отсутствия" данных.
которые сложно ломаются.
При правильном использовании.
Берет файлик: https://cdn.prod.website-files.com/648c3f599e160806e737e378/655750fb1eeb16e8c31f5e18_УК-4.0.pdf
На второй странице выясняете, что ключ один на все каски. Какой ключ, выясняете там же.
Читаете на сайте кейсы, что-нибудь про урановые рудники, глядите вокруг на текущие военно-политические реалии, и начинаете тихо грустить.
Я сравнительно недавно имел возможность поинтересоваться, как же оно так получилось? Получил ответ, что этого не может быть, потому что не может быть никогда. После чего документация была поправлена без лишнего шума, в свежей версии (которая почему-то тоже датирована октябрем 2023-го ;-) ) утверждается, что ключ индивидуален для каждого устройства. Вот только есть причины, по которым мне кажется, что это некоторое лукавство.
А вот на устройства от @AutonAutograph вообще внятной документации не видно. И кто его знает, какие чудеса там могут оказаться? И в документации, и в устройствах.
Это не лукавство. Смотрим в этом документе тип активации, а он OTAA. А это точно уникальные ключи для каждого устройства, которые генерируются в процессе подключения. В LoRaWAN 1.1 (не очень распространен пока) еще и их периодическая смена через Rejoin.
Защита от атаки повтора реализована через счетчик. Полезная нагрузка и MAC-уровень, включая счетчик, шифруется и проверяется на Message Integrity.
А то, что кто-то корневые ключи выкладывает (AppKey, NwkKey). Ну так это обычная утечка. Человеческий фактор никто не отменял. Это не относится к технологии.
Ломайте. Могу предоставить тестовую среду, если есть желание.
Это не лукавство. Смотрим в этом документе тип активации, а он OTAA. А это точно уникальные ключи
Документ говорит про ключ активации. Я, в общем, тоже. Вы пишете про сессионные. Все правильно пишете, только про другое.
Полезная нагрузка и MAC-уровень, включая счетчик, шифруется и проверяется на Message Integrity.
Там несколько иначе (FCnt, счетчик т.е., прекрасно видно в дампе пакета без всяких ключей, например. Как и многое другое из frame header.) и сложнее все устроено. Только мы опять про другое.
LoRaWAN 1.1 (не очень распространен пока)
Это "пока" продолжается уже довольно много лет. К теме разговора не относится, снова мы про другое, но жить эта версия особо и не будет. Затевалось в первую очередь ради roaming, но roaming сам оказался dead on arrival. Как раз с безопасностью проблемы выплыли. Сейчас переделывают все, если не бросят, посмотрим. Бросят, так тоже не беда.
Это не относится к технологии.
А я технологию не критиковал. Зачем? Она меня неплохо кормит практически с момента своего появления. Просто написал, что надо пользоваться с умом и правильно.
А то, что кто-то корневые ключи выкладывает (AppKey, NwkKey). Ну так это обычная утечка. Человеческий фактор никто не отменял.
Нет, обычная утечка вот тут где-то начиная с 1:20 :
https://rutube.ru/video/18035d766ab4621c27e4c198bea0476d/ .
Люди занимаются имитацией бурной деятельности, совершают бессмысленные телодвижения для красивой картинки на ТВ, и заодно светят AppKey. Но они, заметьте, скомпроментировали только одно устройство. Потому что на тех устройствах AppKey уникальный, с одним на всех проблем огребли еще в 2016-м ;-) , урок все выучили.
А когда у людей один AppKey на все устройства, это, для начала, спецификации не соответствует, там есть оговорка на эту тему. Ну и самой идее preshared secret противоречит. Просто не было у людей времени или желания нормальное управление ключами делать, это действительно непросто, особенно если еще надо и "удобство" техподдержке и конечным пользователям обеспечить. Ну и перекинули через забор понятно, что. Они не одиноки, и даже к LoRaWAN прямого отношения это не имеет. С Zigbee та же проблема часто, например.
Ломайте. Могу предоставить тестовую среду, если есть желание.
Спасибо, но я же писал, что донес до Softline digital все, что считал нужным донести. Судя по тому, что доку поменяли - услышали. У меня сейчас на руках китайщина сходного назначения и с теми же проблемами (почему вообще и вспомнил про все это), мне с ней хлопот хватает.
Если ваша организация этими касками пользуется, возможно, вам самому стоит все проверить. Для общего блага. Судя по соседнему комментарию, проблемы для вас это не составит. Вектора наверняка понятны, но читать можете не только вы, поэтому поясню.
Имея AppKey:
Ловите JoinRequest, вытаскиваете из него DevEUI/JoinEUI/DevNonce, генерите свой JoinRequest. С DevNonce придется намного поиграться, потихоньку инкрементируя, но довольно быстро у вас получится запрос, который просто вышибет "жертву" из сети. Теплый ламповый denial of service.
Ловите JoinRequest, ловите JoinAccept, восстанавливаете AppSKey и NwkSKey. Дальше делаете, что считаете нужным.
Соберетесь проверить - расскажите потом. Любопытно, исправили ситуацию, или исправили только документ? Просто по цепочке и руководство по эксплуатации всей системы должно бы поменяться, ключи-то уникальные надо как-то грузить в конкретный экземпляр Network server, а этих изменений вроде не было. Можно еще @ivansychev , он тут эти каски года два назад пиарил, вроде причастен к делу, про шифрование там писал и все такое :-)
Там несколько иначе (FCnt, счетчик т.е., прекрасно видно в дампе пакета без всяких ключей, например. Как и многое другое из frame header.)
Некорректно написал, FCnt действительно в открытом виде в FHDR, но значение участвует и в вычислении MIC (там все сообщение целиком берется) и в декрипте FRMPayload. При отсутствии сессионных ключей задача "сломать" сложная.
По поводу одного AppKey на все устройства согласен полностью. Это серьезная проблема.
Если ваша организация этими касками пользуется, возможно, вам самому стоит все проверить. Для общего блага. Судя по соседнему комментарию, проблемы для вас это не составит. Вектора наверняка понятны, но читать можете не только вы, поэтому поясню.
Суть атаки понятна, воспроизводил её при помощи эмулятора БС. При наличии AppKey и перехвате любого JoinRequest+JoinAccept можно сгенерировать сессионные ключи. Остальное дело техники.
1.1 действительно практически не представлена в устройствах, но мнение почему версия не взлетает у меня другое. LoRaWAN почему-то занимает нишу LPLAN, вместо LPWAN, а там роуминг пока не нужен. С безопасностью, на мой взгляд, в 1.1 лучше. Как минимум, теперь шифруются MAC-команды в FOpts и разделен корневой ключ на сетевой и прикладной NwkKey, AppKey, вместо единого AppKey в 1.0.х. В чем стало хуже по твоему мнению?
Кстати в РФ роуминг даже никто не попробовал. Было бы интересно почитать, если ошибаюсь.
LoRaWAN почему-то занимает нишу LPLAN, вместо LPWAN, а там роуминг пока не нужен.
Рынок порешал. Без всяких шуток. Нет платежеспособного спроса на всякие nation-wide networks. Подход "build, and they will come" не сработал. Нигде.
С безопасностью, на мой взгляд, в 1.1 лучше. Как минимум, теперь шифруются MAC-команды в FOpts и разделен корневой ключ на сетевой и прикладной NwkKey, AppKey, вместо единого AppKey в 1.0.х. В чем стало хуже по твоему мнению?
Я же не писал, что в 1.1 стало хуже. Я писал, что вскрылись проблемы с безопасностью в целом в roaming в том виде, в котором он сейчас определен. Очень легко фиктивный трафик нагенерить. Особенно проявилось, когда началась всякая децентрализация, Helium появился, и т.п. Ставится эмулятор базухи, с которого шлются пакеты, выглядящие, скажем, как пакеты от устройств из сети Senet. Helium тот же, да и кто угодно еще, кроме самого Senet, не может проверить, валидный это пакет, или нет. Просто перекидывает этот пакет в Senet, и платит владельцу псевдобазухи копеечку. И берет с Senet две копеечки. А потом никак не разобраться, кто ж виноват, и что делать? Все радуются, что это проявилось на копеечных суммах, а не всерьез.
Да, hand-over roaming это порешал бы, но тогда надо ключи раздавать непонятному количеству непонятных людей, хоть с 1.0.X, хоть с 1.1. А кто из них отвечать будет, случись что?
Кстати в РФ роуминг даже никто не попробовал. Было бы интересно почитать, если ошибаюсь.
Ну, формально "Лартех" когда-то с кем-то из французов соглашение подписывал :-) Хотя это была очевидная туфта, как минимум из-за разницы в частотах. А так - кому с кем подписывать-то? Кстати, не только России касается.
Ну, формально "Лартех" когда-то с кем-то из французов соглашение подписывал :-) Хотя это была очевидная туфта, как минимум из-за разницы в частотах. А так - кому с кем подписывать-то? Кстати, не только России касается.
Я рассматриваю роуминг чуть шире Это не только способ пропуска трафика через чужие сети, но и возможность децентрализации. Т.е. все LNS, которые находятся в роуминговых отношениях, могут принадлежать одному владельцу. По аналогии с Интернетом, когда один оператор может владеть несколькими AS, или другая ситуация, когда от одной и той же AS анонсируются разные сети от разных пограничных маршрутизаторов.
Если упрощать, то роуминг, на техническом уровне, это всего лишь способ отмаршрутизировать трафик.
А вот на устройства от @AutonAutograph вообще внятной документации не видно. И кто его знает, какие чудеса там могут оказаться? И в документации, и в устройствах.
Много разных устройств уже повидал, в т.ч. и собственные разработки есть. Устройства Автограф отношу к одни из самых продуманных. А самое главное, они их постоянно улучшают.
Вы к ним обратитесь. Все дадут. Там же основной документ это описание прикладного протокола.
в т.ч. и собственные разработки есть.
Всегда приятно пообщаться с коллегой.
Устройства Автограф отношу к одни из самых продуманных.
Искренне рад, если все ОК. Просто непонятно, зачем описание протокола секретить? Это только на ненужные размышления наводит, и все.
Искренне рад, если все ОК. Просто непонятно, зачем описание протокола секретить? Это только на ненужные размышления наводит, и все.
Не могу знать :) Смотрели почти всю линейку, понравилась. Коммерческий видно, что болеет за дело и с технической частью все в порядке. С сетевой частью там в целом все стандартно, прикладной протокол тоже простой. Их выделяет исполнение самих приборов, видно, что думают об эксплуатации.
Переход к Индустрии 4.0: роль беспроводных датчиков в повышении эффективности производства