Машинний переклад, не перевірений носієм мови. Еталоном є англійська версія.

Compliance і випробувальний стенд (bench)Редагувати на GitHubДжерело: docs/compliance/dhs-rpcf.md

Рамки відповідності стійкого PNT Міністерства внутрішньої безпеки США (DHS): для чого Kshana підтримує докази (supports evidence for)

Рамки описують рівні стійкості від 0 до 4, побудовані з восьми пронумерованих вимог, і підхід до оцінювання, що поєднує статичний аналіз із динамічним аналізом, у якому тестові вектори замінюють загрози. Власної схеми ідентифікаторів вимог вони не мають, тому наведені нижче посилання — це номери їхніх рівнів і вимог та номери розділів. Вони орієнтовані на результат і не каталогізують загрози.

Кожен рядок вказує, які вихідні дані Kshana підтримують докази для вимоги (supports evidence for) і що залишається поза ними. Ніщо тут не стверджує, що рамки виконано або що будь-який продукт кимось оцінений чи схвалений. Запустіть kshana compliance-report на власних файлах результатів, щоб побачити, які рядки ваші прогони справді підтверджують; див. README.md.

Вихідні документи#

Зіставлення#

Довідник Що вимагається (переказ) Вихідні дані Kshana, що підтримують докази для цього Прогалина
Розділ 5,2 (запобігання, реагування, відновлення) Стійкість описано як три функції: запобігання шкоді, реагування (виявити, повідомити, пом'якшити, стримати) і відновлення. Виявлення є ймовірнісним, тому важливі і хибні тривоги, і пропущені виявлення. Оцінка довіри за журналом приймача; Виявлення спуфінгу та meaconing; Holdover і вибіг Запобігання є властивістю проєктування продукту, яку не показує жоден вихід симуляції. Статистики виявлення із синтетичного або одноразового прогону не є виміряною частотою хибних тривог чи пропусків для продукту в експлуатації.
Рівень 1, вимога 1 Перевіряти, що збережені дані, які надходять із зовнішніх джерел, відповідають форматам і діапазонам значень відповідних стандартів. немає Властивість забезпечення якості програмного забезпечення та перевірки вхідних даних продукту, що випробовується. Kshana не перевіряє обробку вхідних даних продуктом.
Рівень 1, вимога 2 Дозволяти повне ручне відновлення очищенням або скиданням пам'яті, повертаючи систему до визначеної роботи, щойно загроза зникла. Оцінка довіри за журналом приймача Журнал приймача показує, коли фіксація перестала бути довіреною і коли вона відновилася; він не показує, що ручне скидання очищує кожен збережений стан.
Рівень 1, вимога 3 Безпечно перезавантажувати або оновлювати мікропрограму. немає Безпека оновлення мікропрограми лежить поза тим, що спостерігають вихідні дані Kshana.
Рівень 2, вимога 4 Ідентифікувати скомпрометовані джерела PNT і не допускати їхнього спотворення розв'язку. Виявлення спуфінгу та meaconing; Оцінка довіри за журналом приймача; Моніторинг цілісності та рівні захисту Kshana оцінює детектори та монітори, які моделює або запускає над журналом; чи працює власне виключення джерел у продукті, залежить від внутрішнього стану продукту, а не лише від його журналу.
Рівень 2, вимога 5 Відновлювати джерела та систему автоматично без переривання виходу; розв'язок надається і під час загрози, можливо з необмеженою деградацією. Holdover і вибіг; Оцінка довіри за журналом приймача Прогони holdover обмежують модельований дрейф для заданої моделі годинника чи інерційної системи, а не власну поведінку відновлення продукту.
Рівень 3, вимога 6 Спотворені дані з одного джерела не повинні забруднювати інше джерело. Альтернативні та різноманітні джерела PNT Kshana запускає джерела поруч; ізоляція джерел усередині продукту потребує перегляду проєкту або впровадження збоїв у продукт.
Рівень 3, вимога 7 Перехресно перевіряти розв'язки всіх джерел і тримати деградацію під час загрози в межах. Моніторинг цілісності та рівні захисту; Holdover і вибіг; Альтернативні та різноманітні джерела PNT Обмежену деградацію показано для модельованих датчиків; власну перехресну перевірку продукту не спостережено.
Рівень 4, вимога 8 Використовувати джерела різних технологій проти загроз спільного режиму, без деградації під час загрози. Альтернативні та різноманітні джерела PNT; Вплив бюджету лінії зв'язку за глушіння Аргумент спільного режиму потребує набору джерел реального продукту та загрози, що охоплює їх усі; сценарій її задає, але не доводить, що продукт не має спільної слабкості.
Розділ 5,5 (спільний режим) Різні механізми не повинні мати спільної слабкості: наприклад, глушник, що охоплює дві смуги, перемагає різноманітність смуг. Вплив бюджету лінії зв'язку за глушіння; Оцінювання стійкості за ансамблями загроз; Альтернативні та різноманітні джерела PNT Оцінювання використовує синтетичний ансамбль загроз, про що прямо сказано; це не польові дані.
Розділи 8,1–8,3 (оцінювання) Оцінювання поєднує статичний аналіз із динамічним аналізом, де тестові вектори замінюють загрози; класи тестів — відмова джерела, завади та внутрішні збої. Симулятори названо методом тестування. Оцінка довіри за журналом приймача; Вплив бюджету лінії зв'язку за глушіння; Виявлення спуфінгу та meaconing Експортовані рух і події можуть керувати лабораторним симулятором (docs/TEST-BENCH.md). Kshana не записує сигнал, тож загрозу забезпечують симулятор та його уповноважений оператор.
Розділ 8,6 (елементи плану тестування) План тестування вказує рівень, вимогу, вхідні дані, посилання, потрібний доступ до даних, процедуру з критеріями успіху чи неуспіху, результати та примітки. Походження відтворюваного прогону; Оцінка довіри за журналом приймача Критерії успіху чи неуспіху обирає оцінювач; Kshana записує вхідні дані, пороги та хеші, із якими запускалася.