ІБ по-американськи. Частина 4. Розбираємося з «підгонкою» і «перекриттями» і завершуємо цей огляд


*Залиште свою роботу на робочому місці!*

Отже, нелегкий шлях по обзиранию створення короткого огляду NIST SP 800-53 підходить до логічного кінця. Я радий, що мені вдалося зробити задумане і написати нехай невеликий, але закінчений за змістом цикл статей, не зупинившись на першій або другій частині. Надалі, сподіваюся, вийде від випадку до випадку ділитися з громадськістю своїми міркуваннями на тему ІБ, ІТ та аудиту.

Отже, у цій статті буде нарешті поведано про вибір набору контролів безпеки, підгонки його під потреби конкретної організації та створення так званих перекриттів «фоліо», застосовних поза масштабів окремої організації.

Посилання на попередні статті:
ІБ по-американськи. Частина 1. Що таке NIST 800-53 і як виглядають контролі безпеки?
ІБ по-американськи. Частина 2. А можна детальніше про NIST 800-53 і причому тут управління ризиками?
ІБ по-американськи. Частина 3. Що з себе являє базовий набір контролів безпеки і як визначати критичність інформаційних систем?



Вибір базового набору контролів
В попередній статті я представив своє бачення методики визначення критичності ІС, представлене в документі FIPS 199 і виконується на першому кроці Фреймворку управління ризиками, розглянутого в другій статті. Що ж треба зробити далі?
Після визначення рівня критичності ІС починається процес визначення необхідних контролів безпеки. Першим кроком є вибір базового набору контролів, грунтуючись на результатах категоризації. Вибирається один з трьох наборів, відповідний низького, середнього та високого рівня критичності. Безумовно, варто відзначити, що далеко не всі контролі входять у ці набори. Найменше їх представлено у наборі для низького рівня, що очевидно. В черговий раз насмілюся нагадати, що базові набори є лише відправною точкою подальшого процесу щодо створення відповідного набору контролів. У подальшому, в процесі «підгонки», контролі можуть бути додані, прибрані або уточнені для відповідності вимогам безпеки організації.
Також важливим є той факт, що в силу своєї універсальності базові набори, представлені в документі, мають певні допущення, в рамках яких вони є актуальними. Інакше кажучи, ці набори створювалися для певних, цілком конкретних умов застосування. Однак не варто дорікати авторів у вузькості поглядів, адже ці умови спеціально підібрані таким чином, щоб охопити наймасовіший сегмент ІС. Отже, представляю вам ці допущення:
  1. ІС розташовані на фізичних об'єктах (спочатку набори не заточені під віртуалізацію);
  2. Інформація користувачів в ІС організації відносно постійна (користувачі не створюють і не знищують інформацію в значних кількостях на регулярній основі);
  3. ІС функціонують в многопользовательском режимі;
  4. Деяка інформація в ІС організації недоступна іншим користувачам, що мають авторизований доступ у ті ж ІВ (адже розмежування доступу — це базовий принцип, чи не так?);
  5. ІС існують в мережевому оточенні;
  6. ІС є по суті системами загального призначення (тобто не намагаємося захистити іранські центрифуги зі збагачення урану);
  7. Організація володіє необхідними структурою, ресурсами та інфраструктурою для реалізації контролів.
У разі якщо деякі з цих припущень не відповідають дійсності — необхідно виробляти додаткову «підгонку» контролів під потреби організації (про що буде розказано докладно трохи нижче).

Також автори представляють ряд можливих ситуацій, які не перекриваються захисними заходами, реалізованими в базових наборах контролів:
  1. Існує інсайдерська загроза в організації (як кажуть, «проти лому немає прийому»);
  2. щодо організації існують постійні погрози з боку серйозних порушників (мова йде, наприклад, про банківському секторі);
  3. Окремі типи інформації потребують додаткового захисту у відповідності з вимогами законодавства, регуляторів тощо ;
  4. ІС повинні взаємодіяти з іншими системами через середовища, що відрізняються рівнем захищеності (наприклад, через публічний сегмент мережі).
У разі якщо які-небудь з цих припущень вірні для організації, то необхідно звернутися до набору додаткових контролів і здійснити «підгонку» захисних заходів у відповідності з результатами оцінки ризиків в організації.


*Санта може відпочити… А ти ні! У безпеки не буває вихідних*

«Підгонка» базових наборів контролів
Нагадаю, що під «підгонкою» («tailoring») розуміється процес оптимізації, доопрацювання або вдосконалення набору контролів таким чином, щоб він відповідав вимогам безпеки конкретної ІС або організації. Цей активність зазвичай здійснюється після вибору базового набору контролів і включає в себе:
  1. Виявлення і визначення загальних характеристик контролів безпеки в базовому наборі (тут мається на увазі тип: загальний/системний/гібридний) ;
  2. Аналіз можливих сфер застосування залишилися контролів базового набору;
  3. Вибір компенсуючих контролів безпеки при необхідності;
  4. Встановлення значень параметрів контролів безпеки, вже визначених в організації;
  5. Додаток базового набору додатковими контролями і «посиленнями» контролів при необхідності;
  6. Надання додаткової інформації щодо впровадження контролів при необхідності.
Процес «підгонки», що входить до складу етапу вибору і специфікації контролів, є частиною застосовуваної в організації процесу управління ризиками. По суті організація використовує «підгонку» для досягнення економічно вигідною безпеки, заснованої на оцінці ризиків і сприяє досягненню потреб бізнесу (адже нікому не потрібна інформаційна безпека, яка не здатна закрити актуальні загрози або вартість якої перевищує можливі втрати). Всі активності «підгонці» контролів повинні проходити обов'язкове узгодження з призначеними в організації відповідальними особами перш ніж вони будуть реалізовані.
В цілому, процес підгонки займає в даній публікації одне з центральних місць і описаний дуже детально, оскільки є однією з основних активностей, що сприяє побудові системи ІБ, що відповідає потребам організації та нівелює актуальні ризики ІБ. Можливо більш докладно ця тема буде висвітлена пізніше.


*Безпека — необхідна турбота в будь-який час року*

Розробка «перекриттів» («фоліо»)
Отже, коротко ознайомившись з процесом «підгонки» базових наборів контролів, який надає можливість одержання більш точних і відповідають реальності заходів по забезпеченню інформаційної безпеки, необхідно звернути свій погляд на ще одну дуже корисну можливість застосування публікації NIST SP 800-53.
У певних ситуаціях для організації може бути вигідно використовувати інструмент «підгонки» для отримання узагальненого набору контролів, іменованого «перекриттям», застосовного у масштабах якої-небудь галузі, або, наприклад, необхідного для відповідності яким-небудь специфічним вимогам, технологій або завданням функціонування (далі будемо називати такі «перекриття» галузевими). Розробка такого набору може бути виконана як самою організацією, так і федеральними органами в рамках якої-небудь галузі. Так, наприклад, уряд може випустити набір контролів, обов'язковий до реалізації у всіх федеральних установах, в яких здійснюється використання інфраструктури PKI. Таким чином набір контролів безпеки може розроблятися будь-яким зацікавленим особою для адекватного реагування на ризики інформаційної безпеки і потім поширюватися серед інших учасників якої-небудь галузі або користувачів будь-яких технологій або обладнання. Така особливість застосування методології «підгонки» надає хороший базис для забезпечення стандартизації можливостей щодо забезпечення інформаційної безпеки в різних технологічних областях або в конкретних умовах функціонування (тут знаходять своє застосування універсальність і одноманітність підходу, закладені авторами в самих основах публікації NIST SP 800-53).
Концепція «перекриттів» вводиться для забезпечення можливості розробки як галузевих, так і спеціалізованих наборів компенсуючих заходів ІБ для інформаційних систем і організацій. «Перекриття» — це цілком певний набір контролів безпеки, «підсилень» та додаткової інформації щодо їх реалізації, розроблений у відповідності з правилами проведення процесу «підгонки».
«Перекриття» доповнюють базові набори контролів безпеки шляхом:
  1. Надання можливості додавання і видалення контролів;
  2. Забезпечуючи застосовність контролів безпеки та їх трактування для спеціалізованих інформаційних технологій, комп'ютерних парадигм, типів інформації, середовищ виконання, технологічних галузей, вимог законодавства та регуляторів і так далі.
  3. Установки в масштабах галузі значень параметрів контролів безпеки і «підсилень»;
  4. Розширення додаткової інформації про застосування контролів при необхідності.
Зазвичай організації використовують «перекриття» у разі наявності розбіжностей з допущеннями, у межах яких створені базові набори контролів безпеки (ми вже говорили про цих припущеннях раніше у відповідному розділі). У разі відсутності у організації значних розбіжностей з допущеннями базових наборів, найчастіше не виникне необхідності створення та використання «перекриття».
«Перекриття» надають можливість досягнення одностайності всередині якої-небудь галузі (інакше кажучи, області інтересу) і розробити план безпеки для ІС організації, який отримає підтримку серед інших учасників, незважаючи на специфічні умови й обставини в конкретній галузі. Категорії перекриттів можуть бути корисні для різних областей інтересу, наприклад:
  1. Індустріальні галузі, коаліції і корпорації (охорона здоров'я, енергетика, транспортна галузь тощо);
  2. Інформаційні технології/комп'ютерні парадигми (хмарні сервіси, BYOD, PKI, крос-доменних рішень і т.д.);
  3. Середовище функціонування;
  4. Типи ІС і режимів функціонування (промислові/тестові системи, однокористувацькі системи, системи озброєння, ізольовані системи);
  5. Типи завдань/функціонування (контртеррор, екстрене реагування, дослідження, розробка, тестування, оцінка тощо);
  6. Вимоги законодавства і регуляторів (тут американські вимоги до нам не застосовуються).
При розробці «перекриттів» автори публікації радять для досягнення більшої ефективності використовувати концепції управління ризиками, закладені в документі NIST SP 800-39. Успішна розробка «перекриття» вимагає обов'язкової участі:
  • Професіоналів в області ІБ, які розуміють специфіку області, що є метою розробки «перекриття»;
  • Експертів предметної області, для якої здійснюється розробка перекриття, мають розуміння суті контролю безпеки, призначення базових наборів контролів та структури розробки «перекриттів».
До одного набору контролів може бути застосовано кілька «перекриттів». «Підігнаний» («tailored») набір контролів, отриманий в результаті розробки перекриття може бути як більш, так і менш стійким (сильним) по відношенню до вихідного. Оцінка ризиків допомагає визначити, чи є ризик реалізації «підігнаного» набору прийнятним в рамках стратегії прийняття ризиків, прийнятої в організації «області інтересу», яка розробляла перекриття. У разі впровадження декількох «перекриттів» не виключена ситуація, в якій різні перекриття суперечать один одному в окремих моментах. У разі виявлення такого протиріччя, яке може вилитися в конфлікт при реалізації або навіть відмова від будь-якого конкретного контролю безпеки, спірна ситуація повинна вирішуватися із залученням відповідальних осіб, розробників перекриття, власників інформації та бізнесу.
У загальному вигляді «перекриття» покликані скоротити необхідність проведення «підгонки» наборів контролів на ходу (на швидку руку), шляхом розробки набору контролів та «підсилень», найбільш повно відповідає конкретним умовам, обставинам та/або ситуації. Таким чином повинен досягатися більш зрілий і в перспективі єдиний підхід до забезпечення ІБ. У той же час використання «перекриттів» не позбавляє від необхідності провадити подальшу «підгонку» для відповідності потребам організації, що діють в ній обмежень і допущеннях. «Підгонка» «перекриття» також допускається і проводиться з схваленням і погодженням відповідальних осіб і розробників. Однак у загальному випадку очікувана кількість змін у структурі наборів контролів безпеки, що здійснюються на швидку руку, значно знижується.


*Ігноруючи безпеку ви ходите по тонкому льоду*

Документування процесу вибору контролів
В NIST звичайно-ж є розділ, присвячений питанням документування всіх дій, здійснюваних у процесі роботи з контролями безпеки. Звичайно, американці знатні бюрократи і, як і працівники багатьох вітчизняних установ, люблять підкріплювати будь-яку активність якийсь папірцем. Однак цього разу мова йде все-таки про доцільних речах.
Отже, необхідно, щоб всі рішення про вибір контролів супроводжувалися обґрунтуванням прийнятого рішення. Це необхідно для сприяння успішному проведенню наступних оцінок потенційних загроз активів організації. Підсумковий набір контролів безпеки, що включає в себе будь-які обмеження щодо використання окремих інформаційних систем, так і їх сукупності, повинен бути відображений у відповідному плані безпеки. Необхідно забезпечити документування будь-яких значимих рішень в рамках процесу управління ризиками, для надання в подальшому відповідальним особам доступу до даної інформації.

Додаткові висновки
Рішення, що приймаються в процесі «підгонки» наборів контролів, існують не самі по собі, але в умовах будь-якої конкретної організації. А це значить, що в той час як вони сфокусовані на забезпеченні інформаційної безпеки, необхідно забезпечити узгодженість цих рішень з іншими факторами ризиків, що існують в організації. Такі фактори, як вартість, розклад, продуктивність, повинні бути розглянуті в ході визначення контролів, які плануються до впровадження в організації.


*Безпека вимагає уваги до деталей*

Нові розробки і успадковані системи
Процес вибору контролів безпеки, про який йшла мова в даній статті, може бути застосовано до інформаційних систем організації з двома різними підходами: як до успадкованих систем або як до нових розробок.
Для розроблюваних систем процес вибору контролів безпеки проводиться з точки зору «визначення вимог на етапі проектування», оскільки система ще не існує в кінцевому вигляді і здійснюється лише попередня класифікація ІС. В даному випадку контролі, включені в план з безпеки інформаційної системи, служать вимогами щодо безпеки і включаються в систему на етапах розробки і впровадження. В іншому ж просто застосовується повний цикл RMF.
Для успадкованих систем, навпаки, процес вибору контролів проводиться з точки зору gap-аналізу, коли організація планує провести значні зміни в інформаційній системі (наприклад, в ході оновлення або модифікації). Оскільки унаследованность означає, що ІС вже використовується, швидше за все організацією вже вироблялася категоризація системи і вибір контролів безпеки виллється в коректування підібраного раніше набору контролів, який вже повинен бути присутнім в узгодженому плані безпеки для даної системи, і подальшу реалізацію цих контролів в ІС. Отже, gap-аналіз може бути здійснено наступним чином:
  1. Проводиться підтвердження чи оновлення значення критичності і рівнів негативного впливу на ІС, виходячи з інформації, яка на даний момент обробляється, зберігається або передається системою;
  2. Здійснюється аналіз існуючого плану з безпеки, що описує реалізовані контролі безпеки. Беруться до уваги будь-які зміни категорій безпеки, рівнів негативного впливу, а також інші зміни в організації, бізнес-процесах, системах і середовище функціонування. Повторна оцінка ризиків та плану з безпеки обов'язкові, також, як і документування будь-яких додаткових контролів безпеки, які повинні бути реалізовані для того, щоб ризики залишилися на прийнятному для організації рівні.
  3. Провадиться реалізація контролів, представлених в оновленому плані безпеки, а також документування плану дій ключових моментів не реалізованих контролів.
  4. Також здійснюються кроки, представлені у циклі Фреймворку управління ризиками в тій же манері, як це робиться для знову розроблювальних систем.


Замість висновку

На цьому, мабуть, можна і закінчити огляд публікації NIST SP 800-53. За межами даного циклу статей залишилося ще багато цікавого, адже документ містить понад 450 сторінок друкованого тексту. Проте з усіма деталями й тонкощами використання даного документа не можливо ознайомитись за 4 коротких статті на Хабре, тим більше без досвіду реального застосування представлених у документі принципів і реалізації описаних контролів.
Я сподіваюся, що у мене вийшло зацікавити кого-небудь публікацією NIST SP 800-53, а тим, хто вже щось чув про неї, розповісти трохи докладніше про її будову.
І наостанок ще один плакат:

*Додайте щіпку безпеки. Це ключовий інгредієнт!*

За сім з вами прощаюся. Якщо будуть запитання, зауваження та пропозиції, не соромтеся використовувати коментарі і лічку.
Спасибі за увагу!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.