Проектиране на HMI/SCADA приложения с оглед на киберсигурността – принципи, които намаляват риска още на етапа на проектиране

За безопасността на HMI/SCADA приложението се вземат решения много по-рано, отколкото на етапа на избор на защитни механизми. Дали системата ще бъде устойчива на грешка, злоупотреба и неконтролирана промяна на състоянието на процеса, зависи преди всичко от приетите проектни допускания: разпределението на ролите, границите на доверие, обхвата на функциите, достъпни през интерфейса, както и от начина на организиране на сервиза и отдалечения достъп. Ако тези въпроси бъдат оставени на заден план, приложението ще започне да затвърждава риска, вместо да го ограничава. Затова проектирането на HMI/SCADA с оглед на киберсигурността трябва да се води като инженерна задача: първо да се определи кои операции са критични, какви последици могат да имат и кой действително трябва да може да ги изпълнява, и едва след това да се изграждат екраните, алармите и удобството при работа.

Киберсигурността започва още в проекта

В HMI/SCADA системите киберсигурността не е добавка към вече готовата визуализация. Тя произтича от решения, взети по-рано: от архитектурата на приложението, модела на правата за достъп, начина на комуникация с управлението и допусканията за сервиз. Това е особено важно, защото HMI/SCADA приложението е едновременно точка на взаимодействие между човека, процеса и инфраструктурата. Затова проектна грешка не се изчерпва само с ИТ риск. Тя може едновременно да повлияе на реакцията на оператора, функционалната безопасност, оперативния риск и непрекъснатостта на производството.

От гледна точка на проекта основният въпрос не е каква защита да се добави накрая, а кои решения още в началото ще ограничат повърхността на атака. Най-големите проблеми обикновено не произтичат от липсата на единичен механизъм, а от прекомерното доверие, заложено в приложението. На практика това означава общи потребителски акаунти, широк и постоянен сервизен достъп, липса на разделение на ролите между оператора, поддръжката и интегратора, както и прекалено свободна комуникация между операторския слой и управлението. На етапа на пускане в експлоатация такива решения изглеждат удобни, защото ускоряват работата и улесняват диагностиката. По-късно обаче се превръщат в трайна характеристика на средата и увеличават риска от злоупотреба, грешка или неконтролирана промяна в състоянието на процеса.

Затова преди проектирането на екраните е добре да се определи не само какво трябва да вижда потребителят, а преди всичко къде минават границите на доверие, кои операции са критични и в кои точки интерфейсът може да се превърне в инструмент за грешка или заобикаляне на процедура. Такава последователност подрежда и следващите решения: дали HMI трябва да бъде само слой за визуализация, или и място за конфигуриране, диагностика и промяна на рецепти; дали сервизните функции трябва да работят постоянно, или само след съзнателно активиране; дали операторът трябва да има достъп единствено до управление на процеса, или и до операции, които променят параметри и историята на данните.

Практическата цена на пропуските обикновено става видима едва когато приложението вече е обвързано с рецепти, аларми, отчетност, архивиране и процедури по поддръжка. Тогава дори на пръв поглед проста корекция, като разделяне на акаунтите, промяна на начина за одобрение на критична операция или ограничаване на отдалечения достъп до инцидентен режим, престава да бъде промяна само по екраните. Тя изисква преработване на логиката, повторно тестване на обработката на алармите, изясняване на отговорностите и често също организационни промени в предприятието.

На практика най-разумната отправна точка е работна карта на потребителските роли и техните права за критични операции, списък на функциите, които водят до промяна на състоянието на процеса, конфигурацията или рецептите, както и списък на външните връзки, обхващащ сервиз, отчетност, надзорни системи и отдалечен достъп. Едва на тази основа може смислено да се проектира архитектурата на зоните и връзките и да се подготви последващият анализ на риска. Такъв подход съответства както на инженерната практика, така и на изискванията за ясно разпределяне на отговорностите, разделяне на функциите и контрол на комуникацията в средите на индустриалната автоматизация.

Къде всъщност нарастват разходът и рискът

Най-големият разход и риск в HMI/SCADA приложението не произтичат единствено от самия факт на свързване на системите, а от това какви процесни и организационни последици предизвикват отделните функции на приложението. Най-чувствителни са онези места, които позволяват бърза промяна на настройките, въвеждане на заобикаляне, заглушаване на аларма, промяна на рецепта или ръчно управление без пълен технологичен контекст. Ако проектът допуска такива операции от производствения екран в рутинен режим, рискът нараства, защото едно потребителско решение или една компрометирана сесия може пряко да промени състоянието на процеса.

Това означава, че каталогът на критичните операции трябва да се разглежда като елемент от архитектурата на сигурността, а не само като въпрос на ергономия на интерфейса. Същият механизъм важи и за отчетността на действията. Общи логини, акаунти, споделяни между смените, липса на разделение на правата за преглед, управление, конфигуриране и администриране, както и оскъдно регистриране на събитията водят до това, че след инцидент е трудно надеждно да се установи дали е станала грешка, заобиколена е процедура, злоупотребено е със сервизен достъп или е извършено неоторизирано действие. Проблемът не се изчерпва само с разследването на причините. Без достоверна следа от действията на потребителя не може да се оцени и ефективността на процедурите, да се управляват смислено правата за достъп, нито да се защитят експлоатационните решения пред вътрешен одит, изискванията на клиента или приетите политики за сигурност. На практика тук става дума за отчетност на действията и проследимост, а не само за самия запис на събития.

Много скъпа проектантска грешка е и пренасянето в производствената среда на разширени сервизни и диагностични екрани, първоначално подготвени за пускане в експлоатация или за нуждите на интегратора. Такива изгледи често дават широк достъп до вътрешни променливи, принудително задаване на състояния, изчистване на блокировки и промяна на параметри, въпреки че при нормална експлоатация са необходими най-много инцидентно. Ако не бъдат обхванати с допълнителни ограничения, те се превръщат в най-краткия път за намеса в процеса извън обичайния операторски сценарий. Разумното решение е да се отдели диагностиката, необходима за поддръжката, от функциите, които позволяват намеса в логиката на работа, както и отделно да се реши дали диагностиката на производителя на машината да бъде достъпна локално, дистанционно или само при определени условия, след съзнателно активиране и с пълен запис на сесията.

По същия начин трябва да се разглежда и интеграцията с бази данни, отчетност, дистанционна поддръжка и офис системи. Всяка такава връзка подобрява удобството на работа, но едновременно с това увеличава броя на зависимостите, които могат да се превърнат във входна точка, източник на смущения или причина за загуба на яснота по отношение на отговорностите. Отказ на посредническа услуга, грешна синхронизация на времето, неконтролиран обмен на данни със система от по-високо ниво или оставен сервизен канал могат да влияят не само върху наличността на отчетите, но и върху решенията, които операторът взема.

Затова още на етапа на проектиране си струва да се измерва не само наличността на екраните, но и по-прости и по-полезни показатели: броят на критичните операции, възможни от производственото HMI, броят на активните външни връзки, броят на привилегированите акаунти и обхватът на събитията, включени в одитната следа. Такъв преглед впоследствие внася ред в регистрирането на събитията, контрола на промените по параметрите и правилата за дистанционен достъп.

Отделно внимание изисква алармирането. В тази област привидната пълнота често прикрива реална липса на контрол. Лошо проектираните аларми и история на събитията не само претоварват оператора, но и му отнемат способността да различава критичните сигнали от техническия шум. Ако алармата може лесно да бъде заглушена без обосновка, потвърдена без връзка с причината или изгубена в масата от диагностични съобщения, приложението престава да подпомага безопасността на процеса. Затова приоритетите на алармите трябва да произтичат от реалните последици за хората, машината и качеството на производството и да останат свързани с правилата за регистриране на потвърждения, заобикаляния и промени в настройките. Именно в този момент анализът на риска престава да бъде формален документ и започва да оформя интерфейса.

Как да се проектира така, че да се ограничат последиците от грешка и злоупотреба

Изходната точка е проста: приложението HMI/SCADA не може да приема, че всеки потребител винаги действа правилно и в правилния контекст на процеса. Проектирането трябва да започне с разделяне на функциите, а не с рисуване на екрани. Екипът първо трябва да определи какво операторът трябва само да вижда, какво може да потвърждава, какво има право да променя в нормалния ход на работа и кои действия трябва да бъдат прехвърлени в сервизен режим, да бъдат обхванати с допълнителна авторизация или напълно изведени в отделен инструмент или станция.

Такова решение подрежда цялата архитектура на достъпа: ролите, обхвата на правата, начина на регистриране на действията и условията за дистанционна поддръжка. На практика добре работи матрица на ролите, базирана на реалните задължения, която различава оператор, бригадир, поддръжка, технолог, интегратор и администратор. Това не е формалност. Ако сервизните функции остават на същия екран и под същия акаунт като управлението на процеса, самото приложение създава път към грешка, заобикаляне на процедура или злоупотреба с права.

Доброто HMI/SCADA ограничава възможността опасна операция да бъде изпълнена случайно, но не забавя излишно рутинните действия. Това изисква ясен работен контекст: потребителят трябва да вижда върху кой обект работи, в какво състояние е процесът, дали действа локално или дистанционно и дали системата е в автоматичен, ръчен или сервизен режим. Потвържденията трябва да са съобразени с риска, а не еднакви за всички действия. Там, където последицата от грешка е обратима и ограничена, обикновено е достатъчна единична авторизация. Критичните операции изискват допълнителен контрол: второ потвърждение, повторно удостоверяване, зависимост от състоянието на процеса или физическо преминаване към отделен интерфейс.

Съществено значение имат и условните блокировки. Ако приложението допуска промяна на настройка, форсиране на сигнал или преминаване в ръчен режим независимо от състоянието на обекта, рискът се прехвърля от проекта към оператора. Именно тук се вижда, че правилното проектиране на интерфейса не се изчерпва с удобството при работа, а цели да ограничава последствията от грешка чрез вградени бариери. В много случаи този начин на мислене е близък до начина, по който работи Poka-Yoke в производствените линии.

Многослойното проектиране на достъпа трябва да обхваща и начина, по който правата се използват във времето. Индивидуалните акаунти са необходими навсякъде, където се очаква проследимост на действията. Общият акаунт отнема възможността да се установи кой действително е взел решението. Минималният обхват на правата означава, че потребителят получава само функциите, които са му нужни за текущата работа, а повишаването на правата се извършва временно и при контролирани условия. Това важи особено за поддръжката, интегратора и дистанционната поддръжка от производителя. Постоянно отвореният сервизен достъп е удобен само привидно, защото премахва естествената граница на доверие между експлоатацията и сервиза. По-безопасният модел е достъп, активиран при заявка, ограничен във времето, свързан с конкретно лице и отразен в историята на събитията. Този подход добре се вписва в принципа на минималните права и сегментирането на достъпа.

В същия дух трябва да се реши дали сервизните функции да бъдат достъпни от работното HMI, или само от отделна станция, както и дали да се допускат сменяеми носители и локален импорт или експорт на данни от операторския панел. Тези решения не са второстепенни. От тях зависи дали поддържаемостта на системата ще се осигурява по контролиран начин, или чрез временни заобиколни решения.

От гледна точка на инцидент или експлоатационен спор самият интерфейс не е достатъчен. Приложението трябва да оставя данни, които позволяват да се възстанови ходът на взетите решения. Историята на събитията, системните дневници и регистрирането на промените трябва заедно да дават отговор не само на въпроса какво се е случило, но и кой, кога, от кое място и в какво състояние на процеса е извършил операцията. Минималният обхват от събития, които обичайно е добре да се регистрират, включва влизане в системата, промяна на права, промяна на параметри, преминаване в ръчен режим, потвърждаване на аларма и импорт на конфигурация. Ключово е записът да бъде обвързан с технологичния контекст, защото самата информация за промяна без състоянието на обекта често е безполезна.

Добър пример, типичен за много внедрявания, е следният: промяна на прага на аларма от технолог може да е допустима, но само след влизане в предвидения режим, с регистриране на потребителя, станцията, времето, предишната и новата стойност, както и с потвърждение, че обектът не е бил в критично състояние. Такава следа е важна както за безопасността, така и за управлението на промените в индустриалните приложения.

Последният слой е поддържаемост без заобикаляне на защитите. Ако актуализация, възстановяване на конфигурация или диагностика изискват изключване на контрола на достъпа, използване на обща парола или работа без одитна следа, проблемът е в проекта, а не в дисциплината на персонала. Приложението трябва да има предвиден процес за промяна: заявка, оценка на въздействието, тест, внедряване, потвърждение и план за връщане назад. То трябва също да разделя работната от сервизната среда поне логически, а там, където е обосновано, и организационно, и технически. Копията на конфигурацията трябва да могат да се създават и възстановяват по контролиран начин, без инцидентен експорт „за всеки случай“ от панела. Такъв подход е в съответствие с принципа на минималните права в OT и с изискванията за контрол на достъпа, проследимост на действията и управление на промените, като техният обхват винаги трябва да се съотнася към архитектурата на системата и приетото разпределение на отговорностите.

Практика при внедряване и връзка с изискванията

Най-голяма полза носи не добавянето на нови защитни механизми в края на проекта, а подреденият преглед на приложението преди приемане или модернизация. Това е моментът, в който начинът на работа на системата все още може да се коригира сравнително евтино, вместо по-късно погрешните предпоставки да се обграждат с допълнителни процедури. Такъв преглед следва да се извършва от смесен екип: проектанти, поддръжка, експлоатация, специалист по автоматизация и лицата, отговарящи за безопасността.

Предмет на оценката не е само техническата конфигурация, а и това дали приложението действително разделя ролите, защитава критичните операции, ограничава дистанционния достъп до обоснованите случаи, осигурява ясно управление на алармите, съхранява историята на промените и позволява изпълнение на резервни копия и аварийни процедури без заобикаляне на защитите. Именно от такъв преглед трябва да произтича списъкът за FAT/SAT, както и изискванията, включвани в приемането, сервизния план и екзекутивната документация.

Този подход измества фокуса от обсъждането единствено на защитите към проектните решения, които впоследствие определят поведението на хората и оборудването. Ако още на етапа на проектиране не е уточнено кой може да променя параметрите на рецептите, кой одобрява сервизния режим, как се документира намесата на интегратора и при какви условия е допустим достъп извън предприятието, след пускането системата ще се опира на изключения и устни договорки.

По същата причина е добре да се реши дали оценката на приложението да се извърши в рамките на модернизация на машина или линия, или като отделен преглед на OT. Първият подход обвързва по-добре безопасността с функцията на процеса, а вторият улеснява откриването на зависимости между системите и разпределянето на отговорностите за акаунти, права за достъп и регистриране на действията. Това е и естественото място за предварителен анализ на риска: идентифициране на критичните операции, границите на доверие и последиците от грешка на оператора или злоупотреба. На практика тук често е полезен и анализът на риска в проекта.

• ролите и начинът на влизане на потребителите,
• критичните операции и правилата за тяхното потвърждаване,
• отдалеченият достъп и сервизните функции,
• алармите, регистрирането на промените и проследимостта на действията,
• резервните копия, възстановяването и аварийните процедури.

Добрият резултат в предприятието рядко е следствие от едновременното внедряване на много инструменти. Обикновено по-голямо значение има премахването на няколко системни риска, които с години са били приемани за практични. Модернизацията на HMI/SCADA приложение може да започне с премахване на споделените акаунти, отделяне на сервизните функции от операторските, ограничаване на външните връзки до контролирани канали и въвеждане на следа от промените в параметрите с обвързване към конкретно лице или роля. Такава промяна не е задължително да влоши работата на поддръжката и интегратора, стига още от самото начало да са предвидени сервизен режим, правила за оторизация и възпроизводим ход на модификациите.

При експлоатацията след това е добре да се измерва не абстрактно ниво на сигурност, а оперативно полезни показатели: броят на споделените акаунти, които все още остават в системата, обхватът на активния отдалечен достъп, пълнотата на регистрите на промените, времето за възстановяване на конфигурацията и броят на намесите, извършени извън формалната процедура. Такива показатели позволяват да се оцени дали проектът действително е ограничил риска, или само го е прехвърлил в ежедневната практика.

В полските и европейските реалности става все по-трудно да се защити подходът, при който киберсигурността на HMI/SCADA е изключително въпрос на ИТ отдела. Отговорността е разпределена между проектирането, експлоатацията, поддръжката, доставчиците и интеграторите, а отрасловите и договорните изисквания имат значение едва когато организацията може да покаже конкретика: какви проектни решения са взети, как се предоставят правата, каква е следата от действията и кой контролира промените. Самите позовавания на стандарти, политики или договорни клаузи не заместват доказателството, че приложението е проектирано и прието по начин, който позволява безопасна експлоатация.

Най-важният извод е практичен. Най-евтиният и най-ефективният момент за ограничаване на риска остава проектирането и приемането на приложението. Именно тогава с най-малък разход се определят границите на доверие, ролите, условията за достъп, следата от действията и начинът за управление на промените. Ако тези изисквания бъдат преведени в проверими критерии към доставчика и интегратора, HMI/SCADA престава да бъде удобен, но прекалено доверчив интерфейс и се превръща в инструмент за безопасна експлоатация на процеса.