Захист АСУ ТП в Росії: досліджуємо нові вимоги ФСТЕК

Про кібератаки на АСУ ТП і промислових диверсіях «в один клік» до 2014 року чули, здається, вже навіть діти. Тут і havex, і «найстрашніший пошуковик» Shodan (де, до речі, нещодавно опублікували карту АСУ ТП), і десятки інцидентів, описаних в останньому звіт Novetta.

Російські організації, відповідальні за регулювання в галузі безпеки, до пори до часу не приділяли уваги вразливостей промислових систем, проте наказ ФСТЕК № 31 від 14 березня 2014 року обіцяє докорінно змінити ситуацію.

Не можна сказати, що раніше в Росії безпека АСУ ТП (SCADA) зовсім не регулювалася. З 2007 року процеси ІБ на основних критично важливих об'єктах регламентуються вимогами, що пред'являються до «ключовим систем інформаційної інфраструктури» (КСІІ), однак методичні вказівки в цьому документі мають обмеження по розповсюдженню: підприємства, яким вони адресовані, повинні бути внесені до спеціального переліку. У цьому списку КСІІ могли опинитися і банки, і будь-які інші організації, але при цьому не враховувалися особливості застосування АСУ ТП як систем реального часу, а також тенденції розвитку ІТ-інфраструктур (наприклад, робота в візуалізованими середовищах). Відокремити АСУ ТП, врахувати специфічну архітектуру і слабкі місця таких систем — завдання вимог, сформульованих у наказі № 31.

Часто російське нормотворчість дорікають в тому, що воно відірване від передового міжнародного досвіду і не відповідає останнім тенденціям. Щоб перевірити це припущення, ми порівняли вимоги наказу ФСТЕК № 31 з провідними закордонними стандартами в області систем промислової автоматизації, а саме:

  • сімейством галузевих стандартів NERC Critical Infrastructure Protection (NERC CIP);
  • сімейством стандартів ISA/IEC 62443 Industrial Automation and Control Systems Security;
  • рекомендаціями NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security» і NIST SP 800-53 «Security and Privacy Controls for Federal Information Systems and Organizations».

Що цікавого в наказі ФСТЕК № 31 є вже зараз

Розробка та документування правил і процедур (політик) забезпечення безпеки (ці заходи захисту йдуть під номерами на 0). Це важливі заходи: будь-процес забезпечення безпеки, причому не тільки інформаційної, починають будувати з ретельного документування всіх процедур. Регулярний чекінг можна порівняти з передполітним оглядом літака і перевіркою бортового журналу, і звучить все це нудно для пасажира лише до тих пір, поки пасажир не піднявся на висоту 10 тисяч кілометрів.

Вимоги до захисту середовища віртуалізації (ЗСВ). Технології віртуалізації дозволяють оптимізувати ресурси, однак породжують нові загрози. Зрозуміло, що зниження витрат цікавіше боротьби за безпеку, тому критично важливі системи в цілому і АСУ ТП зокрема дуже швидко виявляються в не зовсім безпечних хмарах, і цей процес необхідно якось контролювати. Відповідні пункти у наказі № 31 можна тільки вітати, а ось в перерахованих нами зарубіжних стандартах питання захисту віртуальних середовищ не розглянуті.

Навчання та відпрацювання дій користувачів у разі виникнення нештатних (непередбачених) ситуацій (ДНС). Підвищення обізнаності персоналу зменшує як мінімум ризики, пов'язані з соціальною інженерією. Репетиція «плану порятунку» важлива також для розуміння співробітниками своєї ролі в процесах керування інцидентами безпеки.

Вимоги щодо безпечної розробки ПО (ОБР). Код в програмному забезпеченні АСУ ТП часто просто жахливий, а на більшості критично значимих підприємств можна виявити уразливості 10-15-річної давності. Оновлення часто не встановлюються в принципі, що обумовлене безліччю чинників, починаючи від безперервності технологічного процесу і закінчуючи необізнаністю працівників про погрози. Тому найкраще рішення — приймати всілякі заходи для виправлення помилок в АСУ ТП на етапі розробки. Подібні вимоги практично не відображені в зарубіжних стандартах, що ще раз говорить на користь авторів російського документа.

Вимоги за інцидент-менеджменту (ИНЦ) і аналізу загроз безпеки (УБІ). Дані вимоги складають суть ризик-орієнтованого підходу, відображеного в наказі № 31. Їх наявність означає формування захисту на підставі характерних для системи ризиків: це дозволяє враховувати нові загрози і покращувати процеси забезпечення ІБ.

Що хотілося б побачити

Швидке поява детальних рекомендацій та методичних вказівок для фахівців ІБ і аудиторів. Зараз наказ ФСТЕК № 31 — це досить високорівневий документ.

Поділ на мережевому рівні корпоративної ЛОМ і технологічних мереж за аналогією з IEC-62443-2-1 і NIST SP 800-82. Вимогу про необхідність сегментування ЛВС в наказі присутній (ЗІС-17), проте у відповідному методичному документі найкращим рішенням буде явно зазначити необхідність відділення технологічних мереж від корпоративних.

Рекомендації з побудови безпечної архітектури компонентів АСУ ТП з урахуванням поділу на рівні, як це зроблено в стандартах IEC-62443-2-1, NIST SP 800-82: нижній рівень — польовий, середній — ПЛК, верхній рівень — SCADA.

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

Перевірка персоналу перед наданням допуску до роботи з АСУ ТП. Подібні вимоги є NERC CIP і ISA/IEC 62443, але в поточну версію наказу № 31 поки не увійшли.

Заходи, пов'язані з звільненням персоналу. Не дуже веселі, але необхідні дії, що включають блокування облікових записів, зміну паролів і т. п., прописані в ISA-62443-2-1 і NERC-CIP. Кажуть, що колишні слідчі краще за всіх уміють знищувати докази, а екс-співробітник КВО, добре знайомий з технологічним процесом, може бути значно небезпечніше порушника з боку. Хотілося б в подальших версіях наказу № 31 побачити вимоги до заходів, пов'язаних із звільненням працівників КВО.

В цілому, незважаючи на окремі недоліки, документ відповідає кращим міжнародним стандартам і практикам у галузі забезпечення інформаційної безпеки АСУ ТП, а в окремих пунктах вводить найсучасніші вимоги, потреба в яких назріла.

Більш докладне зіставлення вимог наказу ФСТЕК від 14 березня 2014 р. № 31 з аналогічними пунктами міжнародних стандартів представлено на сайт Positive Technologies.

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

0 коментарів

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