NIST SP 800-37 рамка управління ризиками для інформаційних систем

Що це таке

NIST Special Publication 800-37 Revision 2 задає Risk Management Framework (RMF), семикроковий процес, який Національний інститут стандартів і технологій США побудував, щоб звести управління ризиками безпеки та приватності для федеральних інформаційних систем і організацій в одну повторювану рамку. Він обов'язковий для використання федерального уряду; NIST написав його так, щоб "the RMF can be applied to any type of nonfederal organization" також, на добровільній основі, і політика FISMA і OMB окремо вимагає, щоб зовнішні надавачі, що обробляють федеральну інформацію або експлуатують системи від імені уряду, виконували ті самі вимоги, що й самі агентства. Це Revision 2, опублікований у грудні 2018 року.

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

Документ називає учасників безпосередньо, а не описує загальну "організацію". Authorizing official - єдина особа, яка може прийняти ризик безпеки та приватності для операцій і активів організації, і для федеральних агентств ця роль "is an inherent U.S. Government function and is assigned to government personnel only." Власник системи і, де заходи спільно використовуються між системами, common control provider збирають докази і подають їх на рішення. Control assessor, відібраний до ступеня незалежності, який задає authorizing official, випробовує впроваджені заходи, а старша посадова особа агентства з приватності веде паралельний трек для будь-якої системи, що обробляє персональну інформацію. Ширший набір підтримувальних ролей - chief information officer, старша посадова особа агентства з інформаційної безпеки, старша підзвітна посадова особа з управління ризиками, корпоративні, безпекові і приватні архітектори і люди, що насправді адмініструють і користуються системою, - повторюється впродовж усього.

Оскільки політика FISMA і OMB поширює ті самі очікування на "external providers handling federal information or operating systems on behalf of the federal government," рамка також, по суті, звертається до будь-якого підрядника чи хмарного надавача, що стоїть у тих відносинах із федеральним агентством. Для тих організацій він зобов'язує так, як більшість федеральних вимог: через контракт або угоду, що народжує відносини, а не самим існуванням.

Prepare і поділ рівня організації / рівня системи

Prepare - основоположний крок рамки, і він іде на двох рівнях. На рівні організації, зроблений один раз, а не на систему, організація призначає свої ролі управління ризиками, задає стратегію управління ризиками і толерантність до ризику, проводить оцінювання ризику на всю організацію, ідентифікує, які заходи може надавати центрально як common controls для наслідування іншими системами, і задає стратегію безперервного моніторингу на всю організацію. На рівні системи, повторюваний для кожної системи, Prepare ідентифікує місію, яку система підтримує, її зацікавлених сторін, активи, що потребують захисту, і, критично, authorization boundary системи, "what the organization agrees to protect under its management control." Усе всередині тієї межі - проблема цієї системи; усе поза нею належить іншій системі або межі зовсім іншої організації. Та сама робота рівня системи продовжується через ідентифікацію типів інформації, які система оброблятиме, оцінювання ризику рівня системи, визначення вимог безпеки та приватності, розміщення системи в корпоративній архітектурі і реєстрацію її в управлінських офісах організації.

Categorize, Select, Implement і Assess

Власник системи і власник або розпорядник інформації документують характеристики системи і категоризують її, зазвичай щодо рівнів впливу FIPS 199 і FIPS 200, перш ніж authorizing official перегляне і затвердить результат; система, що охоплює кілька рівнів впливу, бере найвищий, що застосовується. Select бере заходи з попередньо зібраної бази, узгодженої з тим рівнем впливу, підлаштовує їх до фактичних обставин системи і розподіляє їх по системі і її операційному середовищу, з планом, задокументованим у планах безпеки та приватності, які затверджує authorizing official. Implement ставить заходи на місце і оновлює документацію, щоб описати систему як фактично побудовану. Assess - місце, де незалежний control assessor, працюючи до того ступеня незалежності, який задав authorizing official, випробовує те, що впроваджено, і звітує про результати; для оцінювання рівня системи оцінювач не повторно випробовує заходи, які система наслідує від common control provider, лише те, що система впроваджує сама. Недоліки або усувають і повторно оцінюють, або несуть далі в задокументованому plan of action and milestones.

Authorize і Monitor

Власник системи або common control provider збирає пакет уповноваження - виконавче резюме, плани безпеки та приватності, звіти оцінювання і plan of action and milestones - і подає його authorizing official, який аналізує ризик, вирішує, як відповісти, і тоді ухвалює саме рішення про уповноваження: authorization to operate, common control authorization, authorization to use (зазвичай там, де одна організація покладається на вже уповноважену систему іншої), або відмову, де ризик не можна знизити до прийнятного рівня вчасно. Це конкретне рішення не можна делегувати призначеному представнику authorizing official. Моніторинг не зупиняється, щойно систему уповноважено: він починається на старті експлуатації і триває до утилізації, відстежуючи зміни, проводячи постійні оцінювання, що можуть подвоїтися як річне оцінювання, якого вимагає сам FISMA, і тримаючи пакет уповноваження актуальним. Визначений набір тригерів подій - нова вразливість, значна зміна, зміна authorizing official - змушує негайний перегляд. Організація, чий безперервний моніторинг відповідає потрібній суворості, може перевести систему на ongoing authorization, де поточне знання authorizing official про систему замінює фіксовану дату повторного уповноваження.

Для систем, що залежать від інфраструктури зовнішнього надавача, рамка дає організації спертися на власні заходи надавача і результати оцінювання, водночас застерігаючи, що охоплення, суворість і незалежність оцінювача різняться за надавачем і що організації "should exercise caution", покладаючись на них. Один приклад, який документ називає безпосередньо: попереднє authorization to operate, видане під Federal Risk and Authorization Management Program (FedRAMP), може бути основою, на яку організація-замовник спирається для власного authorization to use хмарної системи.

Як оцінюють рішення про уповноваження

Ніхто не є "NIST SP 800-37 certified." Сертифікації щодо цього документа немає: він не називає акредитованого органу сертифікації і не описує схеми сертифікації. Відповідність іде через власне рішення authorizing official про прийняття ризику, записане в документі рішення про уповноваження, що викладає рішення, його умови і або дату припинення, або частоту перегляду ongoing authorization. Нічого тут не видає зовнішній орган: це власна старша посадова особа однієї організації приймає ризик за систему, яку та організація володіє, і рішення не переходить до іншої організації, крім де та організація навмисно на нього спирається, як замовник, коли видає власне authorization to use на силі наявного уповноваження надавача.

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

NIST SP 800-37 побудовано працювати поряд із кластером інших публікацій NIST, а не стояти окремо. Каталог заходів, з якого бере крок Select, живе в окремій публікації SP 800-53, чиї супутники SP 800-53B (бази) і SP 800-53A (процедури оцінювання) підтримують кроки Select і Assess відповідно. FIPS 199 і FIPS 200 дають рівні впливу, які застосовує Categorize. SP 800-39 дає модель ризику організації, місії і системи, на якій сидить рамка; SP 800-30 - методологію оцінювання ризику; SP 800-137 - настанову з безперервного моніторингу. Жоден із них не тримається окремо в цьому каталозі.

Поза серією NIST, NIST публікує відображення з власного каталогу заходів на заходи безпеки ISO/IEC 27001 і на вимоги безпеки Common Criteria ISO/IEC 15408-2 і 15408-3. Документ прямо каже, що відображення - фонове читання, а не еквівалентність, на яку спиратися безпосередньо: він називає такі відображення "inherently subjective" і очікує, що організація сама перегляне одне, перш ніж на нього опертися.

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

• ISO/IEC 27001Довідково

Інші стандарти в темі «Стандарти та методи управління ризиками»

• ISO 31000Управління ризиками за ISO 31000
• NIST SP 800-30NIST SP 800-30 оцінювання ризиків інформаційної безпеки