Функціональна безпека – старша сестра інформаційної безпеки

image

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


чи Заслуговує уваги функціональна безпека?
Важлива функціональна безпека на сьогоднішній день? Адже фокус уваги в основному спрямований на інформаційну безпеку.
З одного боку, функціональна безпека безпосередньо пов'язана з надійністю апаратної складової, і тут залишилося небагато невирішених завдань, електроніка безвідмовно працює роками, а якщо і цього недостатньо, то завжди є можливість резервування. Але ж є ще програмна складова, на яку якраз і покладається управління функціями безпеки. Нещодавно на хабре була опублікована стаття «найдорожчі і доленосні помилки в ІТ-індустрії». В ній дається опис декількох кейсів, коли помилка в софті систем управління космічними системами обходилася в мільйони доларів, і це далеко не всі відомі випадки. А ще є системні проекти, що включають механічну, електронну та електричну складові, і тут, на жаль, теж є місце для помилок.
У статті «Інтернет речей (IoT) – виклики нової реальності» проведений аналіз кіберзагроз і методів забезпечення інформаційної безпеки для інтернету речей (Internet of Things, IoT). Одним з потенційних ризиків є перехоплення управління на рівні фізичних пристроїв. Тоді зловмисник може змусити систему управління виконувати небезпечні функції. У цьому випадку інформаційна та функціональна безпека є двома сторонами одного і того ж явища. Властивість інформаційної безпеки має забезпечити доступність, цілісність і конфіденційність даних системи управління. Властивість функціональної безпеки має забезпечити коректне виконання функцій системи управління, а при виникненні відмов перевести об'єкт управління в так зване безпечний стан.
Ще одним мотивом знайомства з функціональної безпекою є розуміння процесу сертифікації та ліцензування. Об'єкти, якими управляють комп'ютерні системи, часто створюють ризики для навколишнього середовища і людей (хімічне виробництво, газова та нафтова промисловість, медичні пристрої, атомні та інші електростанції, залізничний, автомобільний, авіаційний транспорт тощо). Комп'ютерні системи управління такими об'єктами мають виконувати функції безпеки і володіти певними характеристиками (резервування, відмовостійкість, самодіагностика, стійкість до зовнішніх екстремальних впливів тощо). Контроль за розробкою, впровадженням та експлуатацією комп'ютерних систем управління, важливих для безпеки, здійснюється державними органами сертифікації та ліцензування. Таким чином, розробникам систем доводиться знайомитися з вимогами до функціональної безпеки.

Архітектура систем управління
До якого класу комп'ютерних систем може бути застосоване поняття функціональної безпеки? Очевидно, що це системи контролю і управління. Контроль або моніторинг може бути віднесений до окремого випадку керування (збір даних з видачею управляючого впливу тільки у разі виявлення критичного відмови), тому будемо називати такі системи просто системами управління.
Для узагальнення поглянемо на очевидну структуру ідеального контуру управління.

image

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

image

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


Schneider Electric – Modicon Quantum PLC

Найбільш складною є типова архітектура IoT, я коротенько про неї розповів в статті на хабре.



Керуюча система реалізується на рівні Device Layer. Її програмно-апаратна реалізація може бути аналогічна вбудованій системі. З точки зору інформаційної безпеки критичними є інтерфейси DL-NL & DL-AL доступу до рівня Device Layer.
Таким чином, до систем управління, для яких важливо розглядати властивість функціональної безпеки, відносяться АСУ ТП, вбудовані системи та IoT.

Стандарти, що відносяться до функціональної безпеки
В області стандартизації існує таке поняття, як «umbrella standard», т. е. основний «вертикальний» стандарт верхнього рівня. Для функціональної безпеки таким є МЕК 61508 «Функціональна безпека систем електричних, електронних, програмованих електронних, пов'язаних з безпекою» (IEC 61508 Functional safety of electrical/electronic/electronic programmable safety-related systems), що включає сім частин. Даний стандарт переведений на російську мову і впроваджений в Російській Федерації у вигляді Госту.
Далі я спробував коротко інтерпретувати основні положення МЕК 61508. Вони, скажімо так, неідеальні, однак, здоровий глузд у них є. Нижче слід авторська обробка з урахуванням особистого досвіду у сфері функціональної безпеки.
Згідно з положеннями МЕК 61508, під функціональною безпекою (functional safety) мається на увазі коректне функціонування, як системи управління, так і керованого нею обладнання. Таким чином, для забезпечення функціональної безпеки необхідно спочатку визначити функції безпеки (safety functions), необхідні для зниження ризику керованого обладнання, а також для досягнення і збереження цим обладнанням безпечного стану (наприклад, функції протиаварійного захисту). Далі, система управління повинна володіти властивістю так званої повноти безпеки (safety integrity), під яким МЕК 61508 передбачає ймовірність того, що система буде коректно виконувати функції безпеки при всіх заданих умовах протягом заданого інтервалу часу.
При забезпеченні повноти безпеки (safety integrity) враховуються два типи відмов: випадкові (random failures) і систематичні (systematic failures).
Випадкові відмови викликані виходом з ладу апаратних компонентів і парируются такими методами, як резервування, самодіагностика, фізична та електричне розділення компонентів, підвищення стійкості до зовнішніх впливів і т. п.
Систематичні відмови викликані помилками проектування, в тому числі, і помилками програмного забезпечення. Усунення систематичних відмов можливо шляхом вдосконалення процесів проектування і розробки, тестування, управління конфігурацією, проектного менеджменту і т. п. Крім того, оскільки класичне резервування не дозволяє уникнути систематичних відмов, застосовується так зване диверсное (diversity) резервування, коли резервні канали розроблені із застосуванням різного програмного і апаратного забезпечення. Дорого, незручно, але іноді допомагає.
Положення МЕК 61508 деталізовані для потенційно небезпечних областей. Існують, наприклад, такі стандарти:
IEC 61511, Functional safety – Safety instrumented systems for the process industry sector;
IEC 62061, Safety of machinery – Functional safety of electrical, and electronic programmable electronic control systems;
IEC 61513, Nuclear power plants – Instrumentation and control systems for important to safety;
ISO 26262, Road vehicles – Functional safety;
EN 50129, Railway Industry Specific – System Safety in Electronic Systems;
IEC 62304, Medical Device Software;
В аерокосмічній галузі на МЕК 61508 не посилаються, тим не менш, схожий підхід:
для авіоніки розроблений стандарт RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification;
в космічній галузі стандарти розробляються космічними агентствами, наприклад NASA використовує стандарт STD 8719.13, Software Safety Standard.

Висновки
У дружній, але непередбачуваною сім'ї «безпека», що бореться за свободу інформаційних технологій від неприйнятних ризиків, живуть собі дві сестри: старша, функціональна безпека (safety), і молодша, інформаційна безпека (security).
Для керуючих систем, до яких відносяться такі архітектури, як АСУ ТП, вбудовані системи та інтернет речей (Device Layer), основним властивістю є функціональна безпека.
Під функціональною безпекою мається на увазі коректне функціонування, як системи управління, так і керованого нею обладнання.
Інформаційна безпека в таких системах носить додатковий характер і повинна запобігати доступу зловмисників до контролю над системою управління і керованим обладнанням.
Для пояснення основних аспектів функціональної безпеки планується наступний цикл статей:
Теорія надійності та функціональна безпека: основні терміни та показники;
Методи забезпечення функціональної безпеки систем управління;
Життєвий цикл безпеки для системи управління;
Тестування систем управління, важливих для безпеки.
Тематика може коригуватися залежно від отриманих коментарів.
Джерело: Хабрахабр

0 коментарів

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