Інформаційна безпека АСУ ТП: Дон Кіхот в еру кіберзброї


В даній статті здійснена систематизація вимог до інформаційної безпеки (ІБ) АСУ ТП. Вимоги обрані з доступних на даний момент стандартів, у першу чергу, з NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security» і розробляється нової редакції серії ISA/IEC 62443 «Security for Industrial Automation and Control Systems».

АСУ ТП взаємодіють з об'єктами фізичного світу і забезпечують захист від аварій та катастроф. В англомовній літературі АСУ ТП називають Industrial Control Systems (ICS) або Industrial Automation and Control Systems (IACS). У світі IT технологій їх можна порівняти з Дон Кіхотом, який залишився вірним простим, але не дуже модним принципами вже давно мінливому світі.

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

Схожі проблеми слід вирішувати і для інших кібер-фізичних систем, включаючи IoT і вбудовані керуючі системи.

У чому відмінність АСУ ТП від інших інформаційних (IT) систем?

Перш ніж розглядати питання ІБ, добре б спочатку розібратися, а що, власне кажучи, такого в АСУ ТП, що питання їх захисту та безпеки необхідно розглядати окремо від усього світу інших IT?

Хороший порівняльний аналіз, який відповідає на це питання міститься у вже згаданому NIST SP 800-82. Нижче наводиться фрагмент цього документа з порівняльними характеристиками АСУ ТП і абстрактної інформаційної системи (IT системи). З деякими моментами можна сперечатися, однак, при цьому треба пам'ятати, що в таблиці зроблена спроба максимально сконцентруватися на можливі відмінності, які, тим не менш, не можуть бути властивими для окремо взятої інформаційної системи (наприклад, у банківських система критична готовність і швидкість доступу).

Порівняльний аналіз інформаційних (IT) систем і АСУ ТП



Так у чому ж все-таки проблема з інформаційною безпекою АСУ ТП?

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

Часто все забезпечення ІБ зводиться до розгляду системи менеджменту інформаційної безпеки (СМІБ), хоча СМІБ є необхідною, але не достатньою умовою забезпечення ІБ для АСУ ТП. До того ж, в управлінні ІБ АСУ ТП необхідно розглядати три рівня: 1) підприємство, 2) програма з розробки та експлуатації серії АСУ ТП, 3) одинична АСУ ТП. Про це пам'ятають не завжди, і відбувається підміна понять, коли для АСУ ТП, як технічного об'єкта, намагаються виконати всі вимоги до СМІБ і втрачають функціональні та технічні характеристики.

Ще буває так, що ІБ розглядають лише з точки зору high-tech, як потік «чорних» інновацій (Stuxnet, BlackEnergy, etc.) і, відповідно, набір тих чи інших заходів захисту від них.

Тим не менш, розумним є системний підхід, який включає організаційні і технічні заходи (тріада «Люди – Процеси – Технології»).

Ще одним моментом є лавиноподібне збільшення за останні 5-10 років кількості стандартів в області ІБ. Багато стандартів активно переробляються і розширюються, що породжує певний хаос у вимогах.

Я постарався врахувати стандарти і техдоки по АСУ ТП, а також ті джерела, на які вони посилаються. Вийшов наступний великий перелік:
– серія ISO/IEC 27000 «Information technology – Security techniques – Information security management systems» всім відома, і на хабре багаторазово обговорювалася, стандарти переводяться на російську мову і приймаються в якості ГОСТ Р;
– три частини ISO/IEC 15408 «Information technology – Security techniques –Evaluation criteria for IT security», або так звані «Загальні критерії» (Common Criteria) також переведені на російську мову і прийняті в якості ГОСТ Р;
– серія стандартів ISA/IEC 62443 «Security for Industrial Automation and Control Systems»; ці стандарти вимагають ретельного уваги, оскільки являють собою «енциклопедію» ІБ АСУ ТП; перша редакція була розроблена International Society of Automation (ISA) у 2000-х роках, а потім адаптована в якості стандарту Міжнародної електротехнічної комісії (МЕК, по-англійськи IEC); в РФ деякі частини 62433 прийняті в якості ГОСТ Р; в даний час силами ISA ведеться розробка наступної редакції 62433; розробка відстає від графіка, але вже зараз там є про що почитати; малюнок нижче показує структуру запланованої серії ISA/IEC 62443;


Малюнок 1. Структура серії стандартів ISA/IEC 62443

– публікації States National Institute of Standards and Technology (NIST) на тему ІБ включають три серії: SP 500 Computer Systems, SP 800 Computer Security, SP 1800 Cybersecurity Practice Guides; NIST розробив власну СМІБ (NIST SP 800-53 «Security and Privacy Controls for Federal Information Systems and Organizations», а також internet security Framework (SCF); але нас найбільш цікавить NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security»;
– публікації North American Electric Reliability Corporation (NERC) під загальною назвою Critical Infrastructure Protection (SIP), відносяться, в першу чергу, до енергетичних систем;
Cybersecurity Capability Maturity Model (C2M2), розроблена Міністерством енергетики США (Department of Energy, DOE);
рекомендовані практики, розроблені командою Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), що входить до складу Міністерства внутрішньої безпеки США ( Department of Homeland Security, DHS);
– фреймворк Control Objectives for Information and Related Technologies (COBIT), розроблений International Professional Association ISACA;
– фреймворк Critical Security Controls for Effective Cyber Defense (CIS CSC) розроблений Center for Internet Security;
– також можна перерахувати стандарти, розроблені для окремих індустріальних галузей, наприклад, серія AGA 12 від American Gas Association (AGA), керівництво API 1164 від American Petroleum Institute (API), що застосовується на АЕС стандарт IEC 62645 «Nuclear power plants – Instrumentation and control systems – Cybersecurity requirements» і т. д.

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

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

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

Правда і те, що «надежностники» теж скептично дивляться на security, не бачачи особливих проблем в кібер загроз. Системи безпеки (протиаварійного захисту, ПАЗ) вкрай консервативні, оскільки вимагають великих витрат на ліцензування і сертифікацію. Наприклад, для АЕС витрати на ліцензування можуть становити до 10% вартості проекту.

Так що, іншого шляху, ніж міждисциплінарна інтеграція зусиль і знань, на даний момент не існує. Гармонізація вимог до ІБ і ФБ теж буде розглянута нижче в даній публікації.

Загальна картина вимог до інформаційної безпеки АСУ ТП

Коли розглядається будь-яка технічна система, пов'язана з можливими ризиками, то алгоритм формування вимог до неї наступний:

– ранжувати рівні ризиків, зв'язати ризики з функціонуванням системи, і, таким чином, ранжувати необхідні рівні безпеки системи;
– визначити заходи, спрямовані на досягнення необхідних рівнів ризиків; крупноблочно, такими заходами є: система менеджменту, процеси життєвого циклу, технічні контрзаходи захисту від порушення працездатності внаслідок відмов і/або зовнішніх впливів.

Коли я про це, задумався, то загальна картина у мене випала таким чином.



Малюнок 2. Концепція інформаційної безпеки

В основі лежить управління ризиками. Контекст ІБ включає оцінку загроз, вразливостей і ризиків разом з взаємопов'язаним процесом застосування контрзаходів зі зниження ризиків. Організація робіт по забезпеченню прийнятного рівня ризиків визначається категоріями «люди», процеси», «технології».



Малюнок 3. Контекст забезпечення та оцінювання інформаційної безпеки (джерело: ISA/IEC 62443)

На особливості опису АСУ ТП і концепції забезпечення ІБ необхідно зупинитися докладніше.

Опис АСУ ТП

Для опису особливостей розберемося з трьома типами моделей АСУ ТП, які пропонується розглядати в інтересах ІБ.

Насамперед, це референсна модель АСУ ТП, що визначає п'ять рівнів:

– Рівень 4: управління підприємством;
– Рівень 3: операційне управління виробництвом;
– Рівень 2: управління та моніторинг фізичних процесів (SCADA);
– Рівень 1: локальне керування процесом та обладнанням, включаючи функції захисту і безпеки (Control System);
– Рівень 0: фізичний процес і обладнання (датчики і виконавчі механізми).
Те, що зазвичай розуміється під АСУ ТП, по суті займає рівні 0, 1 і 2.



Малюнок 4. Референсна модель АСУ ТП (джерело: ISA/IEC 62443)

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



Малюнок 5. Модель фізичної архітектури АСУ ТП (джерело: ISA/IEC 62443)

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



Малюнок 6 Модель зонування АСУ ТП (джерело: ISA/IEC 62443)

Далі, процес забезпечення ІБ залежить від визначення того, як АСУ ТП застосовується на цільовому об'єкті. Такий опис включає:

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

Концепція забезпечення інформаційної безпеки

Рівні інформаційної безпеки

В основі концепції забезпечення ІБ лежить розподіл АСУ ТП на рівні ІБ (Security Level, SL). Визначаються рівні ІБ в залежності від характерних загроз і вразливостей, ризиків, цільових функцій частин і компонентів АСУ ТП, і, пов'язаних із цим політик безпеки.

Вважається, що рівні ІБ запозичені із раніше запропонованих і успішно застосовуються в АСУ ТП рівнів ФБ, званих також Safety Integrity Level (SIL).

У стандартах можна знайти кілька підходів до поділу АСУ ТП на Security Level. Ми зупинимося на зонуванні, запропонованому все в тому ж ISA/IEC 62443:

– Security Level 0 (No specific вимога or security protection necessary); визначення рівня, для якого не потрібні заходи забезпечення ІБ, породжує деяку невизначеність, оскільки незрозуміло, чи можна взагалі відмовитися від забезпечення ІБ; на практиці можна керуватися конкретною ситуацією і виходити з принципу розумної достатності; зазвичай нульовий рівень встановлюється не для зон в цілому, а для окремих компонентів, який з якоїсь причини не дотягують до такого рівня Security Level 1;
– Security Level 1 (Protection against casual or coincidental violation); захист від випадкових або співпадаючих порушень ІБ забезпечується, в першу чергу, процедурних шляхом;
– Security Level 2 (Protection against intentional violation using simple means with low resources, generic skills and low motivation); починаючи з другого рівня, розглядається захист від зловмисних порушень; на другому рівні розглядаються звичайні неспеціалізовані атаки, такі як віруси або використання відомих вразливостей; зазвичай такі атаки відображаються в автоматичному режимі;
– Security Level 3 (Protection against intentional violation using sophisticated means with moderate resources, ICS specific skills and moderate motivation); на даному рівні необхідно забезпечити захисту від зловмисників, що володіють достатніми знаннями і ресурсами, щоб зробити атаку на цільову систему; такі зловмисники використовують відомі уразливості операційних систем та індустріальних протоколів, а також програмні інструменти, які вимагають спеціальних знань;
– Security Level 4 (Protection against intentional violation using sophisticated means with extended resources, ICS specific skills and high motivation); цей рівень відрізняється від попереднього тим, що тут зловмисник залучає значні ресурси, наприклад, організована група може використовувати кластер комп'ютерів з високою обчислювальною потужністю на продовженні тривалого часу.

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

Для кожного з рівнів ІБ в АСУ ТП задається кілька груп вимог:

– управління ідентифікацією і аутентифікацією;
– контроль використання ресурсів;
– забезпечення інтегрованості (цілісності);
– забезпечення конфіденційності даних;
– доступність ресурсів;
– контроль і обмеження потоків даних;
– час реакції на події.

Відповідно, обсяг розглянутих нижче вимог до СМІБ, життєвого циклу АСУ ТП і захисних контрзаходів залежить від встановленого рівня ІБ.

Система менеджменту інформаційної безпеки

З проблеми організації СМІБ вже існує безліч матеріалів. Важливо пам'ятати, що менеджмент СМІБ може встановлюватися на декількох рівнях: 1) підприємство, 2) програма з розробки та експлуатації серії АСУ ТП, 3) одинична АСУ ТП.

Для СМІБ рівня підприємства, як для управлінської системи, реалізується цикл Демінга: Plan – Do – Check – Act.

Для СМІБ, застосовуваної в рамках проектів по розробці АСУ ТП, реалізується життєвий цикл, який розглянуто нижче.

Життєвий цикл інформаційної безпеки

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



Малюнок 7. V-подібний життєвий цикл розробки ПЗ АСУ ТП (джерело: IEC 61508)

Даний життєвий цикл реалізує вимоги до ФБ і тому називається Functional Safety Life Cycle. Для того, щоб відповідати Security Life Cycle, у специфікації повинні бути визначені вимоги до ІБ. Вимоги до ІБ повинні включати реалізацію спрямованих на зниження ризиків контрзаходів, таких, як забезпечення конфіденційності, інтегрованості і доступності, управління ідентифікацією і аутентифікацією і т. д. Ці вимоги потім реалізуються і перевіряються на всіх етапах життєвого циклу.

Важливою концепцією ІБ є «захист в глибину» (Defense in Depth), також прийшла з області ФБ. «Захист у глибину» подібна багаторівневої глибокоешелонованої оборони, коли, після проникнення атакуючого через один із захисних рівнів, він зустрічається з новою, можливо, принципово інший захистом атакується об'єкта.

Зв'язок інформаційної та функціональної безпеки

У публікаціях на тему функціональної безпеки мені вдалося звести все різноманіття вимог до декількох груп:

— управління функціональної безпекою (Functional Safety Management);
— реалізація життєвого циклу функціональної безпеки (Functional Safety Life Cycle);
— захист від систематичних відмов проектування системи (System and Software Failures Avoidance);
— захист від випадкових відмов апаратних засобів (Random Failures Avoidance).



Малюнок 8. Концепція вимог щодо функціональної безпеки

Якщо спроектувати ці групи вимог на область ІБ, то картина вийде приблизно та ж.

По-перше, виходячи з ролі АСУ ТП в забезпеченні ФБ і ІБ, провадиться градація і поділ систем на рівні. Для забезпечення та оцінювання ФБ вводяться Safety Integrity Levels (SIL), а для забезпечення та оцінювання ІБ – Security Levels (SL).

По-друге, в рамках СМІБ повинно бути реалізовано управління ІБ. Оскільки багато процесів ІБ і ФБ мають перетин, між ними повинна здійснюватися координація.

По-третє, як було показано вище, процеси розробки, верифікації та валідації, спрямовані на забезпечення ФБ, так і ІБ, можуть бути реалізовані в рамках єдиного життєвого циклу (Safety & Security Life Cycle).

По-четверте, в області ФБ та ІБ є загальні ризики, обумовлені можливими відмовами апаратних засобів. Методами захисту від таких відмов є резервування, діагностування, захист від перешкод і інших екстремальних впливів і т. п. Таким чином, для забезпечення ІБ і ФБ застосовуються одні і ті ж контрзаходи.

По-п'яте, в АСУ ТП виникають так звані систематичні відмови, викликані недоліками проектування та системної складової. Ті ж недоліки призводять до вразливостей, які можуть бути використані зловмисниками. Ряд контрзаходів може бути застосований для забезпечення як ІБ, так і ФБ (наприклад, контроль доступу до обладнання і інформації). Таким чином, виникає необхідність координації між контрзаходами, спрямованими на забезпечення ІБ і ФБ.

І, нарешті, у рамках управління ІБ і ФБ має здійснюватися оцінювання заходів по забезпеченню цих двох складових безпеки.

Все сказане вище представлено на діаграмі, яка може бути основою для координації діяльності щодо забезпечення ІБ і ФБ.



Малюнок 9. Концепція гармонізованих вимог до функціональної та інформаційної безпеки

Висновки

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

З урахуванням вищесказаного, забезпечення й оцінювання інформаційної та функціональної безпеки АСУ ТП повинне здійснюватися координовано в рамках єдиного життєвого циклу (Safety & Security Life Cycle).

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

Організаційна складова, в першу чергу, полягає в постійному навчанні персоналу і усілякому розвитку культури безпеки.

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

Для захисту від атак і киберинцидентов необхідно виділяти випадкову (вразливості, викликані випадковими відмовами обладнання) і систематичний (вразливості, спричинені недоліками проектування) складові.

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

Інші уразливості можна і потрібно усувати в рамках вже напрацьованого індустрією досвіду, керуючись концепцією побудови захисту в глибину (Defense in Depth). Однак, механізми хакерських атак будуть також розвиватись, і нульового ризику тут бути не може.

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

Очевидно, що методи боротьби повинні бути адекватними, а в кибервойнах АСУ ТП свідомо приречені на поразку. Тому, Дон Кіхот (АСУ ТП, і, особливо протиаварійний захист) повинен воювати з проблемами в технологічних процесах, і це поле бою повинно бути відокремлене і захищено від решти кіберпростору.
Джерело: Хабрахабр

0 коментарів

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