AEP-67 - інженерне забезпечення довіри до системи в програмах NATO

Що це таке

AEP-67 - це Allied Engineering Publication NATO, яка пояснює програмі, як інженерними засобами вбудувати забезпечення довіри до системи ("system assurance") в електронну, мікропрограмну чи програмну систему протягом усього її життєвого циклу. Публікація визначає забезпечення довіри до системи як "the justified confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle." Це радше посібник, ніж специфікація, і його несе STANREC 4808: саме там зафіксовано рекомендацію держав користуватися ним, тобто AEP - це Allied Engineering Publication, і він доходить до постачальника так само, як будь-яка Allied Publication, бо його вимагає власна угода конкретної програми NATO.

Чинна редакція - Edition B, Version 1, оприлюднена в жовтні 2017 року, яка замінила початкову Edition 1. Вона несекретна й безоплатна, її видав NATO Standardization Office для Life Cycle Management Group при CNAD.

Обґрунтування довіри: твердження, аргументи, докази

Організаційна ідея AEP-67 - це обґрунтування довіри: пов'язаний набір тверджень про критичні для довіри властивості системи, аргументів, які виправдовують кожне твердження, і доказів, які підтверджують кожен аргумент. Твердження має бути чітким і перевірним висловлюванням, а не дією, і воно розкладається на часткові твердження, доки кожне з них не з'єднається з доказом, який можна відшукати. Посібник встановлює мінімальні умови для такого обґрунтування: воно має відповідати справжньому робочому середовищу системи, твердження мають бути виправдані аргументами, а аргументи - доказами, і все обґрунтування має будуватися ітеративно та лишатися живим протягом усього життєвого циклу, а не бути написаним один раз і покладеним до архіву. Його також треба передати разом із системою під час приймання, а не залишити в команді розробників. Аудитор, який працює за цим документом, шукає не одне погодження, а простежуваний ланцюг від заявленого твердження через його аргумент до названого доказу.

Що він охоплює і чого свідомо не охоплює

Обсяг посібника щільно обмежений довірою, пов'язаною з безпекою: конфіденційність, цілісність, доступність, автентифікація, підзвітність (разом із неспростовністю) та придатність до аудиту. Він говорить про це прямо і так само прямо називає те, що лишається поза обсягом: "it does not address assurance for quality, safety, or dependability," хоча й зазначає, що супротивник, здатний підірвати безпеку системи, побічно може підірвати й ці інші властивості. Крім того, він розглядає довіру як властивість системи в цілому, а не будь-якої окремої частини: система, повністю зібрана з добре обґрунтованих елементів, не стає обґрунтованою автоматично, бо довіра залежить від того, як частини поєднані, а не лише від того, як побудували кожну з них.

Процеси угод: закупівля та постачання

Коли елементи купують, а не будують власними силами, AEP-67 просить покупця зважити репутацію, кваліфікацію, процеси та інструменти постачальника і надавати перевагу інтерфейсам на основі стандартів та ешелонованому захисту, щоб один слабкий постачальник не зруйнував усієї системи. Окрему увагу приділено готовим комерційним і державним елементам, бо покупець зазвичай має мало впливу на майбутній напрям розвитку готового продукту, і настанови очікують, що докази вибору постачальника, історія дефектів, оцінки продукту та відповідні сертифікати, які постачальник уже має, будуть записані й лишатимуться простежуваними.

Проєктні процеси: планування, ризики, конфігурація та інформація

Структура декомпозиції робіт має прямо називати діяльність із забезпечення довіри: оцінювання загроз, розроблення та підтримання обґрунтування довіри, взаємне рецензування з наголосом на довірі, статичний і двійковий аналіз вихідного коду та тестування на проникнення. Перш ніж програма рушить далі, ключові контрольні точки рішень мають пройти вимірні критерії довіри, як-от результати статичного аналізу та висновки червоної команди. Управління ризиками спирається на названі джерела відомостей про вразливості (каталоги Common Vulnerabilities and Exposures, Common Weakness Enumeration та Common Attack Pattern Enumeration and Classification) і розглядає ймовірності якісно, а не чисельно, бо розумний супротивник поводиться не як випадковий збій і може обрати найгірший момент для нападу. Управління конфігурацією має давати журнал аудиту про те, хто, що і коли змінив, зберігати його незмінним заради підзвітності, застосовувати до змін принцип найменших привілеїв і вести процес сортування виправлень, який зважує ризик відомої вразливості проти ризику неперевіреного виправлення. Управління інформацією вимагає позначати й захищати матеріали, чутливі з погляду довіри, і тісно узгоджувати роботу з управлінням конфігурацією.

Технічні процеси: від вимог до утилізації

Аналіз вимог відокремлює власні функції, які виконують місію, від захисних функцій, які її оберігають, і градує критичність системи від Highest, де компрометація спричиняє катастрофічний зрив місії за секунди чи хвилини (таблиця 3-4), до Low. Архітектурне проєктування спирається на конкретні прийоми: найменші привілеї, ізоляція та стримування, спостереження й реагування, стійкість до часткової відмови, ідентифікація та автентифікація, криптографія, а також десять названих механізмів захисту від втручання - від пломб, які показують факт розкриття, до корпусів, що обнуляють свої дані, якщо хтось у них просвердлить отвір. Реалізацію побудовано навколо названих джерел загроз: ненавмисний дефект, недобросовісний авторизований розробник, неавторизований зловмисник, скомпрометований постачальник, і кожному з них відповідають контрзаходи, як-от увімкнені від самого початку попередження компілятора, засоби статичного й динамічного аналізу та парне розроблення зі взаємним рецензуванням. Верифікація та валідація потребують задокументованої стратегії, що охоплює статичний аналіз, фазингове тестування, тестування на проникнення й роботу червоної команди, а для найкритичніших елементів - методи формального доведення, виконані людьми, які мають потрібні навички, щоб витлумачити результати. Введення в дію вимагає, щоб встановлена система була посилена, непотрібні служби вимкнені, а постачання захищене від втручання через ланцюг відповідального зберігання та пакування, яке показує факт розкриття. Експлуатація та навчання вимагають навчити користувачів, що робити й чого не робити, зокрема розпізнавати соціальну інженерію, а систему відстежувати на відхилення від очікуваної конфігурації. Обслуговування вимагає автентифікувати виправлення, іноді через відкритий ключ, вбудований у розгорнуту систему, і вимагає, щоб виправлення само ніколи не вносило нової вразливості. Утилізація вимагає знищення даних відповідно до рівня чутливості, аж до спалювання, бо інакше супротивник із доброю ресурсною базою може відновити дані з перезаписаних чи розмагнічених носіїв.

Аудитор, який працює за AEP-67, зрештою шукає живий набір взаємопов'язаних артефактів, а не сертифікат: визначення критичності, структуру декомпозиції робіт, яка називає завдання з довіри, записи статичного аналізу та взаємного рецензування, результати червоної команди, записи про навчання й запис про утилізацію, і все це має простежуватися назад до тверджень в обґрунтуванні довіри.

Стандарти, названі поряд із ним

Власна структура AEP-67 наскрізь побудована на ISO/IEC 15288:2008, стандарті життєвого циклу системної та програмної інженерії, а його додаток A оглядає суміжні цивільні роботи з управління інформаційною безпекою - ISO 9001, ISO/IEC 27001, ISO/IEC 27002 та ISO/IEC 27005 - як довідковий матеріал, а не як вимоги, що їх накладає сам посібник. Його несе STANREC 4808, рекомендація NATO, яка фіксує згоду держав користуватися ним.

Стандарти, на які він посилається

• ISO/IEC 27001Довідково
• ISO 9001Довідково
• ISO/IEC 27005Довідково
• ISO/IEC 27002Довідково

Інші стандарти в темі «Управління життєвим циклом і забезпечення якості»

• AACP-02AACP-02 - настанови щодо взаємного проведення аудитів контрактів
• AAP-20AAP-20 рамкова система управління програмами NATO
• AAP-48AAP-48 процеси життєвого циклу системи в NATO
• ACMP-2000ACMP-2000 політика NATO щодо управління конфігурацією
• ACMP-2009ACMP-2009: керівництво з управління конфігурацією
• ACMP-2100ACMP-2100 договірні вимоги до управління конфігурацією