Когато доставчик на софтуер обяви уязвимост, производителят на машини трябва да отговори: „Кои от доставените от нас машини съдържат този компонент?“ Ако инженерингът, закупуването и сервизът трябва да реконструират отговора от отделни списъци, в техническите записи липсват полезни връзки.
Техническият файл на CRA трябва да обяснява дизайна за сигурност на доставения продукт и как този дизайн е проверен. Моделът, хардуерът, версията на софтуера, доказателствата от тестове и записите за поддръжка трябва да описват един и същ продукт. Когато клиентът получи различно издание, съответната документация трябва да го следва.
Определете точно продукта
Дефинирайте модела и поддържаните от него конфигурации. Включете контролер, HMI, индустриален компютър, локални приложения и отдалечени услуги, необходими за функциите на продукта. Покажете интерфейсите между тях. Направете видима границата между мрежата на клиента и достъпа до услугата на производителя.
Свържете модела към всяка доставена машина чрез нейния сериен номер, версия на хардуера, инсталирана версия на софтуера и запис за доставка. Записвайте и по-късни промени в услугата. „Този модел използва този софтуер“ и „този клиент има инсталирана тази версия“ отговарят на различни въпроси.
| Запис | Въпрос, на който трябва да се отговори |
|---|---|
| Дефиниция на продукта | Кои функции и конфигурации принадлежат на продукта? |
| Архитектура и потоци от данни | Кои компоненти комуникират, през какви интерфейси? |
| Оценка на риска за киберсигурността | Кое проектно решение е насочено към всеки идентифициран риск? |
| Инвентаризация на софтуерните компоненти | Кои версии на компоненти са включени в изданието? |
| Доказателства от проверките | Кое изискване е тествано, на коя настройка, с какъв резултат? |
| План за поддръжка и актуализация | Кой изготвя корекция и как тя достига до клиентите? |
Изискванията за техническа документация на CRA обхващат дизайна на продукта и оценката на съответствието. Тези работни записи помагат на екипите да поддържат връзките, необходими за обяснение на техния продукт.
Запишете какво доказва тестът за достъп
Твърдението „отдалеченият достъп работи“ не показва коя защитна мярка е проверена. Запишете версията, правата на потребителя, целевото приложение и очаквания резултат. Може ли сервизният инженер да отвори диагностичното приложение? Може ли същият потребител да достигне друг ресурс без разрешение? Какво се случва, след като клиентът отнеме правата на партньора?
Илюстративен запис за приемане може да гласи: "Групата за услуги отвори диагностичното приложение. Достъпът до приложението за управление на производството беше отказан. След премахване на разрешението на партньора, нов опит за отваряне на диагностика беше отказан." Прикачете конфигурацията, датата и резултата към съответната версия.
Проверете както разрешените, така и отказаните действия. Успешното влизане само по себе си не доказва, че ограниченията за достъп работят. При промяна на компонент за достъп определете кои тестове трябва да се повторят при прегледа на версията.
Пример: от уязвим компонент до актуализация при клиента
Да приемем, че доставчик съобщава за уязвимост в библиотека на диагностично приложение. Инженерният екип проверява списъка с компоненти на машинния софтуер 3.4. Сервизният отдел установява серийните номера на машините с тази версия. Така екипът работи с конкретен списък на засегнатите инсталации, без да кара клиентите да гадаят коя версия използват.
Разработчикът подготвя корекция. Отговорникът по сигурността оценява влиянието на уязвимостта върху продукта. Проверяват се корекцията, правилата за достъп и основните функции. Одобрението за публикуване, резултатите от тестовете и инструкциите за инсталиране трябва да се отнасят за една и съща коригирана версия.
Сервизният отдел уговаря инсталирането с клиентите и следи отделно завършените и предстоящите актуализации. Крайният запис трябва да свързва засегнатите машини с одобрената корекция и доставката ѝ до клиента. Наличието на нов пакет не е достатъчно. Отговорникът за уведомяване преценява дали има активно използвана уязвимост или сериозен инцидент по член 14. При необходимост започва съответната процедура за уведомяване.
Разграничете наличността на хардуер от поддръжката на сигурността
Orenda предлага 10-годишна наличност на хардуер за Orenda Box. Този ангажимент помага при планирането на подмяната и допълненията към инсталиран машинен парк. Периодът на поддръжка на сигурността за софтуер е отделно решение за продукта.
Съгласно CRA периодът на поддръжка трябва да отразява очакваното използване на продукта и обикновено е най-малко пет години, с изключение за продукти, за които се очаква да се използват за по-малко време. Една дълготрайна индустриална машина се нуждае от оценка на собствената си употреба; минимумът не е причина да спрете да планирате след пет години.
Посочете края на поддръжката в информацията за клиента. Помислете какво се случва, ако дадена софтуерна зависимост достигне края на поддръжката си преди машината. Съхранявайте решението, отговорния собственик и метода на актуализиране в документацията на продукта.
Ролята на Orenda в техническото досие
Orenda Box предоставя TPM корен на доверие и подписани издания за актуализация. Orenda Connect дава на упълномощени потребители криптиран достъп до избрани ресурси без портове за публична входяща услуга. Потребителите и групите в организацията предоставят дефинирана основа за решения за достъп.
Приложенията App Market използват споделена идентичност и контроли за достъп с разрешения, одобрени от администратора на Orenda Box. Разработчиците могат да включат тези контроли в дизайна на своите приложения. Производителят на машината може да запише внедрената версия, одобрените разрешения и тестваната сервизна връзка заедно с останалите доказателства за продукта.
По време на дискусия за архитектурата на CRA можем заедно да прегледаме системната ви диаграма, записите за издаване и метода на обслужване. Полезният резултат е ясен път от машината на мястото на клиента до нейните компоненти, доказателства от тестове и решения за поддръжка.
