NIST SP 800-171 захист Controlled Unclassified Information

Що це таке

NIST SP 800-171 Revision 3 задає вимоги безпеки для захисту конфіденційності Controlled Unclassified Information (CUI), коли ту інформацію обробляють, зберігають або передають на власних системах нефедеральної організації. NIST написав його, власними словами, "for use by federal agencies in contractual vehicles or other agreements" з нефедеральними організаціями, з якими вони ділять CUI. Публікація нікого не зобов'язує самим існуванням; спочатку має посилатися контракт або угода федерального агентства. Revision 3 затверджено в квітні 2024 і опубліковано в травні 2024, замінює Revision 2 від лютого 2020.

Вимоги організовано в 17 родин, від контролю доступу і журналювання аудиту через фізичний захист і управління ризиком ланцюга постачання, і кожна з них звужена з набагато більшого каталогу заходів у NIST SP 800-53. Три родини, що існують у тому більшому каталозі, тут відкинуто повністю: Contingency Planning, бо вона стосується доступності, а не конфіденційності; Program Management, бо не прив'язана до конкретної системи; і PII Processing and Transparency, бо інформація, що ідентифікує особу, уже трактується як категорія CUI і не потребує окремої родини. Це варто знати, якщо ви звикли до повнішої бази SP 800-53 і очікуєте їх побачити.

До кого звернений і як зобов'язує

Документ називає дві ролі безпосередньо. З того, що називає "Federal perspective," він звернений до "the entity establishing and conveying the security requirements in contractual vehicles or other types of agreements." З "Nonfederal perspective," він звернений до "the entity responding to and complying with the security requirements set forth in contracts or agreements." Під цими двома ролями сидять особи з відповідальністю за розроблення систем, закупівлю, управління ризиками і оцінювання безпеки.

Ніщо в документі не робить його обов'язковим самим по собі. Для нефедеральної організації він стає реальним у момент, коли федеральний контракт або угода його називає, і лише тією мірою, якою той контракт каже. Вимоги застосовуються до "components of nonfederal systems that process, store, or transmit CUI or that provide protection for such components," без обмеження конкретним сектором чи технологією: охоплена система може бути чим завгодно від звичайної ІТ-мережі до "operational technology (OT)... Internet of Things (IoT) devices, Industrial IoT (IIoT) devices, specialized systems, cyber-physical systems, embedded systems, and sensors."

Де рішення про охоплення окупається рано

Сам документ позначає, де насправді сидить вартість цієї роботи. Section 1.1 зазначає, що організація може обмежити охоплення вимог безпеки "by isolating the system components", що обробляють CUI, "in a separate security domain," що уникає "increasing the organization's security posture beyond what it requires for protecting its missions, operations, and assets." Вирішене до побудови системи, це вибір архітектури. Вирішене після підписання контракту, що вже називає цей документ, зазвичай означає відділити компоненти, що обробляють CUI, із системи, яку ніколи не будували з тією межею. Перш ніж будь-яку з 97 вимог можна оцінити, вимога 03.11.01 прямо каже, що "establishing the system boundary is a prerequisite to assessing the risk of the unauthorized disclosure of CUI" - тож перше справжнє питання не з якої вимоги почати, а де CUI насправді живе.

Що охоплюють 17 родин

Access Control вимагає визначених і керованих типів облікових записів, забезпечення найменших привілеїв (включно з правилом, що привілейовані користувачі застосовують непривілейовані облікові записи для повсякденної, не пов'язаної з безпекою роботи), блокування після повторних невдалих входів і віддалений і бездротовий доступ, проведений через керовані точки контролю. Мобільні пристрої потребують шифрування всього пристрою або на основі контейнера, перш ніж можуть тримати CUI, і будь-яка зовнішня система, особиста чи інша, "is prohibited unless specifically authorized."

Awareness and Training, Audit and Accountability, and Configuration Management просять грамотність з безпеки і навчання за ролями, прив'язане до фактичних ролей, визначений і переглянутий набір журнальованих подій із захищеними записами аудиту і задокументовану базову конфігурацію з формальним контролем змін. Виконання програмного забезпечення - відмова за замовчуванням: може працювати лише програмне забезпечення зі затвердженого переліку.

Identification and Authentication - місце, де Revision 3 змінює те, чого аудитор, звичний до старішої настанови, очікуватиме. Багатофакторна автентифікація тепер застосовується і до непривілейованих облікових записів, не лише до привілейованих. Управління паролями відходить від обов'язкової періодичної ротації і йде до перевірки нових паролів щодо веденого переліку "commonly-used, expected, or compromised passwords" перш ніж їх прийняти.

Incident Response, Maintenance, Media Protection, and Personnel Security охоплюють задокументований план реагування на інциденти, випробуваний за власним графіком (не лише написаний і підшитий), затверджені і перевірені на шкідливе ПЗ інструменти обслуговування з багатофакторною автентифікацією для сеансів віддаленого обслуговування, санацію носіїв перед утилізацією чи повторним використанням і перевірку плюс визначений процес вимкнення доступу в момент закінчення або зміни зайнятості.

Physical Protection, Risk Assessment, and Security Assessment and Monitoring вимагають веденого переліку доступу до об'єкта з монітореними і журнальованими точками входу, оцінювання ризику, що явно включає ризик ланцюга постачання, і вимогу, щоб організація оцінювала, за власним визначеним графіком, чи вона насправді виконує ці вимоги, відстежуючи все нерозв'язане в plan of action and milestones (POAM).

System and Communications Protection and System and Information Integrity вимагають захисту межі, що відділяє компоненти, звернені до публіки, від внутрішніх, політики мережевого трафіку з відмовою за замовчуванням, криптографічного захисту CUI і в транзиті, і в стані спокою, і захисту від шкідливого коду з визначеним терміном латання для оновлень, релевантних безпеці.

Planning, System and Services Acquisition, and Supply Chain Risk Management замикають набір: задокументовані політики і процедури за кожною іншою родиною, план безпеки системи, що описує межу системи і як виконується кожна вимога, принципи інженерії безпеки, застосовані до нового розроблення, план заміни компонентів без підтримки і план управління ризиком ланцюга постачання, що охоплює систему від дослідження і розроблення до утилізації.

Як вас оцінюють

Сертифікації щодо NIST SP 800-171 немає. Документ не називає акредитованого органу сертифікації і не описує схеми сертифікації організації чи виробу щодо нього. Натомість вимагає самооцінювання: організація повинна "assess the security requirements for the system and its environment of operation... to determine if the requirements have been satisfied," з частотою, яку визначає сама, і документувати будь-який розрив у plan of action and milestones. Супутня публікація NIST, SP 800-171A, задає процедури проведення того оцінювання, але документ лишає рішення про те, яких доказів досить, сторонам контракту: федеральне агентство "may consider system security plans and POAMs as inputs to risk-based decisions on whether to process, store, or transmit CUI on a system hosted by a nonfederal organization." На практиці те, що оцінювач або контрактний офіцер просить побачити, - план безпеки системи, POAM, записи аудиту і записи навчання, перевірки та обслуговування, яких вимагають окремі вимоги, а не сертифікат.

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

Вимоги NIST SP 800-171 звужені з повного каталогу заходів у NIST SP 800-53, Rev. 5, використовуючи помірну базу в SP 800-53B. Його супутник, NIST SP 800-171A, Rev. 3, дає процедури оцінювання вимог, описаних тут. Базова схема захисту CUI сягає FIPS 199 і FIPS 200, які задають значення впливу на конфіденційність, під яке побудовано вимоги, і Executive Order 13556 та федерального регулювання CUI в 32 CFR Part 2002. Окремі вимоги вказують на FIPS 140-3 для криптографічних модулів і приблизно на сорок подальших NIST Special Publications і Interagency Reports як підтримувальну, ненормативну настанову, жодна з яких не тримається окремо в нашому каталозі.

Запросити доступ до цього стандарту

Розкажіть, як ви плануєте працювати з NIST SP 800-171 і що вам від нього потрібно. Ми зв'яжемося з вами та повідомимо, чим тут може допомогти ComplyTrain.