Само оригиналните текстове на ИКЕ на ООН имат правна сила съгласно международното публично право. Статутът и датата на влизане в сила на настоящото правило следва да бъдат проверявани в последната версия на документа на ИКЕ на ООН за статута TRANS/WP.29/343, който е на разположение на електронен адрес: https://unece.org/status-1958-agreement-and-annexed-regulations

Правило № 155 на ООН — Единни предписания за одобрение на превозни средства по отношение на киберсигурността и системата за управление на киберсигурността [2025/5]

Включващо всички текстове в сила до:

Допълнение 3 към първоначалната версия на правилото — дата на влизане в сила: 10 януари 2025 г.

Настоящият документ служи единствено като средство за документиране. Автентични и правно обвързващи текстове са:

—	ECE/TRANS/WP.29/2020/79 (изменен с ECE/TRANS/WP.29/2020/94 и ECE/TRANS/WP.29/2020/97)

—	ECE/TRANS/WP.29/2022/54

—	ECE/TRANS/WP.29/2023/70 и

—	ECE/TRANS/WP.29/2024/55

СЪДЪРЖАНИЕ

Правило

Обхват

Определения

Заявление за одобряване

Маркировки

Одобряване

Сертификат за съответствие за система за управление на киберсигурността

Спецификации

Изменение на типа превозно средство и разширяване на одобрението на типа

Съответствие на производството

10.

Санкции при несъответствие на производството

11.

Окончателно прекратяване на производството

12.

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

Приложения

Информационен документ

Съобщение

Оформление на маркировката за одобрение

Образец на сертификат за съответствие за система за управление на киберсигурността

Списък на заплахите и съответните мерки за смекчаване

1. Обхват

1.1.

Настоящото правило се прилага за превозни средства, по отношение на киберсигурността, от категории L, M, N и O, ако са оборудвани с поне един електронен блок за управление.

1.2.

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

1.3.

Настоящото правило не засяга други правила на ООН, регионално или национално законодателство, регулиращи разработването и инсталирането/системната интеграция на резервни части и компоненти, физически и цифрови, във връзка с киберсигурността.

2. Определения

За целите на настоящото правило се прилагат следните определения:

2.1.

„Тип превозно средство“ означава превозни средства, които са еднакви най-малко по следните съществени характеристики:

а)	Наименованието от производителя на типа превозно средство;

б)	Основни аспекти на електрическата/електронната архитектура и външните интерфейси във връзка с киберсигурността.

2.2.

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

2.3.

„Система за управление на киберсигурността (CSMS)“ означава систематичен, основан на риска подход, определящ организационните процеси, отговорностите и управлението, с цел справяне с риска, свързан с киберзаплахите за превозните средства, и осигуряване на тяхната защита от кибератаки.

2.4.

„Система“ означава набор от компоненти и/или подсистеми, които изпълняват дадена функция или функции.

2.5.

„Развойна фаза“ означава периодът преди одобряването на типа на даден тип превозно средство.

2.6.

„Производствена фаза“ означава продължителността на производството на даден тип превозно средство.

2.7.

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

2.8.

„Мярка за смекчаване“ означава мярка, която намалява риска.

2.9.

„Риск“ означава вероятността при дадена заплаха да се използват уязвимостите на превозното средство, с което да се причинят вреди на организацията или на физически лица.

2.10.

„Оценка на риска“ означава цялостният процес на откриване, разпознаване и описване на рисковете (установяване на рисковете) с цел да се разбере естеството на риска и да се определи нивото му (анализ на риска), както и на сравняване на резултатите от анализа на риска с критериите за риска, за да се определи дали рискът и/или размерът му е приемлив или допустим (оценка на риска).

2.11.

„Управление на риска“ означава съгласувани дейности за управление и контрол на дадена организация по отношение на риска.

2.12.

„Заплаха“ означава потенциална причина за нежелан инцидент, който може да доведе до вреди за дадена система, организация или физическо лице.

2.13.

„Уязвимост“ означава слабост на даден актив или мярка за смекчаване, която може да бъде използвана при условия на една или повече заплахи.

3. Заявление за одобрение

3.1.

Заявлението за одобрение на тип превозно средство във връзка с киберсигурността се подава от производителя на превозното средство или от негов надлежно упълномощен представител.

3.2.

Към заявлението се прилагат посочените по-долу документи в три екземпляра и следните сведения:

3.2.1.

Описание на типа превозно средство във връзка с елементите, посочени в приложение 1 към настоящото правило.

3.2.2.

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

3.2.3.

Сертификат за съответствие за системата за управление на киберсигурността съгласно точка 6 от настоящото правило.

3.3.

Документацията се предоставя в две части:

а)

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

б)

Допълнителните материали, свързани с изискванията на настоящото правило, може да бъдат задържани от производителя, но се предоставят за проверка при одобряване на типа. Производителят гарантира, че всеки материал, който е бил предоставен за проверка по време на одобряването на типа, остава наличен за период от поне 10 години, считано от момента, в който производството на типа превозно средство се прекратява окончателно.

4. Маркировки

4.1.

На всяко превозно средство, което съответства на одобрен по настоящото правило тип превозно средство, на видно и леснодостъпно място, определено във формуляра за одобрение, се поставя международна маркировка за одобрението, състояща се от:

4.1.1.

Окръжност около буквата „Е“, последвана от отличителния номер на държавата, издала одобрението.

4.1.2.

Номера на настоящото правило, следван от буквата „R“, тире и номера на одобрението, отдясно на окръжността, предписана в точка 4.1.1 по-горе.

4.2.

Ако превозното средство съответства на тип превозно средство, одобрен съгласно едно или няколко други правила, приложени към Спогодбата, не е необходимо да се повтаря символът, указан в точка 4.1.1 по-горе, в държавата, издала одобрението съгласно настоящото правило; в такъв случай номерата на правилото и одобрението, както и допълнителните символи за всички правила, съгласно които одобрението е било издадено в държавата, издала одобрение съгласно настоящото правило, трябва да се поставят във вертикални колони в дясно от символа, предписан в точка 4.1.1 по-горе.

4.3.

Маркировката за одобрение трябва да е ясно четлива и незаличима.

4.4.

Маркировката за одобрение се поставя в близост до или на табелката с данни за превозното средство, поставена от производителя.

4.5.

В приложение 3 към настоящото правило са дадени примери за оформлението на маркировката за одобрение.

5. Одобряване

5.1.

Органът по одобряването предоставя, когато това е уместно, одобрение на типа във връзка с киберсигурността само за типове превозни средства, които отговарят на изискванията на настоящото правило.

5.1.1.

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

а)	Да събере и потвърди информацията, която се изисква съгласно настоящото правило, по цялата верига на доставки, за да докаже, че свързаните с доставчиците рискове са определени и се управляват;

б)	Да документира оценката на рисковете (изготвена по време на развойната фаза или със задна дата), резултатите от изпитванията и мерките за смекчаване, приложени за типа превозно средство, включително проектната информация, която подкрепя оценката на риска;

в)	Да бъдат въведени подходящи мерки, свързани с киберсигурността, в проекта на типа превозно средство;

г)	Да бъдат открити и да се реагира на евентуалните атаки срещу киберсигурността;

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

5.1.2.

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

5.1.3.

Органът по одобряването или техническата служба отказват да предоставят одобрение на типа във връзка с киберсигурността, ако производителят на превозното средство не е изпълнил едно или повече от изискванията, посочени в точка 7.3, по-специално:

а)	Производителят на превозното средство не е извършил изчерпателната оценка на риска, посочена в точка 7.3.3.; включително, ако производителят не е взел предвид всички рискове, свързани със заплахите, посочени в приложение 5, част A;

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

в)	Производителят на превозното средство не е въвел подходящи и пропорционални мерки, за да осигури специални среди за типа превозно средство (ако са предвидени) за съхранението и изпълнението на следпродажбено обслужване, включващо софтуер, услуги, приложения или данни;

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

5.1.4.

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

5.2.

Страните по Спогодбата от 1958 г., които прилагат настоящото правило, биват уведомявани относно одобрението, разширяването или отказа за издаване на одобрение на тип превозно средство съгласно настоящото правило, посредством формуляр, който съответства на образеца от приложение 2 към настоящото правило.

5.3.

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

5.3.1.

Органът по одобряването и неговата техническа служба гарантират, в допълнение към критериите, определени в списък 2 от Спогодбата от 1958 г., че разполагат с:

а)	Компетентен персонал с подходящи умения в областта на киберсигурността и конкретни знания по отношение на оценката на рисковете в автомобилния сектор; (1)

б)	Въведени процедури за еднообразна оценка съгласно настоящото правило.

5.3.2.

Всяка страна по Спогодбата, която прилага настоящото правило, уведомява и информира чрез своя орган по одобряването другите органи по одобряването на договарящите се страни, които прилагат настоящото правило на ООН, относно метода и критериите, които нотифициращият орган е използвал като основа, за да оцени целесъобразността на мерките, взети в съответствие с настоящото правило и по-специално с точки 5.1, 7.2 и 7.3.

Тази информация се споделя a) само преди предоставянето за първи път на одобрение съгласно настоящото правило и б) всеки път когато се актуализира методът или критериите за оценка.

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

5.3.3.

Информацията, посочена в точка 5.3.2, се качва на английски език в сигурната интернет база данни „DETA“ (2), създадена от Икономическата комисия за Европа на Организацията на обединените нации, своевременно и не по-късно от 14 дни, преди за първи път да бъде предоставено одобрение съгласно съответните методи и критерии за оценка. Информацията трябва да бъде достатъчна, за да се разбере какви минимални нива на ефективност са били приети от органа по одобряването за всяко отделно изискване, посочено в точка 5.3.2, както и процесите и мерките, които той прилага, за да потвърди съответствието с тези минимални нива на ефективност. (3)

5.3.4.

Органите по одобряването, които получават информацията, посочена в точка 5.3.2, може да представят на нотифициращия орган по одобряването коментари, като ги качат в DETA в рамките на 14 дни след деня на уведомяването.

5.3.5.

Ако не е възможно издаващият одобрението орган да вземе предвид коментарите, получени в съответствие с точка 5.3.4, органите по одобряването, които са изпратили коментарите, и издаващият одобрението орган трябва да потърсят допълнителни пояснения в съответствие със списък 6 от Спогодбата от 1958 г. Съответната помощна работна група (4) към Световния форум за хармонизация на регулаторната уредба за превозните средства (WP.29) за това правило се договаря относно общо тълкуване на методите и критериите за оценка. (5) Това общо тълкуване се прилага и всички органи по одобряването съответно издават одобрения на типа съгласно настоящото правило.

5.3.6.

Всеки орган по одобряването, който предоставя одобрение на типа съгласно настоящото правило, известява другите органи по одобряването относно предоставеното одобрение. В рамките на 14 дни след предоставянето на одобрението органът по одобряването качва в DETA на английски език одобрението на типа, заедно с допълнителната документация. (6)

5.3.7.

Договарящите се страни по Спогодбата може да разгледат предоставените одобрения на основата на информацията, качена съгласно точка 5.3.6. В случай на различие в мненията между договарящите се страни по Спогодбата, това се разрешава в съответствие с член 10 и списък 6 от Спогодбата от 1958 г. Договарящите се страни по Спогодбата също така информират съответната помощна работна група към Световния форум за хармонизация на регулаторната уредба за превозните средства (WP.29) относно различаващите се тълкувания по смисъла на списък 6 от Спогодбата от 1958 г. Съответната работна група съдейства за разрешаването на различията в мненията и може да се консултира с WP.29 относно това, ако е необходимо.

5.4.

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

6. Сертификат за съответствие за система за управление на киберсигурността

6.1.

Договарящите се страни определят орган по одобряването, който да извърши оценката на производителя и да издаде сертификат за съответствие за системата за управление на киберсигурността.

6.2.

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

6.3.

Към заявлението се прилагат посочените по-долу документи в три екземпляра и следните сведения:

6.3.1.

Документи, в които е описана системата за управление на киберсигурността.

6.3.2.

Подписана декларация въз основа на образеца, определен в допълнение 1 към приложение 1.

6.4.

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

6.5.

Когато тази оценка е била завършена по задоволителен начин и при получаване на подписана декларация на производителя съгласно образеца, определен в допълнение 1 към приложение 1, на производителя се предоставя сертификат, озаглавен Сертификат за съответствие за система за управление на киберсигурността, както е определен в приложение 4 към настоящото правило (наричан по-долу „сертификата за съответствие за система за управление на киберсигурността“).

6.6.

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

6.7.

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

6.8.

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

6.9.

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

6.10.

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

6.11.

Изтичането на срока или отнемането на сертификата за съответствие за система за управление на киберсигурността на производителя се счита, по отношение на типовете превозно средство, за които се отнася съответната система за управление на киберсигурността, като изменение на одобрението, както е посочено в точка 8, което може да включва отнемане на одобрението, ако условията за предоставянето на одобрението вече не са спазени.

7. Спецификации

7.1.

Общи спецификации

7.1.1.

Изискванията на настоящото правило не ограничават разпоредбите или изискванията на други правила на ООН.

7.2.

Изисквания за системата за управление на киберсигурността

7.2.1.

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

7.2.2.

Системата за управление на киберсигурността обхваща следните аспекти:

7.2.2.1.

Производителят на превозното средство доказва пред органа по одобряването или техническата служба, че системата за управление на киберсигурността се прилага за следните фази:

а)	Развойна фаза;

б)	Производствена фаза;

в)	Следпроизводствена фаза:

7.2.2.2.

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

а)	Процедурите, използвани в организацията на производителя, за да се управлява киберсигурността;

б)	Процедурите, използвани, за да се определят рисковете за типовете превозни средства. В рамките на тези процедури се вземат предвид заплахите, посочени в приложение 5, част А, и съответните други заплахи;

в)	Процедурите, използвани за оценка, категоризация и третиране на набелязаните рискове;

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

д)	Процедурите, използвани за изпитване на киберсигурността на даден тип превозно средство.

е)	Процедурите, използвани, за да се гарантира, че оценката на риска остава актуална;

ж)

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

з)	Процедурите, използвани за осигуряването на надеждни данни, за да се подкрепят анализите на опитите или успешните кибератаки.

7.2.2.3.

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

7.2.2.4.

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

а)	Превозни средства след първата им регистрация в мониторинга;

б)

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

7.2.2.5.

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

7.3.

Изисквания за типове превозни средства

7.3.1.

Производителят на превозното средство трябва да разполага с валиден сертификат за съответствие за системата за управление на киберсигурността, приложима за типа превозно средство, който е обект на одобряването. Въпреки това, за одобренията на типа на превозни средства от категории M, N и O, издадени първоначално преди 1 юли 2024 г., и за одобренията на типа на превозни средства от категория L, първоначално издадени преди 1 юли 2029 г., както и за всяко тяхно разширение, ако производителят на превозното средство може да докаже, че не е възможно типът превозно средство да бъде разработен в съответствие със системата за управление на киберсигурността, тогава производителят на превозното средство трябва да докаже, че киберсигурността е била взета предвид в достатъчна степен по време на развойната фаза на съответния тип превозно средство.

7.3.2.

Производителят на превозното средство открива и управлява свързаните с доставчици рискове за типа превозно средство, обект на одобрението.

7.3.3.

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

7.3.4.

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

По-специално, за одобренията на типа на превозни средства от категории M, N и O, първоначално издадени преди 1 юли 2024 г., и за одобренията на типа на превозни средства от категория L, първоначално издадени преди 1 юли 2029 г., и за всяко тяхно разширение, производителят на превозното средство гарантира, че се прилага друго подходящо смекчаване, ако е технически неосъществима мярка за смекчаване, посочена в приложение 5, част Б или В. Производителят представя на органа по одобряването съответната оценка на техническата приложимост.

7.3.5.

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

7.3.6.

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

7.3.7.

Производителят на превозното средство въвежда мерки за типа превозно средство с цел:

а)	да се откриват и предотвратяват кибератаките срещу превозните средства от този тип;

б)	да се подкрепя способността на производителя на превозното средство за наблюдение по отношение на откриването на заплахи, уязвимости и кибератаки, свързани с типа превозно средство;

в)	да се осигури възможност за събиране на криминалистични данни, за да се позволи анализ на опитите или успешните кибератаки.

7.3.8.

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

7.4.

Разпоредби за докладване

7.4.1.

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

7.4.2.

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

Ако докладването или отговорът не са достатъчни, органът по одобряването може да реши да отнеме сертификата за съответствие за системата за управление на киберсигурността в съответствие с точка 6.8.

8. Изменение на типа превозно средство и разширяване на одобрението на типа

8.1.

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

8.1.1.

Да прецени, че направените изменения все още отговарят на изискванията и документацията за съществуващото одобрение на типа; или

8.1.2.

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

8.1.3.

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

9. Съответствие на производството

9.1.

Процедурите за съответствие на производството трябва да съответстват на указаните в Спогодбата от 1958 г., приложение 1 (E/ECE/TRANS/505/Rev.3), при следните изисквания:

9.1.1.

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

9.1.2.

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

10. Санкции при несъответствие на производството

10.1.

Одобрението, издадено по отношение на тип превозно средство съгласно настоящото правило, може да бъде отнето, ако не е спазено изискването, определено в настоящото правило, или образци на превозното средство не съответстват на изискванията от настоящото правило.

10.2.

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

11. Окончателно прекратяване на производството

11.1.

Ако притежателят на одобрение прекрати напълно производството на типа превозно средство, одобрено съгласно настоящото правило, той трябва да уведоми за това органа, издал одобрението. При получаването на съответното съобщение този орган на свой ред уведомява за това останалите страни по Спогодбата, прилагащи настоящото правило, посредством копие на формуляра за одобрение, съдържащо най-долу следните думи, изписани с едър шрифт, подписано и с поставена дата: „ПРЕКРАТЕНО ПРОИЗВОДСТВО“.

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

12.1.

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

(1) Напр. ISO 26262-2018, ISO/PAS 21448, ISO/SAE 21434.

(2) https://www.unece.org/trans/main/wp29/datasharing.html.

(3) Насоки относно подробната информация (напр. метод, критерии, ниво на ефективност), която трябва да бъде качена, и нейният формат се предоставят в тълкувателния документ, който понастоящем се изготвя от оперативната група по киберсигурността и безжичните комуникации за седмото заседание на GRVA.

(4) Работна група по автоматизираните/автономните и свързаните превозни средства (GRVA).

(5) Това тълкуване се отразява в тълкувателния документ, посочен в бележката под линия към точка 5.3.3.

(6) Допълнителна информация относно минималните изисквания за комплекта документи ще бъде изготвена от GRVA по време на седмото ѝ заседание.

ПРИЛОЖЕНИЕ 5

Списък на заплахите и съответните мерки за смекчаване

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

Част А, част Б и част В се вземат предвид с оглед на оценката на риска и мерките за смекчаване, които се прилагат от производителите на превозни средства.

Уязвимостите на високо равнище и съответните примери за тях са индексирани в част A. Същото индексиране е използвано в таблиците в части Б и В, за да бъдат свързани всички атаки/уязвимости със списък на съответните мерки за смекчаване.

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

а)	Безопасната експлоатация на превозното средство е засегната.

б)	Функции на превозното средство спират да работят;

в)	Изменения на софтуера, промяна в показателите;

г)	Софтуерът е изменен, но няма въздействие върху работата;

д)	Нарушение на цялостността (валидността) на данните;

е)	Нарушение на поверителността на данните;

ж)	Загуба на наличността на данните;

з)	Други, включително престъпления.

ЧАСТ А

Уязвимост или метод на атака, свързани със заплахите

Описания на високо равнище на заплахите и съответните уязвимости или методи на атака са изброени в таблица А1.

Таблица A1

Списък на уязвимостите или методите на атака, свързани със заплахите

Описание на високо равнище и подравнища на уязвимостите/заплахите

Пример за уязвимост или метод на атака

4.3.1.

Заплахи, свързани с сървъри за данни и функционална логика, по отношение на превозни средства в експлоатация

Сървъри за данни и функционална логика, използвани като средство за атакуване на превозно средство или за извличане на данни

1.1

Злоупотреби с привилегии от страна на персонала (атака от вътрешно лице)

1.2

Неупълномощен достъп чрез интернет до сървъра (което е било възможно например посредством задни вратички, некоригирани уязвимости на системния софтуер, атаки SQL или други средства)

1.3

Неупълномощен физически достъп до сървъра (извършен например чрез запаметяващо устройство с флашпамет и интерфейс USB или друг носител, свързан към сървъра)

Услугите от сървъра за данни и функционална логика са нарушени, което въздейства на функционирането на превозното средство

2.1

Атака срещу сървъра за данни и функционална логика прекратява неговото функциониране — например възпрепятства го да взаимодейства с превозни средства и да предоставя услуги, които са им необходими

Данни, свързани с превозното средство и съхранявани на сървъри за данни и функционална логика, са загубени или компрометирани („нарушение на сигурността на данните“)

3.1

Злоупотреби с привилегии от страна на персонала (атака от вътрешно лице)

3.2

Загуба на информация в изчислителния облак. Когато данните се съхраняват от доставчици на компютърни услуги „в облак“ трети страни, чувствителни данни може да бъдат загубени поради атаки или инциденти

3.3

3.4

3.5

Нарушение на сигурността на информацията поради неумишлено споделяне на данни (напр. грешки на администратор)

4.3.2

Заплахи за превозните средства по отношение на техните комуникационни канали

Фалшифициране на съобщения или данни, получавани от превозното средство

4.1

Фалшифициране на съобщения чрез измама на основата на прилика (напр. V2X, съобщения за съвместно оповестяване или координиране на маневри, съобщения от ГНСС и т.н.)

4.2

Атака Sybil (с цел да бъдат имитирани други превозни средства, за да се създаде впечатление, че на пътя има много превозни средства)

Комуникационните канали се използват за извършването на неупълномощена манипулация, изтриване или други изменения на кода/данните, които се съхраняват в превозното средство

5.1

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

5.2

Комуникационните канали позволяват манипулиране на данни/код, съхранявани на превозното средство

5.3

Комуникационните канали позволяват презаписване на данни/код, съхранявани на превозното средство

5.4

Комуникационните канали позволяват изтриване на данни/код, съхранявани на превозното средство

5.5

Комуникационните канали позволяват въвеждането на данни/код в превозното средство (запис на код от данни)

Комуникационните канали позволяват да бъдат приети ненадеждни съобщения или са уязвими към отвличане на сесията/атаки с повторно възпроизвеждане

6.1

Приемане на информация от ненадежден източник

6.2

Атака тип „посредник“/отвличане на сесията

6.3

Атака с повторно възпроизвеждане например атака срещу комуникационен шлюз позволява на атакуващият да върне по-старата версия на софтуера на електронен блок за управление или на софтуера на производителя на шлюза

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

7.1

Прихващане на информация / смущаващи електромагнитни излъчвания / следене на комуникациите

7.2

Получаване на неупълномощен достъп до файлове или данни

Атаки за отказ на услуга чрез комуникационните канали с цел да бъдат възпрепятствани функциите на превозното средство

8.1

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

8.2

Атака тип „черна дупка“ — с цел да бъде нарушена комуникацията между превозните средства, атакуващият успява да блокира съобщенията между превозните средства

Потребител без привилегии успява да получи привилегирован достъп до системите на превозното средство

9.1

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

Вируси, вградени в комуникационно устройство, може да инфектират системите на превозното средство

10.1

Вирус, вграден в комуникационно устройство, инфектира системите на превозното средство

Съобщения, получени от превозното средство (например X2V или съобщения за диагностика) или предавани в рамките на системите му, съдържат зловредно съдържание

11.1

Зловредни вътрешни (напр. CAN) съобщения

11.2

Зловредни съобщения V2X, напр. инфраструктура към превозно средство или съобщения между превозни средства (напр. CAM, DENM)

11.3

Зловредни съобщения за диагностика

11.4

Зловредни съобщения, обект на интелектуална собственост (напр. обичайно изпращаните от производител на оригинално оборудване или доставчик на компонент/система/функция)

4.3.3.

Заплахи за превозните средства по отношение на техните процедури за актуализиране

Злоупотреба или компрометиране на процедури за актуализиране

12.1

Компрометиране на предавани по ефира процедури за актуализиране на софтуера. Това включва фалшифициране на програмата или софтуера на производителя за актуализиране на системата

12.2

Компрометиране на локални/физически процедури за актуализиране на софтуера. Това включва фалшифициране на програмата или софтуера на производителя за актуализиране на системата

12.3

Софтуерът се подправя преди процеса на актуализиране (и следователно е компрометиран), макар че процесът на актуализиране не е засегнат

12.4

Компрометиране на криптографски ключове на доставчика на софтуер, за да се осигури възможност за невалидно актуализиране

Възможно е да бъдат възпрепятствани официални актуализации

13.1

Атака тип „отказ на услуга“ срещу сървър или мрежа за актуализиране с цел да се възпрепятства внедряването на актуализации на софтуера от критично значение и/или отключването на специфични за потребителя функции

4.3.4.

Заплахи за превозни средства, свързани с неумишлени човешки действия, които улесняват извършването на кибератака

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

15.1

Невинна жертва (напр. собственик, оператор или инженер по поддръжката) е измамена да предприеме действие, така че непреднамерено да зареди зловреден софтуер или да осигури възможност за атака

15.2

Определените процедури за сигурност не се спазват

4.3.5.

Заплахи за превозните средства, свързани с техните външни връзки

Манипулиране на връзките на функциите на превозното средство осигурява възможност за кибератака — това може да включва телематика, системи, които позволяват операции от разстояние, и системи, които използват безжични връзки с малък обсег

16.1

Манипулиране на функции, предназначени за дистанционно управление на системи, като например ключове, имобилайзери и колони за зареждане

16.2

Манипулиране на телематиката на превозното средство (напр. манипулиране на измерването на температурата на чувствителни стоки, дистанционно отключване на вратите на товарните отделения)

16.3

Смущаване на безжични връзки или датчици с малък обсег

Софтуер на трета страна, ползващ хостинг, напр. развлекателни приложения, използвани като средство, за да се атакуват системите на превозното средство

17.1

Компрометирани приложения или приложения с ниско ниво на сигурност на софтуера, използвани като метод за атакуване на системите на превозното средство

Устройства, свързани с външни интерфейси, напр. портове USB, порт OBD, използвани като средство за атакуване на системите на превозното средство

18.1

Външни интерфейси като например USB или други портове, използвани като точка на атака — например чрез инжектиране на код

18.2

Носител, който е заразен с вирус, е свързан със система на превозното средство

18.3

Достъп за диагностика (напр. хардуерен ключ в порт OBD), използван за осигуряване на възможност за атака, напр. манипулиране на параметрите на превозното средство (пряко или непряко)

4.3.6.

Заплахи за данните/кода на превозното средство

Извличане на данни/код на превозното средство

19.1

Извличане на защитен от авторско право или лицензиран софтуер от системите на превозното средство (пиратиране на продукт)

19.2

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

19.3

Извличане на криптографски ключове

Манипулиране на данни/код на превозното средство

20.1

Незаконни/неупълномощени промени на електронния идентификатор на превозното средство

20.2

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

20.3

Действия за заобикаляне на системите за наблюдение (напр. хакерство/ подправяне/ блокиране на съобщения, като например данни от ODR Tracker, или брой изпълнения)

20.4

Манипулиране на данни с цел да се фалшифицират данните на превозното средство (напр. пробег, скорост на движение, посока на движение и т.н.)

20.5

Неупълномощени промени на данните за диагностика на системата

Изтриване на данни/код

21.1

Неупълномощено изтриване/манипулиране на регистъра на събитията на системата

Въвеждане на зловреден софтуер

22.2

Въвеждане на зловреден софтуер или активност на зловреден софтуер

Въвеждане на нов софтуер или презаписване на съществуващ софтуер

23.1

Фалшифициране на софтуер на системата за управление на превозното средство или на информационната система

Смущение на системи или операции

24.1

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

Манипулиране на параметрите на превозното средство

25.1

Неупълномощен достъп с цел фалшифициране на конфигурационните параметри на ключови функции на превозното средство, като например данни за спирачките, праг за разгънатата въздушна възглавница и т.н.

25.2

Неупълномощен достъп с цел фалшифициране на параметрите за зареждане, като напрежение на зареждане, мощност на зареждане, температура на акумулатора и т.н.

4.3.7.

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

Криптографските технологии може да бъдат компрометирани или не са приложени в достатъчна степен

26.1

Комбинация от къси криптографски ключове и дълъг период на валидност позволява на атакуващия да дешифрира криптирането

26.2

Недостатъчно използване на криптографски алгоритми, за да бъдат защитени чувствителните системи

26.3

Използване на отхвърлени и подлежащи на отхвърляне криптографски алгоритми

Част или доставки може да бъдат компрометирани, за да се осигури възможност за атакуване на превозни средства

27.1

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

Уязвимости, възникнали при разработването на програмната или апаратната част

28.1

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

28.2

Използването на остатъци от разработването (напр. портове за отстраняване на грешки, портове JTAG, микропроцесори, сертификати за разработване, пароли на разработчици... ) може да осигури достъп до електронния блок за управление или да позволи на атакуващите да получат по-високи привилегии

Структурата на мрежата представя уязвимости

29.1

Излишни интернет портове са оставени отворени, като предоставят достъп до мрежовите системи

29.2

Заобикаляне на мрежовото разделяне, за да бъде получен контрол. Конкретен пример е използването на незащитени шлюзове или точки за достъп (като например шлюзове между камион и ремарке), за да бъдат заобиколени защитите и да бъде получен достъп до други мрежови сегменти с цел да бъдат извършени злонамерени действия, като например изпращане на произволни съобщения чрез шината CAN

Може да възникне непредвидено предаване на данни

31.1

Компрометиране на информация. Може да има изтичане на лични данни при смяна на потребителя на лекия автомобил (напр. продажба или използване като наето превозно средство с нови наематели)

Физическо манипулиране на системите може да осигури възможност за атака

32.1

Манипулиране на електронна апаратна част, напр. неодобрена електронна апаратна част се добавя към превозно средство с цел да се осигури възможност за атака тип „посредник“

Замяна на одобрена електронна апаратна част (напр. датчици) с неодобрена електронна апаратна част

Манипулиране на информацията, събирана от датчик (например използване на магнит с цел да бъде нарушено функционирането на датчика на Хол, свързан с предавателната кутия)

ЧАСТ Б

Мерки за смекчаване на заплахите, насочени към превозни средства

Мерки за смекчаване, свързани с комуникационните канали на превозните средства

Мерките за смекчаване на заплахите, свързани с комуникационните канали на превозните средства, са изброени в таблица Б1.

Таблица Б1

Мерки за смекчаване на заплахите, свързани с комуникационните канали на превозните средства

Справка с таблица А1	Заплахи, свързани с комуникационните канали на превозните средства	Спр.	Смекчаване
4.1	Фалшифициране на съобщения (напр. V2X, съобщения за съвместно оповестяване или координиране на маневри, съобщения от ГНСС и т.н.)	M10	Превозното средство проверява автентичността и валидността (цялостността) на съобщенията, които получава
4.2	Атака Sybil (с цел да бъдат имитирани други превозни средства, за да се създаде впечатление, че на пътя има много превозни средства)	M11	Трябва да бъдат въведени контролни механизми за сигурност за съхранение на криптографските ключове (напр. използване на хардуерни модули за сигурност)
5.1	Комуникационните канали позволяват инжектиране на код в данните/кода на превозното средство, например подправени двоични софтуерни данни може да бъдат инжектирани в комуникационния поток	M10 M6	Превозното средство проверява автентичността и валидността (цялостността) на съобщенията, които получава В системите трябва да бъде въведена сигурност още при разработването, за да бъдат сведени до минимум рисковете
5.2	Комуникационните канали позволяват манипулиране на данни/код, съхранявани на превозното средство	M7	Трябва да бъдат приложени техники и разработки за контрол на достъпа с цел да бъдат защитени данните/кодът на системите
5.3	Комуникационните канали позволяват презаписване на данни/код, съхранявани на превозното средство
5.4 21.1	Комуникационните канали позволяват изтриване на данни/код, съхранявани на превозното средство
5.5	Комуникационните канали позволяват въвеждането на данни/код в системите на превозното средство (запис на код от данни)
6.1	Приемане на информация от ненадежден източник	M10	Превозното средство проверява автентичността и валидността (цялостността) на съобщенията, които получава
6.2	Атака тип „посредник“/отвличане на сесията	M10	Превозното средство проверява автентичността и валидността (цялостността) на съобщенията, които получава
6.3	Атака с повторно възпроизвеждане например атака срещу комуникационен шлюз позволява на атакуващият да върне по-старата версия на софтуера на електронен блок за управление или на софтуера на производителя на шлюза	M10
7.1	Прихващане на информация / смущаващи електромагнитни излъчвания / следене на комуникациите	M12	Трябва да бъдат защитени поверителните данни, предавани към или от превозното средство
7.2	Получаване на неупълномощен достъп до файлове или данни	M8	Структурата на системата и контролът на достъпа не трябва да позволяват неупълномощен персонал да получава достъп до лични данни или данни от критично значение за системата. Примери за контрол на сигурността може да бъдат открити в OWASP
8.1	Изпращане на голям брой произволни данни към информационната система на превозното средство, така че да не може да предоставя услуги както при нормални условия	M13	Трябва да бъдат въведени мерки за откриване и възстановяване след компютърна атака тип „отказ на услуга“
8.2	Атака тип „черна дупка“ — нарушаване на комуникацията между превозните средства чрез блокиране на предаването на съобщения към други превозни средства	M13	Трябва да бъдат въведени мерки за откриване и възстановяване след компютърна атака тип „отказ на услуга“
9.1	Потребител без привилегии успява да получи привилегирован достъп, например достъп до кореновата файлова система	M9	Трябва да бъдат въведени мерки, за да се предотвратява и открива неупълномощеният достъп
10.1	Вирус, вграден в комуникационно устройство, инфектира системите на превозното средство	M14	Следва да бъде обмислено въвеждането на мерки, за да бъдат защитени системите срещу вградени вируси/зловреден софтуер
11.1	Зловредни вътрешни (напр. CAN) съобщения	M15	Следва да бъде обмислено въвеждането на мерки, за откриването на зловредни вътрешни съобщения или активност
11.2	Зловредни съобщения V2X, напр. инфраструктура към превозно средство или съобщения между превозни средства (напр. CAM, DENM)	M10	Превозното средство проверява автентичността и валидността (цялостността) на съобщенията, които получава
11.3	Зловредни съобщения за диагностика
11.4	Зловредни съобщения, обект на интелектуална собственост (напр. обичайно изпращаните от производител на оригинално оборудване или доставчик на компонент/система/функция)

Мерки за смекчаване, свързани с процеса на актуализиране

Мерките за смекчаване на заплахите, свързани с процеса на актуализиране, са изброени в таблица Б2.

Таблица Б2

Мерки за смекчаване на заплахите, свързани с процеса на актуализиране

Справка с таблица А1	Заплахи, свързани с процеса на актуализиране	Спр.	Смекчаване
12.1	Компрометиране на предавани по ефира процедури за актуализиране на софтуера. Това включва фалшифициране на програмата или софтуера на производителя за актуализиране на системата	M16	Трябва да бъдат въведени сигурни процедури за актуализиране на софтуера
12.2	Компрометиране на локални/физически процедури за актуализиране на софтуера. Това включва фалшифициране на програмата или софтуера на производителя за актуализиране на системата
12.3	Софтуерът се подправя преди процеса на актуализиране (и следователно е компрометиран), макар че процесът на актуализиране не е засегнат
12.4	Компрометиране на криптографски ключове на доставчика на софтуер, за да се осигури възможност за невалидно актуализиране	M11	Трябва да бъде въведен контрол на сигурността по отношение на съхранението на криптографските ключове
13.1	Атака тип „отказ на услуга“ срещу сървър или мрежа за актуализиране с цел да се възпрепятства внедряването на актуализации на софтуера от критично значение и/или отключването на специфични за потребителя функции	M3	Трябва да бъде въведен контрол на сигурността по отношение на системите за данни и функционална логика. Когато сървъри за данни и функционална логика са от критично значение за осигуряването на услуги, съществуват мерки за възстановяване в случай на изключване на системата. Примери за контрол на сигурността може да бъдат открити в OWASP.

Мерки за смекчаване, свързани с неумишлени човешки действия, които улесняват извършването на кибератака

Мерките за смекчаване на заплахите, свързани с неумишлени човешки действия, които улесняват извършването на кибератака, са изброени в таблица Б3.

Таблица Б3

Мерки за смекчаване на заплахите, свързани с неумишлени човешки действия, които улесняват извършването на кибератака

Справка с таблица А1	Заплахи, свързани с неумишлени човешки действия	Спр.	Смекчаване
15.1	Невинна жертва (напр. собственик, оператор или инженер по поддръжката) е измамена да предприеме действие, така че непреднамерено да зареди зловреден софтуер или да осигури възможност за атака	M18	Трябва да бъдат въведени мерки за определяне и управляване на потребителските роли и привилегиите за достъп на основата на принципа за най-малко привилегии за достъп
15.2	Определените процедури за сигурност не се спазват	M19	Организациите трябва да гарантират, че са определени процедури за сигурност и че те се спазват, включително регистриране на действията и достъпа, свързани с управлението на функциите за сигурност

Мерки за смекчаване, свързани с външните връзки

Мерките за смекчаване на заплахите, свързани с външните връзки, са изброени в таблица Б4.

Таблица Б4

Мерки за смекчаване на заплахите, свързани с външните връзки

Справка с таблица А1	Заплахи, свързани с външните връзки	Спр.	Смекчаване
16.1	Манипулиране на функции, предназначени за дистанционно управление на системи на превозното средство, като например ключове, имобилайзери и колони за зареждане	M20	Трябва да бъде въведен контрол по отношение на системите, които разполагат с дистанционен достъп
16.2	Манипулиране на телематиката на превозното средство (напр. манипулиране на измерването на температурата на чувствителни стоки, дистанционно отключване на вратите на товарните отделения)
16.3	Смущаване на безжични връзки или датчици с малък обсег
17.1	Компрометирани приложения или приложения с ниско ниво на сигурност на софтуера, използвани като метод за атакуване на системите на превозното средство	M21	Трябва да се извърши оценка на сигурността на софтуера, да се удостовери неговата автентичност и да се защити цялостността му. Трябва да бъде въведен контрол на сигурността, за да се сведе до минимум рискът от софтуер от трета страна, който е предназначен или за който има вероятност да използва хостинг на превозното средство
18.1	Външни интерфейси като например USB или други портове, използвани като точка на атака — например чрез инжектиране на код	M22	Трябва да бъде въведен контрол на сигурността по отношение на външните интерфейси
18.2	Носител, който е заразен с вируси, е свързан към превозното средство	M22
18.3	Достъп за диагностика (напр. хардуерен ключ в порт OBD), използван за осигуряване на възможност за атака, напр. манипулиране на параметрите на превозното средство (пряко или непряко)	M22	Трябва да бъде въведен контрол на сигурността по отношение на външните интерфейси

Мерки за смекчаване, свързани с потенциалните цели или мотиви за компютърна атака

Мерките за смекчаване на заплахите, свързани с потенциалните цели или мотиви за компютърна атака, са изброени в таблица Б5.

Таблица Б5

Мерки за смекчаване на заплахите, свързани с потенциалните цели или мотиви за компютърна атака

Справка с таблица А1	Заплахи, свързани с потенциалните цели или мотиви за компютърна атака	Спр.	Смекчаване
19.1	Извличане на защитен от авторско право или лицензиран софтуер от системите на превозното средство (пиратиране на продукт / кражба на софтуер)	M7	Трябва да бъдат приложени техники и разработки за контрол на достъпа с цел да бъдат защитени данните/кодът на системите. Примери за контрол на сигурността може да бъдат открити в OWASP.
19.2	Неупълномощен достъп до поверителна информация на собственика, като например самоличност, информация за платежна сметка, информация от адресния указател, информация относно местоположението, електронен идентификатор на превозното средство и т.н.	M8	Структурата на системата и контролът на достъпа не трябва да позволяват неупълномощен персонал да получава достъп до лични данни или данни от критично значение за системата. Примери за контрол на сигурността може да бъдат открити в OWASP
19.3	Извличане на криптографски ключове	M11	Трябва да бъдат въведени контролни механизми за сигурност за съхранение на криптографските ключове, напр. модули за сигурност
20.1	Незаконни/неупълномощени промени на електронния идентификатор на превозното средство	M7	Трябва да бъдат приложени техники и разработки за контрол на достъпа с цел да бъдат защитени данните/кодът на системите. Примери за контрол на сигурността може да бъдат открити в OWASP.
20.2	Използване на фалшива самоличност. Например, ако даден потребител иска да покаже друга самоличност, когато осъществява комуникация със системите за таксуване, сървъра за данни и функционална логика на производителя	M7
20.3	Действия за заобикаляне на системите за наблюдение (напр. хакерство/ подправяне/ блокиране на съобщения, като например данни от ODR Tracker, или брой изпълнения)	M7	Трябва да бъдат приложени техники и разработки за контрол на достъпа с цел да бъдат защитени данните/кодът на системите. Примери за контрол на сигурността може да бъдат открити в OWASP. Компютърните атаки, свързани с манипулиране на данни от датчици или предавани данни, може да бъдат смекчени чрез съпоставяне на данните от различни източници на информация
20.4	Манипулиране на данни с цел да се фалшифицират данните на превозното средство (напр. пробег, скорост на движение, посока на движение и т.н.)
20.5	Неупълномощени промени на данните за диагностика на системата
21.1	Неупълномощено изтриване/манипулиране на регистъра на събитията на системата	M7	Трябва да бъдат приложени техники и разработки за контрол на достъпа с цел да бъдат защитени данните/кодът на системите. Примери за контрол на сигурността може да бъдат открити в OWASP.
22.2	Въвеждане на зловреден софтуер или активност на зловреден софтуер	M7	Трябва да бъдат приложени техники и разработки за контрол на достъпа с цел да бъдат защитени данните/кодът на системите. Примери за контрол на сигурността може да бъдат открити в OWASP.
23.1	Фалшифициране на софтуер на системата за управление на превозното средство или на информационната система	M7
24.1	Отказ на услуги, например това може да бъде предизвикано във вътрешната мрежа чрез лавинна маршрутизация по шина CAN или като бъдат причинени грешки в електронен блок за управление чрез голям брой изпратени съобщения	M13	Трябва да бъдат въведени мерки за откриване и възстановяване след компютърна атака тип „отказ на услуга“
25.1	Неупълномощен достъп с цел фалшифициране на конфигурационните параметри на ключови функции на превозното средство, като например данни за спирачките, праг за разгънатата въздушна възглавница и т.н.	M7	Трябва да бъдат приложени техники и разработки за контрол на достъпа с цел да бъдат защитени данните/кодът на системите. Примери за контрол на сигурността може да бъдат открити в OWASP.
25.2	Неупълномощен достъп с цел фалшифициране на параметрите за зареждане, като например напрежение на зареждане, мощност на зареждане, температура на акумулатора и т.н.	M7

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

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

Таблица Б6

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

Справка с таблица А1	Заплахи, свързани с потенциалните уязвимости, които може да бъдат използвани за атака, ако не са защитени в достатъчна степен	Спр.	Смекчаване
26.1	Комбинация от къси криптографски ключове и дълъг период на валидност позволява на атакуващия да дешифрира криптирането	M23	Трябва да бъдат спазвани най-добрите практики в областта на киберсигурността за разработването на апаратна или програмна част
26.2	Недостатъчно използване на криптографски алгоритми, за да бъдат защитени чувствителните системи
26.3	Използване на отхвърлени криптографски алгоритми
27.1	Апаратна или програмна част, която е разработена, така че да осигури възможност за атака или не отговаря на проектните критерии за предотвратяване на атаки	M23	Трябва да бъдат спазвани най-добрите практики в областта на киберсигурността за разработването на апаратна или програмна част
28.1	Наличието на софтуерни грешки може да бъде основа за потенциални уязвимости, осигуряващи възможност за атака. Това важи особено, ако софтуерът не е бил изпитан, за да се потвърди, че не е налице известен неправилен код/грешки, и да се намали рискът от наличие на неизвестен неправилен код/грешки	M23	Трябва да бъдат спазвани най-добрите практики в областта на киберсигурността за разработването на апаратна или програмна част. Изпитване на киберсигурността с подходящ обхват
28.2	Използването на остатъци от разработването (напр. портове за отстраняване на грешки, портове JTAG, микропроцесори, сертификати за разработване, пароли на разработчици... ) може да позволи на атакуващия да получи достъп до електронния блок за управление или до по-високи привилегии
29.1	Излишни интернет портове са оставени отворени, като предоставят достъп до мрежовите системи
29.2	Заобикаляне на мрежовото разделяне, за да бъде получен контрол. Конкретен пример е използването на незащитени шлюзове или точки за достъп (като например шлюзове между камион и ремарке), за да бъдат заобиколени защитите и да бъде получен достъп до други мрежови сегменти с цел да бъдат извършени злонамерени действия, като например изпращане на произволни съобщения чрез шината CAN	M23	Трябва да бъдат спазвани най-добрите практики в областта на киберсигурността за разработването на апаратна или програмна част. Трябва да бъдат спазвани най-добрите практики в областта на киберсигурността за проектирането на системите и за системната интеграция.

Мерки за смекчаване, свързани със загуба на данни/компрометиране на данните от превозното средство

Мерките за смекчаване на заплахите, свързани със загуба на данни/компрометиране на данните от превозното средство, са изброени в таблица Б7.

Таблица Б7

Мерки за смекчаване на заплахите, свързани със загуба на данни/компрометиране на данните от превозното средство

Справка с таблица А1	Заплахи, свързани със загуба на данни/компрометиране на данните от превозното средство	Спр.	Смекчаване
31.1	Компрометиране на информация. Може да има изтичане на лични данни при смяна на потребителя на колата (напр. продажба или използване като наето превозно средство с нови наематели)	M24	По отношение на съхраняването на лични данни трябва да се спазват най-добрите практики за защита на валидността (цялостността) и поверителността на данните.

Мерки за смекчаване, свързани с физическо манипулиране на системите, което може да осигури възможност за атака

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

Таблица Б8

Мерки за смекчаване на заплахите, свързани с физическо манипулиране на системите, което може да осигури възможност за атака

Справка с таблица А1	Заплахи, свързани с физическо манипулиране на системите, което може да осигури възможност за атака	Спр.	Смекчаване
32.1	Манипулиране на апаратната част на производител на оригинално оборудване, напр. неразрешена апаратна част се добавя към превозно средство с цел да се осигури възможност за атака тип „посредник“	M9	Трябва да бъдат въведени мерки, за да се предотвратява и открива неупълномощеният достъп

ЧАСТ В

Мерки за смекчаване на заплахите извън превозните средства

Мерки за смекчаване, свързани със сървъри за данни и функционална логика

Мерките за смекчаване на заплахите, свързани със сървъри за данни и функционална логика, са изброени в таблица В1.

Таблица В1

Мерки за смекчаване на заплахите, свързани със сървъри за данни и функционална логика

Справка с таблица А1	Заплахи, свързани със сървъри за данни и функционална логика	Спр.	Смекчаване
1.1 & 3.1	Злоупотреби с привилегии от страна на персонала (атака от вътрешно лице)	M1	Въвежда се контрол на сигурността по отношение на системите за данни и функционална логика, за да се сведе до минимум рискът от атака от вътрешно лице
1.2 & 3.3	Неупълномощен достъп чрез интернет до сървъра (което е било възможно например посредством задни вратички, некоригирани уязвимости на системния софтуер, атаки SQL или други средства)	M2	Въвежда се контрол на сигурността по отношение на системите за данни и функционална логика, за да се сведе до минимум рискът от неупълномощен достъп. Примери за контрол на сигурността може да бъдат открити в OWASP.
1.3 & 3.4	Неупълномощен физически достъп до сървъра (извършен например чрез запаметяващо устройство с флашпамет и интерфейс USB или друг носител, свързан към сървъра)	M8	Структурата на системата и контролът на достъпа не трябва да позволяват неупълномощен персонал да получава достъп до лични данни или данни от критично значение за системата
2.1	Атака срещу сървъра за данни и функционална логика прекратява неговото функциониране — например възпрепятства го да взаимодейства с превозни средства и да предоставя услуги, които са им необходими	M3	Въвежда се контрол на сигурността по отношение на системите за данни и функционална логика. Когато сървъри за данни и функционална логика са от критично значение за осигуряването на услуги, съществуват мерки за възстановяване в случай на изключване на системата. Примери за контрол на сигурността може да бъдат открити в OWASP.
3.2	Загуба на информация в изчислителния облак. Когато данните се съхраняват от доставчици на компютърни услуги „в облак“ трети страни, чувствителни данни може да бъдат загубени поради атаки или инциденти	M4	Въвежда се контрол на сигурността, за да се сведат до минимум рисковете, свързани с изчисленията в облак. Примери за контрол на сигурността може да бъдат открити в OWASP и насоките на NCSC относно изчисленията в облак
3.5	Нарушение на сигурността на информацията поради неумишлено споделяне на данни (напр. грешки на администратор, съхраняване на данни на сървъри в гаражи)	M5	Въвежда се контрол на сигурността по отношение на системите за данни и функционална логика с цел да се предотврати компрометирането на данни. Примери за контрол на сигурността може да бъдат открити в OWASP.

Мерки за смекчаване, свързани с неумишлени човешки действия

Мерките за смекчаване на заплахите, свързани с неумишлени човешки действия, са изброени в таблица В2.

Таблица В2

Мерки за смекчаване на заплахите, свързани с неумишлени човешки действия

Справка с таблица А1	Заплахи, свързани с неумишлени човешки действия	Спр.	Смекчаване
15.1	Невинна жертва (напр. собственик, оператор или инженер по поддръжката) е измамена да предприеме действие, така че непреднамерено да зареди зловреден софтуер или да осигури възможност за атака	M18	Трябва да бъдат въведени мерки за определяне и управляване на потребителските роли и привилегиите за достъп на основата на принципа за най-малко привилегии за достъп
15.2	Определените процедури за сигурност не се спазват	M19	Организациите трябва да гарантират, че са определени процедури за сигурност и че те се спазват, включително регистриране на действията и достъпа, свързани с управлението на функциите за сигурност

Мерки за смекчаване, свързани с физическа загуба на данни

Мерките за смекчаване на заплахите, свързани с физическа загуба на данни, са изброени в таблица В3.

Таблица В3

Мерки за смекчаване на заплахите, свързани с физическа загуба на данни

Справка с таблица А1	Заплахи, свързани с физическа загуба на данни	Спр.	Смекчаване
30.1	Щети, причинени от трета страна. Чувствителни данни може да бъдат загубени или компрометирани поради физически щети в случай на пътнотранспортно произшествие или кражба	M24	По отношение на съхраняването на лични данни трябва да се спазват най-добрите практики за защита на валидността (цялостността) и поверителността на данните. Примери за контрол на сигурността може да бъдат открити в ISO/SC27/WG5
30.2	Загуби поради конфликти, свързани с цифровото управление на права (DRM). Поради проблеми, свързани с цифровото управление на права, може да бъдат изтрити потребителски данни
30.3	Чувствителни данни може да бъдат загубени или тяхната валидност (цялостност) да бъде нарушена поради износване на информационнотехнологични компоненти което да причини потенциални проблеми с каскаден ефект (в случай например на изменение на ключове)

Номер на протокола: …
	Сертификатът е валиден до [… дата]
	Съставено в … [място]
	На [… дата]
	[…подпис]