Стандарт за отдалечено обслужване на производителя на машини определя поддържаните задачи, необходимите приложения, отговорностите на клиента и OEM и тестовете при предаване. Използвайте един и същ запис на услугата и стъпки за завършване за всички клиенти, с документирани опции за свързване за различни мрежи на обекта.
Целта е последователност, без да се преструваме, че всяко клиентско растение е идентично. Стандартизирайте резултатите, доказателствата и точките за вземане на решения. Нека клиентът запази властта над своята мрежа, производствения график, безопасността на машините и процеса на промяна.
Защо поддръжката става по-трудна с увеличаването на машините?
Първите няколко доставени машини често разчитат на лични познания. Един инженер помни версията на PLC, друг знае кой VPN профил достига до клиента, а трети има единственото използваемо резервно копие. С нарастването на инсталираната база този неофициален модел създава опашки и изключения. Сервизните екипи отделят време за възстановяване на контекста, преди да започне диагностиката.
Клиентските среди също се различават по адресиране, защитни стени, правила за идентичност, инженерни работни станции и политики на доставчика. Определете необходимите контроли и малък набор от одобрени модели, вместо да изисквате един плосък мрежов дизайн.
Серията ISA/IEC 62443 третира автоматизираната киберсигурност като споделена отговорност между собственици на активи, доставчици на продукти, интегратори и доставчици на услуги през целия жизнен цикъл на системата. Това е полезна отправна точка: офертата за дистанционна услуга на OEM трябва да посочва къде започва и свършва нейната отговорност, вместо да предполага, че производителят на машината контролира цялата OT среда на клиента.
Какво да съдържа каталогът за дистанционно обслужване?
Дефинирайте каталог на услугите, преди да изберете технология. Всяка способност трябва да има своя собствена цел, привилегия, предпоставки и доказателства.
| Сервизна способност | Типична цел | Граница на разрешение | Необходима локална роля | Примерни доказателства за завършване |
|---|---|---|---|---|
| Преглед на състоянието и алармата | Публикувано табло за управление, HMI изглед или архив на времеви серии | Функции на приложението само за четене, когато са технически поддържани | Оперативният контакт потвърждава машината и времевия диапазон | Констатации и препоръчителна следваща проверка |
| Поддръжка на приложения | Наименувано MES, SCADA, отчет или приложение за обслужване на машини | Едно приложение и назначена роля | Собственикът на приложението разрешава заявка за поддръжка | Конфигурация или запис на инцидент |
| Поддръжка на управлявана работна станция | Работна станция за OEM инженеринг или поддръжка | Отдалечен работен плот към един хост; потоците надолу по течението са ограничени | Местен координатор на разположение за последваща работа | Сесия, свързана със случай и записани резултати |
| Одобрен обмен на файлове | Контролирано място за прехвърляне или управлявана работна станция | Конкретни потребители, вид файл и правила за мястото на прехвърляне | Процедура за прехвърляне на отзиви от клиенти | Идентификация на файла, резултат от сканиране или валидиране и получател |
| PLC или HMI инженерство | Управлявана инженерна работна станция и избран поток от устройства | Отделна привилегирована роля и протокол | Упълномощено местно лице потвърждава работния прозорец и състоянието на машината | Архивиране, одобрена промяна, валидиране и базова актуализация |
| Актуализация на софтуер или edge приложение | Платформа от страна на обекта или наименувано приложение | Подписан или контролиран пакет към идентифицирана цел | Клиентът сменя собственика, който одобрява времето | Версия, резултат, състояние на връщане назад и открити проблеми |
Не продавайте „пълен отдалечен достъп“ като една единствена възможност. Наблюдението, конфигурацията и промените в контролера имат различни последствия. Разделянето им прави по-ясно както одобрението на клиентите, така и обучението за поддръжка на OEM.
Кои части трябва да бъдат стандартизирани във всяка машина?
Създайте сервизен запис на машината при поръчка или пускане на проект, след което го поддържайте до извеждане от употреба. Като минимум стандартизирайте:
- идентификатори на машина, клиент, обект и отговорен собственик
- продуктово семейство, контролер, HMI, задвижване, робот, край и базови линии на приложения
- одобрените сервизни възможности и точните отдалечени цели
- модел на шлюз или работна станция от страна на обекта и неговия собственик за поддръжка
- Ролите на OEM и клиентските роли имат право да използват всяка възможност
- местоположение за архивиране и кой проверява възстановяването
- приемане при въвеждане в експлоатация, готовност за обслужване и състояние на тест за прекъсване
- специфични за клиента ограничения и одобрени изключения
- преглед на достъпа, сертификат, лиценз, гаранция и дати за поддръжка, когато е приложимо
- състояние на извеждане от експлоатация и потвърждение, че достъпът и съхранените тайни са премахнати
Не копирайте идентификационни данни или чувствителни подробности за мрежата в неконтролирана електронна таблица. Съхранявайте всеки клас данни в неговата оторизирана система и го свързвайте чрез стабилен ID на машината.
Производственият профил на NIST описва доброволен, базиран на риска подход за производствени системи и използване на текущи и целеви профили за съобщаване на желани резултати за киберсигурност. OEM може да използва същия принцип вътрешно: документира целевото състояние на отдалечена услуга за фамилия машини, сравнява всяко внедряване с него и проследява оправданите пропуски.
Как трябва да се разпределят отговорностите на OEM и клиентите?
Публикувайте матрица на отговорността като част от офертата за услуга и я повторете при предаването на клиента.
| Дейност през жизнения цикъл | Производител на машини / OEM | Собственик на клиентски актив | Локален обект или оперативна роля |
|---|---|---|---|
| Сервизен дизайн | Дефинира поддържани цели, верига от инструменти, версии и роли за поддръжка на OEM | Определя политиката на обекта, очакванията за риск и приемливите модели | Съветва оперативни ограничения |
| Включване в обекта | Конфигурация на доставките и тестове за приемане | Одобрява мрежовото разположение, идентичности, маршрути и обработка на данни | Потвърждава идентичността на машината и местната готовност |
| Рутинна диагностика | Определя конкретен инженер и записва констатациите | Разрешава достъпа според споразумението за поддръжка | Осигурява симптоми, състояние на машината и локално наблюдение |
| Промяна, засягаща процеса | Предлага промяна, архивиране, валидиране и връщане назад | Одобрява чрез своята процедура за промяна | Потвърждава безопасното състояние, наблюдава поведението и може да спре работа |
| Поддръжка на платформата | Поддържа компоненти, контролирани от OEM, и поддържа съвместимост според договора | Поддържа контролирана от клиента зависимост от мрежа и идентичност | Координира прозореца за поддръжка и производственото въздействие |
| Реагиране на инциденти | Деактивира или проучва достъпа от страна на OEM според изискванията и съобщава въздействието | Води отговор за клиентската среда | Защитава безопасната локална работа и предоставя наблюдения |
| извеждане от употреба | Премахва машината от системите за обслужване на OEM и затваряне на документи | Премахва достъпа до обекта, акаунтите, маршрутите и запазените данни, както е приложимо | Потвърждава разположението на оборудването |
Една фирма може да изпълнява няколко роли. Посочете конкретен отговорник за всеки ред. Включете договорените отговорности в сервизната оферта и документацията при предаване.
Коя архитектура може да се прилага в различни клиентски мрежи?
Предложете малка библиотека с шаблони. Един клиент може да одобри публикуване на ниво приложение за табло за управление. Друг може да изисква управлявана инженерна работна станция в гранична зона. Трети може да позволи тясно ограничен път на шлюз към машинен ресурс. Дефинирайте едни и същи резултати за сигурност за всеки модел:
- уникална човешка идентичност навсякъде, където платформата я поддържа
- достъпът е ограничен до одобрения машинен ресурс и задание
- отделни рутинни и привилегировани инженерни роли
- няма зависимост на локалния контрол от отдалечената връзка
- документирани собственици за компонента на обекта, актуализации, сертификати и архивиране
- тествано поведение при премахване, прекъсване, повторно свързване и възстановяване
- няма непреднамерен маршрут до съседни клиентски активи
NIST Guide to OT Security обяснява защо контролите на OT трябва да зачитат ограниченията за производителност, надеждност и безопасност. Не превръщайте модела на сигурност в производствена зависимост. PLC и локалната система за безопасност остават авторитетни, когато отдалечената услуга, шлюзът, доставчикът на идентичност или интернет връзката не са достъпни.
За подробни архитектурни компромиси, сравнете VPN, междинни сървъри и ZTNA за OT. Използвайте контролния списък за разпространение на отдалечен достъп, за да тествате последователно всеки модел на обект.
Какво да съдържа общата сервизна процедура?
Направете Runbook достатъчно кратък за използване и достатъчно строг, за да спре двусмислената работа.
- Прием: запишете ID на машината, контакт с клиента, симптоми, състояние на производство, спешност и искан резултат.
- Класифициране: изберете възможностите на услугата и решете дали случаят е наблюдение, конфигурация или инженеринг, засягащ процеса.
- Упълномощаване: потвърдете препратката за упълномощаване на клиента, назован OEM инженер, целеви ресурс, разрешен прозорец и необходим локален координатор.
- Подгответе: проверете съвместимостта на версията, резервни копия, одобрени файлове, комуникации, условия за спиране и връщане назад.
- Свързване: проверете идентичността и целевата машина, след което започнете с най-ниската привилегия, която може да завърши диагностиката.
- Диагностика: заснемане на наблюдения и разграничаване на доказателства от хипотези. Не разширявайте достъпа само за да изследвате.
- Промяна, ако е одобрена: използвайте отделната процедура за промяна; запишете състоянието преди и след и валидирайте локално.
- Затваряне: обобщете работата, оставащия риск, действието на клиента, състоянието на достъп и дали записът на услугата се нуждае от актуализация.
- Научете: прегледайте повтарящи се изключения, липсваща телеметрия, несъвместимост на инструменти и пропуски в обучението на редовна среща за обслужване.
Инструментите за отдалечен достъп се използват и от нападатели, както посочва съвместното ръководство на CISA за отдалечен достъп. Направете списък на сервизните агенти. Премахнете ненужните и неразрешените инструменти. Клиентът трябва да може да прекъсне този достъп, без да спира локалното управление на машината.
Как се потвърждава готовността за обслужване при предаване?
Добавете тест за приемане на дистанционно обслужване към пакета за въвеждане в експлоатация на машината. Това трябва да докаже повече от „инженерът се свърза веднъж“. тест:
- назовани OEM и клиентски идентичности, разделяне на ролите и премахване
- всяко публикувано приложение, работна станция или устройство спрямо одобрения обхват
- неуспешни опити за достигане на съседна цел
- наблюдение и инженерни разрешения като различни тестове
- поддържаните функции на PLC/HMI, включително всякакви изисквания за откриване или прехвърляне на файлове
- производителност при представителна латентност и загуба на пакети
- загуба на интернет, идентичност, шлюз, отдалечен клиент и сесия
- наличност на текущо архивиране и брифинг за локално възстановяване
- който получава известия за работа и сигурност от всяка зависимост
- как клиентът иска, разрешава, поставя на пауза и завършва случай за поддръжка
Използвайте контролния списък за пускане в експлоатация на отдалечена машина, за да интегрирате тези тестове със стартиране и предаване. Записвайте изключения, вместо да декларирате готовност, когато изискван тест е бил пропуснат.
Кои мерки показват дали стандартът работи?
Изберете мерки, които разкриват здравето на процеса, без да обещават бизнес резултат, който данните не могат да поддържат. Полезните примери включват процент на активни машини с назован собственик на услугата, текуща техническа база, тестван път за поддръжка, възстановимо архивиране, завършен преглед на достъпа и затворени изключения за включване. Проследявайте случаи, които изискват непланирано разширяване на достъпа, неподдържани инженерни версии или липсваща локална координация.
Показатели като времето за назначаване на квалифициран инженер или за установяване на одобрен достъп показват къде процесът се забавя. Те не доказват намален престой или избегнато пътуване. Тези резултати зависят от повредата, частите, персонала, решенията на клиента и други фактори. Измервайте ги само спрямо определена начална стойност и сравними случаи.
NIST Cybersecurity Framework 2.0 организира резултатите около управление, идентифициране, защита, откриване, реагиране и възстановяване. Използвайте тези функции като леща за преглед: Уредени ли са отговорностите? Идентифицирана ли е инсталираната база? Защитени ли са пътеките? Може ли да се открие злоупотреба? Могат ли OEM и клиентът да отговорят заедно? Могат ли достъпът и обслужването на машината да се възстановят безопасно?
Какви са ограниченията, изключенията и контролите на жизнения цикъл?
Стандартизацията не прави всеки стар протокол поддържан или всяка задача безопасна за дистанционно изпълнение. За всяко изключение определете отговорник, причина, компенсиращи мерки, дата за преглед и план за прекратяване. Ограничете старите протоколи зад управлявана работна станция. Не ги предоставяйте на всеки потребител. Ако клиентът забранява дистанционни инженерни промени, определете достъп само за диагностика и местна сервизна процедура.
Прегледайте сервизния запис след смяна на контролера, миграция на HMI, промяна на мрежата, актуализация на шлюза, смяна на собствеността, промяна на договора или инцидент със сигурността. При извеждане от употреба премахнете идентичностите, връзките, сертификатите, лицензите, копията на проекти и машинните записи според договорените правила за съхранение. Потвърдете, че компонентът при клиента е премахнат или предаден на посочен отговорник.
ISO/TR 22100-4 подчертава заплахите за киберсигурността, които могат да повлияят на безопасността на машините. Прегледайте отново оценката на риска на машината, когато нова дистанционна функция или възможност за актуализиране може да повлияе на резултат, свързан с безопасността. Запишете произтичащите промени в дизайна и проверката в техническата документация на машината.
Къде може да се впише Orenda в стандарт за обслужване на машиностроители?
Orenda Connect дава на OEM екипа достъп до одобрени ресурси на клиента в избрания проект. Orenda Box събира машинни данни и изпълнява локални приложения на обекта. Решението за производители на машини позволява да започнете с един сервизен процес. Страницата за дистанционно обслужване на инсталираните машини обяснява как екипите документират и използват този подход в отделни клиентски проекти и устройства Box. Всеки обект се проверява отделно.
Съхранявайте сервизната заявка, одобрението на клиента, записа на промяната и резервната справка в системите за обслужване на OEM и клиентите. Orenda предоставя достъп до избраните ресурси. Оторизираните потребители могат да създават и отменят връзки към доставчици и да задават изтичане по избор. Споделена връзка идентифицира предоставения достъп, така че използвайте индивидуални потребителски акаунти, когато записът на услугата трябва да идентифицира лицето, което се е свързало.
Пилотирайте модела на едно семейство машини и малък набор от сервизни възможности. Валидирайте точните протоколи, клиентските роли, границите на ресурсите, поведението при прекъсване, собствеността върху поддръжката, премахването на достъпа и доказателствата за предаване, преди да разширите предлагането на услугата в цялата инсталирана база.
