Статті

Документальний фільм про кібервірус StuxNet

опубліковано 1 лют. 2020 р., 12:55 Александр Пупена

Про це варто знати кожному автоматнику.

Уязвимость нулевых дней


Захист даних з використанням криптографії

опубліковано 28 груд. 2019 р., 00:30 Александр Пупена

    Криптографія (Cryptography) - одна з методик захисту інформаційних систем, що передбачає шифрування (Encryption) повідомлення або вмісту файлу за допомогою певного методу чи алгоритму, який робить його незрозумілим для сторонньої особи чи засобу. Окрім самого повідомлення для шифрування використовується ключ (key) – певна послідовність символів. Ключ є унікальним для кожного шифрувальника, тому вихідні повідомлення будуть різні для кожного відправника навіть при однаковому їх змісті і використаному алгоритмі. Отримувач може розшифрувати (Decryption) повідомлення тільки з використанням відповідного алгоритму та ключа. Ключі можуть бути однаковими (симетричне шифрування) або різними (асиметричне шифрування), але при цьому тільки санкціоновані отримувачі зможуть розшифрувати повідомлення.

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

    Враховуючи, що асиметричні алгоритми складніші і потребують порівняно багато ресурсів та довгих ключів, вони використовуються для передачі секретних ключів для симетричного шифрування для організації одного сеансу зв’язку.

    Для формування певного унікального «відбитку» даних застосовують механізм хешування (hashing) – перетворення вхідного масиву даних довільної довжини у вихідний бітовий рядок фіксованої, порівняно невеликої довжини. Такі перетворення також називаються хеш-функціями, а їхні результати – хешем (hash), хеш-кодом або хеш-сумою. Хешування використовують для багатьох задач, наприклад в якості контрольної суми для файлу чи повідомлення. Враховуючи різну довжину та варіативність даних, якість та придатність алгоритму для певної задачі оцінюється ймовірністю співпадання хеш-сум за різних повідомлень. Для криптографічних цілей хешування повинно задовольняти наступним вимогам:

  • незворотність – неможливість відновлення вхідних даних по хеш-коду
  • неможливість співпадіння хеш-кодів для різних повідомлень
  • практична неможливість підбору повідомлення для формування заданого хеш-коду

Виконання цих вимог на сьогоднішній день забезпечується алгоритмами групи SHA-2. У старіших алгоритмах хешування (MD5, SHA-1) були виявлені недоліки, тому наразі вони не рекомендуються для використання, хоч працюють в кілька разів швидше.

    Хешування використовується для формування електронних цифрових підписів (digital signature) –  вид електронного підпису, отриманого за результатом криптографічного перетворення набору електронних даних, який додається до цього набору або логічно з ним поєднується і дає змогу підтвердити його цілісність та ідентифікувати підписанта. За документом, що має передаватися, формується хеш-сума, яка потім шифрується з використанням приватного ключа (відбитка) підписанта. Підписант також публікує відкритий ключ, який дасть змогу розшифрувати даний хеш будь кому із отримувачів документів. Зробивши хешування отриманого документу, отримувач перевіряє його на ідентичність, порівнявши з розшифрованою хеш-сумою.

Для перевірки приналежності відкритих публічних ключів власникові використовують цифрові сертифікати (Certificates) – електронний файл, як правило формату X.509 (розширення *.DER, *.PEM або *.CER), який включає в себе в тому числі:

  • відкритий ключ особи, юридичної особи або доменне ім’я;
  • опис особи чи юридичної особи: ім'я, назва домену тощо;
  • підпис довіреної третьої сторони, відповідальної за те, що власник відкритого ключа був перевірений, а отже, і справжність відкритого ключа, як і власника.

Довірена (trusted) третя сторона є органом із сертифікації (CA), який відповідає за:

  • перевірку особи, яка просить створити сертифікат;
  • створення сертифікату після перевірки, потім його підписання (приватним ключем від CA);
  • поширення поточного стану сертифікатів
  • ведення списку анульованих сертифікатів (наприклад, якщо ключ зламаний).

Треті сторони можуть бути відомими публічними організаціями, які за замовченням можуть бути в переліку центрів сертифікації програмних засобів, що потребують перевірку (наприклад Веб-браузерів). Центри сертифікації можуть мати ієрархічну структуру.   

Для керування сертифікатами може використовуватися інфраструктура відкритих ключів (Public key infrastructure, PKI) — інтегрований комплекс методів та засобів (набір служб), призначених забезпечити впровадження та експлуатацію криптографічних систем із відкритими ключами. Інфраструктура дозволяє зв’язувати відкриті ключі з особами (наприклад, іменами користувачів або організаціями) та надає гарантії, що відкритому ключу, отриманому за допомогою нього, можна довіряти апріорі. PKI може базуватися на різних механізмах, наприклад центрах сертифікації або блокчейн. У першому випадку до інфраструктури входять також центри реєстрації (які також можуть підтвердити дійсність сертифікату), репозитарії та архіви сертифікатів.

Механізми шифрування, що описані вище можуть бути використані для обміну шифрованими повідомленнями між різними засобами, а шифрування може проходити на різних рівнях комунікаційної моделі. Зокрема SSH (англ. Secure SHell — «безпечна оболонка») — мережний протокол прикладного рівня, що дозволяє проводити віддалене керування комп'ютером (чи іншим пристроєм) і тунелювання TCP-з'єднань (наприклад, для передачі файлів). SSH може бути використаний для віддаленого доступу терміналу до пристрою (ПК чи іншого пристрою), аналогічно як Telnet, при цьому шифрує весь трафік, в тому числі і паролі, що передаються. Інше використання SSH – передача будь яких даних по шифрованому каналу та побудови тунелей. Один з вузлів в з’єднанні є SSH-сервером (прослуховує TCP порт 22), інший – SSH-клієнтом, який ініціює підключення.

SSH не призначений для шифрування даних прикладних протоколів, для цього можуть використовувати протоколи SSL/TLS (остання версія TLS 1.3). SSL/TLS забезпечують сеанс зв’язку для передачі зашифрованих даних прикладного рівня поверх TCP/IP. Так, наприклад, на ньому базується HTTPS, який є схемою функціонування протоколу HTTP поверх SSL/TLS. Схема працює наступним чином. Спочатку клієнт (браузер) надсилає запит на сервер, щоб встановити з'єднання, захищене протоколом TLS, а сервер відповідає, надсилаючи свій сертифікат. Якщо підпис сертифіката підтверджений CA, який входить в перелік центрів сертифікації браузеру, клієнт генерує ключ шифрування та передає його зашифрувавши з використанням відкритого ключа серверу (міститься в його сертифікаті) для продовження шифрованого обміну. Сертифікат серверу може бути підписаний самостійно і не підтверджуватися CA. У цьому випадку існує ймовірність того, що сайт є шахрайським, але користувач може дозволити з'єднання, якщо потребується шифрований обмін і є довіра до серверу. Аналогічним чином користувач може поступити при простроченні сертифікату. У інших випадках з’єднання не відбувається.   

    Шифрування можна також організувати на мережному рівні з використанням протоколу IPsec, який забезпечує захист на рівні пакету IP. Таким чином можуть шифруватися будь які пакети TCP або UDP. IPsec може передавати зашифроване корисне навантаження (транспортний режим), або передавати весь IP-пакет в зашифрованому IPsec-пакеті (тунельний режим). Тунельний режим може бути використаний для побудови VPN, де два вузли (наприклад маршрутизатори) будуть передавати усі IP-пакети по шифрованому тунелю IPsec, а інші вузли будуть обмінюватися з використанням звичайних IP-пакетів.

Читайте також:

Основні загрози та напрями кібератак в системах АСКТП

опубліковано 25 груд. 2019 р., 04:36 Александр Пупена   [ оновлено 25 груд. 2019 р., 04:40 ]

    Для розуміння необхідності кіберзахисту та можливих наслідків від кіберзлочинів, варто розглянути основні загрози та напрями кібератак в системах АСКТП. 

Для початку зупинимося на самому означенні терміну «кібератака». Відповідно до Закону України «Про основні засади забезпечення кібербезпеки України» (від 5 жовтня 2017 року № 2163-VIII) кібератака – це спрямовані (навмисні) дії в кіберпросторі, які здійснюються за допомогою засобів електронних комунікацій (включаючи інформаційно-комунікаційні технології, програмні, програмно-апаратні засоби, інші технічні та технологічні засоби і обладнання) та спрямовані на досягнення однієї або сукупності таких цілей: порушення конфіденційності, цілісності, доступності електронних інформаційних ресурсів, що обробляються (передаються, зберігаються) в комунікаційних та/або технологічних системах, отримання несанкціонованого доступу до таких ресурсів; порушення безпеки, сталого, надійного та штатного режиму функціонування комунікаційних та/або технологічних систем; використання комунікаційної системи, її ресурсів та засобів електронних комунікацій для здійснення кібератак на інші об’єкти кіберзахисту.

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

    Для проникнення в цільову систему та проведення зловмисних дій можна поєднувати різні засоби. Цей процес може проходити через кілька етапів, наприклад:

  • етап розпізнавання: дослідження цільової системи, ідентифікація, вибір цілей та їх вразливості; цілі можуть бути технічними (сервери, PLC) або людськими (персонал компанії);
  • етап передачі зловмисного програмного забезпечення в цільову систему, зокрема:  електронною поштою, через шкідливий веб-сайт, переносний накопичувач або за допомогою вразливості в цільовій системі;
  • етап експлуатації: зловмисне програмне забезпечення приховано виконується в цільовій системі, шпигує або чекає команд від зловмисника; шкідливе ПЗ також може спробувати скопіювати себе на інші станції мережі.

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

Категорії шкідливого ПЗ.

    Зловмисники (особи або навіть цілі організації) можуть використовувати різні категорії шкідливого програмного забезпечення.  

Вірус - це шкідливе програмне забезпечення, яке встановлюється прихованим чином на комп’ютер чи обладнання та здатне копіюватися з одного комп'ютера на інший. Код вірусу є частиною іншого програмного забезпечення (носія), і коли воно запускається – вірус також виконується і може скопіювати себе як частину іншого файлу. Запуск зараженої програми може бути ініційований людиною або автоматично, наприклад якщо USB-накопичувачі виконують файл автозапуску. Хробак (worm) - це тип вірусу, який поширюється по мережі, часто використовуючи вразливість віддаленого виконання.

Троян – це програмне забезпечення, яке часто передається через вкладення в електронний лист та видається за доброякісне, але по факту встановлюється на машину та проводить певні приховані дії (шпигування, надсилання інформації користувача на піратський сервер і т.ін). Логічна бомба - це категорія зловмисного програмного забезпечення, яка встановлюється приховано, наприклад, через троян та запускає дії в певну дату, визначену хакерами. Руткіт - це шкідливе програмне забезпечення, яке встановлюється прихованим способом, метою якого є надання зловмиснику доступу привілейованого користувача, який таким чином має можливість виконувати всі дії в операційній системі. Шпигунське програмне забезпечення - це програмне забезпечення, яке шпигує за користувачами та записує їхню діяльність, наприклад, натискання клавіш (keylog), запис звуку та/або зображення.

Бекдор (Back doors) - це прихована особливість програмного забезпечення або операційної системи, яка найчастіше впроваджується на момент розробки та дозволяє отримати доступ до певних опцій або обходити звичайну процедуру аутентифікації. Ця функція при розробці може бути призначена як для благих цілей (наприклад для відновлення втрачених паролів) так і для незаконних (крадіжка даних).

Ботнет - це мережа машин, підключених до Інтернету, кожна з яких виконує «бот», тобто програмне забезпечення робота, відповідального за реагування на зовнішні команди або виконання попередньо означених дій. Бот поширюється одним із способів, згаданих вище, таких як віруси або електронні листи. Вони приховано встановлюються на цільових робочих станціях або пристроях і чекають замовлень. Це дає можливість створювати армії машин, оснащених шкідливим програмним забезпеченням. Ці зомбі-машини можуть бути комп’ютерами або іншими пристроями, що підключені до Інтернету, наприклад, камерами або засобами промислового Інтернету речей (IIoT), і використовуються для здійснення інших атак. Вони можуть надсилати спам або здійснювати розподілені атаки відмови в обслуговуванні (DDoS).

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

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

Атаки засобів.

Засоби (програмні та технічні) можуть бути атаковані через різні типи вразливостей. Атака переповнення буфера (Buffer overflow) намагається розмістити більше даних в області пам'яті, ніж вона може містити. Це може пошкодити інші змінні, заблокувати систему або, коли область даних перекривається з областю коду записати в стек виклик потрібної підпрограми і тим самим призвести до виконання шкідливого коду.

Атака грубою силою – це метод проб і помилок, який використовується деяким програмним забезпеченням для декодування зашифрованих даних, таких як паролі або ключі шифрування даних. Подібно до того, як злочинець може «зламати» сейф, випробувавши безліч можливих комбінацій, програма для взлому грубою силою проходить послідовно через всі можливі поєднання дозволених символів. Груба сила вважається безвідмовним підходом, хоч і займає тривалий час. Насправді програми, що виконують цей тип атаки, поєднують грубу силу та словниковий підхід: перш ніж систематично перевіряти всі комбінації, вони спочатку перевірять типові паролі, потім словникові слова, потім класичні варіанти наборів.

Атака нульового дня (zero day) – це атака, яка використовує вразливості, які не були виправлені або оприлюднені. Часто цей тип нападу включає атаки, спрямовані на вразливості, відомі широкій публіці, але ще не виправлені. Якщо ці вразливості виявлять хакери, вони можуть використовувати їх для встановлення атак, через фрагменти програм чи програми, які називаються експлойтами (exploits). Експлойти будуть зберігатися в таємниці якомога довше, їх можна продати на чорному ринку кіберзлочинності.

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

Атаки WEB-серверів.

При Веб-доступі також можуть бути використані атаки з ін'єкцією SQL, при якій зловмисний код вставляється в рядки, які потім передаються екземпляру SQL-сервера для аналізу та виконання. Якщо на сервері не стоїть попередня обробка та фільтрація запитів, таким чином, наприклад, можна отримати перелік усіх користувачів.

Атака міжсайтових сценаріїв (XSS) - це тип атаки, при якому зловмисник вводить дані, такі як шкідливий сценарій (як правило Javascript), у контент (наприклад сторінку) із надійних веб-сайтів. Атаки на міжсайтові сценарії трапляються у випадках, коли ненадійному джерелу дозволено вводити власний код у веб-застосунок, і цей шкідливий код включається у динамічний вміст сторінки, що передається браузеру жертви. Так може відбуватися, наприклад, на форумах, якщо вміст, введений користувачами, не валідується. Включений сценарій може використовуватися для крадіжки ідентифікаційних даних або інформації з файлів cookies.

Для засобів АСКТП (ПЛК, засоби розподіленого вводу/виводу, тощо) також присутні особливі вектори атак. Наприклад, багато ПЛК різних виробників працюють на базі ОС VxWorks, яка має вразливості, що дозволяють через проблему неперевіреного переповнення цілих чисел дозволити користувачеві виконувати довільний код або зробити атаку DoS. Якщо ПЛК не передбачає захист програми користувача від змін (наприклад по паролю, або спеціальному фізичному ключі), це надає можливість вставляти зловмисне програмне забезпечення в цільову програму, що може виконувати шкідливі дії або навіть створювати DoS. Існують експерименти, в яких в ПЛК був прописаний хробак, який поширювався по промисловій мережі на інші ПЛК. Інший тип атаки стосується класичного OPC DA, що базується на COM/DCOM. OPC дозволяє зловмиснику перелічити властивості системи або використовувати вразливості шляхом переповнення буфера. Протокол OPC був замінений стандартом OPC UA, який є набагато безпечнішим.

Мережні атаки.

Принцип атаки людини посередині мережі (атаки МіМ або MitM) полягає в передачі зв'язку між двома станціями через проміжний вузол зловмисника без відома цих станцій. Це можна зробити за допомогою різних методик:

  • зараження кешу ARP: коли обидві робочі станції знаходяться в одній локальній мережі, то зловмисник може поставивши "комутатор пакетів" (маршрутизатор, шлюз) і змусити усі мережні пакети пройти через його комп'ютер; так він зможе передивитися або навіть підмінити зміст пакетів;
  • DNS-Spoofing: якщо для зв’язку використовується імена вузлів (наприклад, www.scada1.com), зловмисник може змінити адресу DNS-серверів на свою, щоб перенаправити усі пакети через потрібний вузол;
  • перенаправлення ICMP: з допомогою ICMP зловмисник може надіслати роутеру підроблене повідомлення, щоб перенаправити потік даних жертви на його власну машину (тому ця опція повинна бути заблокована в маршрутизаторах).

DoS-атака (Denial of service, відмова в обслуговуванні) – це атака, призначена для виведення системи чи служби з нормального режиму роботи. Вона може використовувати відому вразливість у конкретному додатку чи операційній системі або використовувати певні вразливості в конкретних протоколах або сервісах. Під час DoS-атаки зловмисник намагається не допустити доступу авторизованих користувачів до конкретної інформації, або до комп'ютерної системи чи самої мережі. Це може бути досягнуто шляхом несподіваного вимкнення (наприклад, через переповнення буфера) або затопити службу мережними запитами (наприклад ботнетом). Атака DoS також може використовуватися разом з іншими діями для отримання несанкціонованого доступу до комп'ютера за допомогою атаки MitM. У контексті АСКТП, DoS-атака системи, що відповідальна за керування фізичним устаткованням, може мати серйозні наслідки. Якщо атакованою системою є СПАЗ – можуть постраждати люди або навколишнє середовище. DoS-атака, що проводиться мережею комп'ютерів або підключених об'єктів, називається DDoS атакою (Distributed DoS). Атаки DoS/DDoS можуть бути проведені наприклад з використанням вразливості SYN-затоплення, коли створюється багато напіввідкритих TCP -з’єднань, що унеможливлює або ускладнює створення нових підключень.

Якщо засоби використовують стек TCP/IP вони можуть очікувати вхідних повідомлень по одному з портів TCP або UDP. Так, наприклад, порт 21 використовується для зв'язку FTP, порт 80 для веб-сервера, 102 для ISO-TSAP (для S7 протоколу), а 502 – для Modbus. Якщо контроль та керування доступом до цих портів не проводиться, це може надавати зловмиснику багато можливостей для несанкціонований дій.  Під час спроби вторгнення, сканування портів дозволяє зловмиснику дізнатися, чи існує пристрій за адресою, а потім визначити його функціональні можливості та вразливості. Це може включати такі етапи:

  • перевірка активність хоста;
  • перевірка, чи знаходиться хост за брандмауером;
  • виявлення ОС або типу обладнання;
  • сканування доступних портів;
  • пошук вразливості.

Спроба вторгнення виконується шляхом тестування відомих вразливостей на ідентифікованих портах. Наприклад, для порту 80, який використовується для веб-сайтів, автоматичне програмне забезпечення надсилає запити для спроб ін'єкцій SQL, атак міжсайтових сценаріїв або спроб переповнення буфера. Для порту 22, який використовується SSH, спроби з'єднання можуть бути здійснені грубою силою. У Інтернеті можна знайти велику кількість утиліт для сканування мережі. Наприклад програмне забезпечення nmap дозволяє "сканувати" комп'ютерну мережу та відкриває порти. Утиліта PLCSCAN дозволяє виявляти ПЛК, наявні в мережі. Виявлення активності сканування портів є важливим захисним процесом виявлення спроби нападу і може попередити інцидент.

Атака повторного відтворення (Replay attack) - це атака, яка передбачає перехоплення пакетів з мережі, (наприклад, за допомогою механізму MiM), а потім використання їх для повторного пересилання  одержувачу. При цьому пакети обов’язково інтерпретувати чи розшифровувати. Наприклад, відправник може надіслати зашифроване ім’я та пароль, щоб ідентифікувати себе, після чого зловмисник повторно використовуючи ту саму послідовність, може отримати права відправника. Атака такого типу можлива проти певних типів вразливих ПЛК: зловмисник, що має доступ до мережі керування процесом, може вкрасти номери сеансу та додати довільні команди, щоб зупинити або перезапустити ПЛК.

Фізичні атаки.

Якщо зловмисник може отримати фізичний доступ до цілі, можлива низка додаткових атак. По-перше, зловмисник може просто знищити або пошкодити пристрої. Крім того, він може:

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

Фізична атака може також бути здійснена на викинутому обладнанні з метою викрадення даних або паролів.

Атаки з використанням людського фактору.

Однією з найслабших ланок безпеки ІТ-системи є людський фактор. Окрім ненавмисних (необережності) чи навмисних (свідоме недотримання правил) людських помилок, користувач може стати жертвою так званих методів соціальної інженерії. Ці методи ґрунтуються на брехні, хибному представленні, шантажі чи жадібності. Наприклад, зловмисник може зв’язатися з системним адміністратором і прикинутися авторизованим користувачем, попросивши отримати новий пароль. Ще одна загальна стратегія – представити себе членом персоналу постачальника, якому потрібен тимчасовий доступ для проведення аварійного обслуговування.

Ці методи також значною мірою покладаються на фішинг-афери, які мають на меті зловживати "наївністю" користувачів для отримання своїх облікових даних. Фішинг — один з різновидів соціальної інженерії, заснований на незнанні користувачами основ мережної безпеки. Зокрема, багато хто не знає простого факту: сервіси не розсилають листів з проханнями повідомити свої облікові дані, пароль та інше. Існує два типи фішингу: масовий (mass phishing) – використання загальних електронних листів а також цільовий (Spear phishing) – який проводиться після дослідження цілі та компанії. Виявлення останнього може бути набагато складнішим. Атака подібного плану може включати в себе наступні етапи:

  • отримання жертвою електронного листа з використанням логотипу та кольорів компанії, яка надає якісь послуги (наприклад постачальника або виробника);
  • запит до жертви на виконання такої операції, як оновлення персональних даних або підтвердження пароля;
  • підключення жертви до підробленого підконтрольного зловмиснику сайту;
  • відновлення зловмисником логіну/паролів (або будь-яких інших конфіденційних даних), введених жертвою на підроблений сайт.
Іншим типом людського фактору є внутрішнє шахрайство – коли уповноважений користувач свідомо використовує свій доступ з метою шкоди безпеці організації, в якій він працює. Користувачем може бути працівник, консультант або субпідрядник. Його слід відрізняти від користувача, який надає свої дані для доступу через необережність, або через те, що він був введений в оману. Існують різні категорії шахраїв: випадковий шахрай, повторний шахрай, особа, яку навмисно наймають на здійснення шахрайства та групового шахрайства.

За матеріалами посбіника Jean-Marie Flaus. Cybersecurity of Industrial Systems. 2019
Переклад та адаптація Олександра Пупени

Рекомендуємо також прочитати Міфи про кібербезпеку систем керування.

Міфи про кібербезпеку систем керування.

опубліковано 22 груд. 2019 р., 05:12 Александр Пупена   [ оновлено 22 груд. 2019 р., 05:17 ]

    На сьогоднішній день багато українських промисловців до цих пір вважають, що проблеми  кібербезпеки в АСКТП для їх підприємств не є актуальними. Нижче ми наведемо переклад одного з параграфів книги Jean-Marie Flaus Cybersecurity of Industrial Systems 2019-го року, в якому автор дає спростування на кілька міфів. 

Чи дійсно існує ризик для промислових систем керування?

Кібер-атаки не сильно актуальні для промислових чи кіберфізичних систем.
    Це правда, що більшість атак стосуються традиційних комп'ютерних систем. Ці напади нескінченні, а інструменти для створення атак стають все більш доступними. Функціональність засобів, що використовуються організованою кіберзлочинністю, значно зросла. Що стосується промислових систем, кількість атак значно менша. Але при цьому атака часто показує, що зловмисник має спеціальні знання про цільові системи та здійснив індивідуальну атаку.
    Чи означає це, що ризик, пов'язаний з кібербезпекою промислових систем, низький? Відповідь, звичайно, - ні. Рівень ризику залежить від ступеня тяжкості ушкодження та ймовірності його виникнення. Для промислових установок чи атомних станцій збитки можуть бути катастрофічними та впливати на населення. Можливість заподіяння шкоди  принаймні є на тому ж рівні, що і для систем керування ІТ. Тому рівень ризику дуже високий. Для переконання, достатньо спостерігати за розвитком регуляторних зобов'язань, таких як LPM (Military Programming Act) у Франції, директива NIS (Network and Information Security) в Європі або Закон про захист критичних інфраструктур у США.

Система ізольована від Інтернету, тому вона безпечна.
    Тривалий час вважалося, що відсутність підключення до Інтернету є достатнім обмеженням, щоб уникнути будь-якого ризику комп'ютерного піратства. Ми іноді називаємо це міфом про «повітряний зазор». Насправді ситуація є складнішою:
  • насамперед, навіть якщо система не підключена до Інтернету, вона може стати жертвою технологічних зловмисних дій, Stuxnet - показовий цьому приклад. Вектор нападу був USB-ключ;
  • часто промислова мережа підключається до корпоративної мережі ІТ: ця ІТ-система може стати жертвою атак та розміщувати шкідливі програми, які згодом намагаються пошкодити промислові мережі, або навіть можуть забезпечити проходження атак безпосередньо через них;
  • в промисловій мережі іноді існують прямі підключення до Інтернету, більш-менш офіційні, а іноді і тимчасові, для обслуговування або конфігурації, і вони представляють реальну вразливість.
    Крім того, із зростанням потреби завантажувати дані в інформаційну систему підприємства або в Хмару, із потребою оновлення систем з сайту виробника та потребою віддаленого обслуговування ізоляція промислових систем стає все більш ілюзорною.

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

Робочі станції оснащені антивірусним програмним забезпеченням і брандмауером, тому ми захищені.
    Використання антивірусу є базовим кроком захисту. Це дозволяє захистити робочі станції комп’ютера, що працюють під Windows або macOS. Однак у промисловій системі є багато пристроїв, що працюють на операційній системі реального часу, або вбудованій системі Linux, або навіть пропрієтарній системі. Для цих систем не обов'язково існує антивірус, і вони є вразливими. Додамо також, що однією з проблем антивірусного програмного забезпечення для промислових робочих станцій є те, що воно не завжди оновлюється.
    Межі використання брандмауерів також добре відомі: перша полягає в тому, що правила фільтрації не завжди добре налаштовані; друга - навіть якщо потоки даних добре фільтруються, це не запобігає проходженню всіх атак. Як детально описано у розділі 4, система керування енергетичною станцією, яка була атакована в Україні у 2015 році, включала в себе брандмауери, які не змогли завадити атаці.

Ми використовуємо Віртуальну приватну мережу (VPN), тому у нас немає проблем.
Ще одна поширена ідея полягає в тому, що використання VPN забезпечує ефективний захист. Ця думка також помилкова з двох основних причин:
  • Перша полягає в тому, що значна кількість VPN використовує технології, які вважаються застарілими і тому є вразливими. Дослідження 2016 року (High-Tech Bridge Research Security Security 2016) показало, що 77% тестованих VPN все ще використовують протокол на основі SSLv3, створений в 1996 році, або навіть SSLv2, тоді як більшість стандартів, таких як PCI DSS або NIST SP 800-52 ( див. Розділ 6) заборонили його використання;
  • Друга причина в тому, що навіть при добре налаштованому VPN, якщо одна з робочих станцій, підключених до цих VPN, була скомпроментована (взламана), це може поставити під загрозу решту мережі, тим більше враховуючи що дані які передаються шифруються і тому їх важко фільтрувати .
Система інформаційної безпеки (ISS Information System Security) є дорогою і створює багато обмежень для ефективності функціонування.
    Поширеною є думка, що ISS є дорогими і накладають велику кількість експлуатаційних обмежень, несумісних із системами керування промисловими об’єктами. Ці обмеження виглядають все більш важливими, оскільки в АСТКП використовується дуже неоднорідне обладнання, а його користувачі цінують певну гнучкість в роботі. Наприклад, використання мобільних терміналів стає все більш поширеним, оскільки це дуже корисно для керування системами в близькості до процесу.
    Насправді ISS промислових систем повинні бути адаптовані до викликів, і важливо провести аналіз ризиків та порівняти важливість цих ризиків із вартістю заходів щодо їх зменшення та обмежень, які вони накладають. Однак безпеку часто вважають джерелом витрат, що важко виправдати рентабельністю інвестицій. Більш релевантним є її вимірювання в термінах потенційних втрат, наприклад, щодо кількості виробленої продукції при тимчасової непрацездатності системи, або витрат на реконструкцію, якщо система була пошкоджена.
    Що стосується операційних обмежень, важливо впроваджувати рішення за консультацією з користувачами та з урахуванням реальності на місцях. Ми повинні підтримувати нові режими роботи і не намагатися надмірно обмежувати можливості користувачів.

За матеріалами посбіника Jean-Marie Flaus. Cybersecurity of Industrial Systems. 2019
Переклад Олександра Пупени

Тлумачення та застосування стандарту по організації роботи тривог ANSI/ISA 18.2

опубліковано 23 трав. 2019 р., 03:14 Александр Пупена   [ оновлено 23 трав. 2019 р., 04:36 ]

Bill Hollifield, PAS Principal Alarm Management and HMI Consultant

Переклад: Альона Шишак (АКТСУ НУХТ), Олексанр Пупена (АКТСУ НУХТ)

Посилання на оригінал білої книги

Загальний огляд

За останні роки тема організації роботи тривогових систем стала предметом огляду у багатьох статтях, книгах  та на технічних симпозіумах. У 2003 році ISA розпочала розроблення стандарту по організації тривогових систем. Десяток, залучених  з різних промислових секторів, учасників робочої групи витратили десятки годин на формування стандарту. PAS приймав участь в цьому процесі як редактор та голосуючий член.

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

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

У цій білій книзі розглянуті найбільш важливі аспекти, вимоги, рекомендації та інше, що стосується  ISA-18.2. Проте, цей документ не може замінити повну версію стандарту для цілковитого його розуміння.

1. Ціль та сфера застосування

Головною задачею ISA-18.2 – є покращення безпеки. Неефективно працюючі тривогові системи часто визнавалися причиною виникнення великих технологічних аварій. Проблеми тривогових систем, які розглядає ISA-18.2 були відомі протягом майже двох десятиліть.

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

Читачі, які ознайомленні з літературою по організації тривогових систем не повинні очікувати якоїсь значно нової інформації, або такої що значно відрізняється від уже загальноприйнятої. Ключовою відмінністю є те, що ISA-18.2 – це стандарт, розроблений відповідно до ANSI методологій. Таким чином, він буде розглядатися нормативними органами як «визнана і загальноприйнята хороша інженерна практика» (RAGAGEP). Цей стандарт  знаходиться в процесі прийняття як міжнародного стандарту IEC (IEC 62682) (У 2014-му році стандарт був прийнятий. Прим. перекладача).

2. Чи слід саме Вам застосовувати ISA-18.2 ?

У центрі уваги ISA-18.2 є підсистеми тривог сучасних систем керування, таких як DCS, SCADA, PLC або систем безпеки. Стандарт впроваджується на виробництвах, де оператори реагують на сигнали тривог, які відображаються  на екранах комп'ютерного типу та/або сповіщувачах.

До таких виробництв належать:

  • нафтохімічне
  • хімічне
  • очисне
  •  електростанції
  • фармацевтичне
  • гірничодобувне

Не має значення яким є тип технологічного процесу: неперервним, рецептурним (batch) чи дискретним. Причиною такої загально прийнятності є те, що реакція на тривогу не є функцією конкретного процесу, над яким здійснюється керування, а лише залежить від людино-машинної  взаємодії. Дії які при цьому здійснюються оператором – це виявлення тривоги, аналіз ситуації та реакція на неї.

У розробленні стандарту ISA-18.2 брало участь багато представників різних промислових секторів.  Результатом стало те, що стандарт є прийнятним для різних промисловостей.

Стандарт ISA-18.2 вказує на межі тривогової системи відносно термінів, що використовуються в інших стандартах, таких як Базова система керування процесами (BPCS), система безпеки (SIS) і т.д. Перераховано декілька виключень, щоб не суперечити  іншим стандартам.

3. Регулятивний вплив

Ця біла книга не має на меті бути деталізованим тлумаченням таких регулятивних документів, як керування з охорони праці  (OSHA), Агентства з охорони навколишнього середовища США (EPA), Керування з безпеки трубопроводів і небезпечних матеріалів (PHMSA) або інших нормативних актів. Нормативне середовище є складним та поширюється на деякі промислові сегменти. Багато виробництв урегульовуються документом «Керування безпекою процесу» оприлюдненим OSHA , в якому є кілька згадувань про тривоги.  

Важливим є те, що регулятивні органи включають в свої нормативні документи пункти «загального призначення». Як приклад, розглянемо OSHA 1910.119 (d) (3) (ii), в якому стверджується, що роботодавець зобов'язаний документувати, що обладнання відповідає прийняті і загальновизнані належні інженерні практики (RAGAGEP).

Стандарти та практики, як правило, вважаються «прийнятими і загальновизнаними належними інженерними практиками». В роз’яснювальному листі OSHA до ISA, ISA-18.2 є RAGAGEP. Існує “Меморандум про домовленність” між OSHA і ANSI з цих питань.

В загальному, регульовані сектори промисловості можуть очікувати перевірки на відповідність прийнятим і загальновизнаним належним інженерним практикам (RAGAGEP) або показати,  що вони роблять щось так само добре або краще. Насправді,  OSHA  отримали дозвіл від ISA поширювати ISA-18.2 стандарт серед OSHA спостерігачів. Рада з розслідування хімічної безпеки і небезпеки США також буде використовувати ISA 18.2 у своїх розслідуваннях. Інші регуляторні органи також беруть до уваги цей стандарт.

Американський інститут нафти (API) скоро опублікує API RP-1167, Alarm Management Recommended Practices for Pipeline Systems. Цей документ API повністю узгоджується з ISA-18.2, а адміністрація з безпеки нафтопроводу та небезпечних матеріалів (PHMSA) зазвичай застосовує рекомендовану API-практику в своїй нормативній мові.

4. Наслідування

Пункт наслідування використаний іншими ISA стандартами , також використаний і в ISA-18.2.

«Для існуючих тривогових систем, які розроблені відповідно до норм, стандартів та/або практик до випуску даного стандарту, власник/оператор повинен визначити, що обладнання спроектовано, обслуговується, перевіряється, тестується та експлуатується безпечним чином. Підходи і процедури, викладені у цьому стандарті, повинні застосовуватися для існуючих систем в розумних часових інтервалах, як визначено власником/оператором.»

Два згадування слова «повинні» у цитованому тексті позначають обов’язкові для виконання вимоги. Ця цитата імітує мову, використовувану в положеннях OSHA.

5. Означення в ISA-18.2

Для того, щоб забезпечити сумісність ISA-18.2 з іншими стандартами та нормативами було проведено велику кількість роботи по дослідженню та розробці означень. Стандарт ISA-18.2 означує тривогу як «Звукові та/або візуальні засоби індикації про несправність устаткування, відхилення від процесу, ненормального режиму роботи, які потребують реакції оператора»

6. Діаграма автомату станів тривог

Стандарт ISA-18.2  включає в себе помірно складну діаграму, що відображає стани та підстани тривог: «Нормальний стан», «Неквітована» (unacknowledged), «Підтверджена» («acknowledged»), «Повернена до нормального стану але не квітована» («returned to normal unacknowledged») та «Тривоги з фіксацією» («Latched»). (У новій версії стандарту в автоматі станів немає означений станів «Latched». Прим. перекладачів)  Окремої уваги заслуговують стани «Відтермінована тривога» (“Shelved”), «Проектно-блокована тривога» (“Suppressed by Design”) та «Виведена з обслуговування» (“Out of Service”). Ці стани мають специфічні значення:

Відтермінована тривога – це тривога, яка тимчасово блокується, зазвичай вручну оператором. При цьому дотримуються різних адміністративних вимог щоб статус тривоги був відомий та відслідковувався.

Проектно-блокована тривога – це тривога навмисне блокована системою керування відповідно до алгоритму керування.

Виведена з обслуговування – це не функціонуюча тривога. У цей стан тривога зазвичай переходить внаслідок причин пов’язаних зі стадією обслуговування. Під час виведення тривоги з обслуговування також дотримуються адміністративних вимог як у випадку з відтермінованою тривогою.

Терміни «блокувати» («suppress») і «блокування тривоги» навмисне є загальними, а не специфічними для типу DCS. Вони використовуються у випадках, коли треба вказати, що тривога не буде сигналізуватися. Можливо, і, на жаль, є загальноприйнятим, блокування  тривоги поза належною практикою роботи, і виявлення таких небажаних ситуацій є частиною стадії моніторингу життєвого циклу.

7.Життєвий цикл організації роботи тривогової системи


рис.1.Життєвий цикл керування тривогами.

Стандарт ISA-18.2  означує структуру життєвого циклу, який включає 10 стадій:

  • Методологія тривог (alarm Philosophy): документує цілі тривогової системи та робочі процеси, які супроводжують досягнення цих цілей.
  • Ідентифікація (Identification): робочі процеси по означенню необхідних тривог.
  • Раціоналізація (Rationalization): процес підтвердження відповідності тривог поставленим в методології тривог вимогам. Ця стадія також включає задачі пріоритизації, класифікації, означення налаштувань тривог та документації.
  • Проектування(Detailed Design): відповідно до вимог, означених на стадіях раціоналізації та методології тривог проводиться процес проектування тривогової системи в цілому. На цій стадії приймаються рішення щодо відображення тривог на HMI, а також використовуються спеціальні техніки проектування тривог.
  • Впровадження(Implementation): розроблена тривогова система переводиться в операційний статус. Ця стадія може включати введення в експлуатацію, тестування та тренування персоналу.
  • Експлуатація (Operation): функціонування тривогової системи. Ця стадія також може включати підвищення кваліфікації персоналу.
  • Обслуговування(Maintenance): на даній стадії тривога не функціонує за причини тестування або налагоджувальних робіт.  Цю стадію не слід плутати з життєвим циклом обслуговування обладнання і їх функцій.
  • Моніторинг та оцінка (Monitoring and Assessment): Продуктивність роботи тривогової системи постійно моніториться та оцінюється відповідно до вимог, означених у документі методології тривог.
  • Керування змінами(Management of Change): відповідно до означених правил вносяться зміни до тривогової системи.
  • Аудит(Audit): проводиться періодична перевірка системи для підтримки цілісності тривогової системи і процесів організації її роботи.

7.1. Стадії життєвого циклу проти діяльностей

Не потрібно плутати стадії життєвого циклу з діяльностями. Життєвий цикл це спосіб структурування змісту усього стандарту ISA-18.2. Життєвий цикл не є конкретним або обов’язковим списком діяльностей, які необхідно провести  у означеному порядку.

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

Стадія моніторингу:  Інженер:  «Ну добре, виділю собі трохи часу на визначення хибних тривог. Які тривоги найчастіше зустрічаються у списку тривог?  Є одна така – тривога високого тиску у колоні»

Стадія Ідентифікації: Інженер: «Ах так, я пам’ятаю, що нам потрібна ця тривога для забезпечення якості; проте моя задача на сьогодні зробити так щоб ця тривога працювала правильно, а не вирішити чи взагалі потрібна нам ця тривога чи ні»

Стадія проектування: Інженер: «Перевірю налаштування цієї тривоги. Немає нічого незвичного. Хммм, я бачу, що зона нечутливості для тривоги дорівнює 0. Це точно неправильно і спричинює таку «вібруючу» поведінку тривоги. Передивлюся історію тривог і визначу найбільш підходящу зону нечутливості, користуючись хорошою книгою по організації роботи тривог»

Стадія експлуатації і обслуговування: Інженер: «Зараз я збираюся змінити налаштування зони нечутливості»

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

Стадія впровадження: Інженер: «Зараз я фактично змінюю зону нечутливості. Увожу нове значення та натискаю ‘ENTER’. Зроблено!»

Стадія раціоналізації: Інженер: «Оскільки у мене є належний доступ до безпеки, я додам цю нову настройку зони нечутливості до головної бази даних тривог, вказавши своє ім'я, дату та причину. Крім того, я зроблю примітку у щотижневому звіті по відстеженню хибних тривог. Поки я тут і дивлюся на цю тривогу,то зауважу, що вона налаштована з пріоритетом 3. Це здається розумним, але про всяк випадок перевірю головну базу даних тривог, щоб переглянути причини встановлення такого пріоритету. Хмм, вони виглядають досить добре. Якби цього не було, я б не міг самостійно змінити пріоритет. Мені потрібні спеціалісти, які займаються пріоритизацією. Операторів необхідно повідомляти про будь-які зміни пріоритету»

Стадія моніторингу: Інженер: «До моїх обов’язків входить слідкувати за даними тривоги, і переконатися в тому що зміна зони нечутливості була рішенням проблеми виникнення хибної тривоги»

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

В 2006 році, PAS опублікував «The Alarm Management Handbook», в якій пропонується визнана семи-крокова методологія для вирішення проблем функціонування тривогової системи та для досягнення ефективної організації роботи тривогової системи. Між таким семи-кроковим підходом та методологією, яка викладена у стандарті немає конфліктів; можливі відмінності  в переліку та постановці задач.

8. Стадія формування документу методології тривог

Стандарт ISA-18.2 визнає документ методології тривог ключовою вимогою для ефективної організації роботи тривогової системи. Документ методології тривог обов’язково повинен включати посадові обов’язки, означення тривоги, обґрунтування пріоритизації, керівництво для розробки HMI, показники ефективності функціонування тривогової системи, керування змінами, навчання персоналу та інше.

У стандарті не зустрічається значно нових термінів окрім «класифікація тривог» та «високоорганізовані тривоги» («highly managed alarms»).

8.1. Класифікація тривог

Класифікація тривог - це метод призначення та відстеження різних вимог до тривог, переважно адміністративних. Наприклад, деякі тривоги можуть вимагати періодичної перепідготовки персоналу, а інші - ні. Те ж саме стосується тестування, технічного обслуговування, звітності, відображення на HMI та подібних аспектів. Класи тривог використовують для відстеження цих вимог. За ISA-18.2 класи тривог необхідно означити обов'язково.

Це трохи незвична річ для стандартів. Зазвичай стандарт говорить про те, що робити, а не про те, як це робити, і не вимагає використовувати конкретний метод. Наприклад, у стандарті може стверджуватися: «Визначте та відслідковуйте тривоги, які вимагають періодичного тестування». Існує велика кількість методів, щоб успішно це реалізувати, і  класифікація – це тільки один з них. Проте комітет вирішив вимагати класифікаційну структуру, хоч вона і не повинна бути обтяжливою. Стандарт не наводить конкретних вимог до класів та не вказує мінімальну їх кількість. PAS рекомендує використовувати просту структуру класів з мінімальними варіаціями.

8.2. Високоорганізовані тривоги

Комітет вважав за необхідне чітко означити один клас тривог. Було розглянуто велику кількість різних назв означень, від «критичний» до «життєво важливого», «спеціального» та «супер-пупер». Назвою такого класу було обрано «Highly Managed Alarms» (високоорганізовані тривоги). Мета полягає в тому, щоб означити тривоги, до яких ставляться адміністративні вимоги високого рівня.

Використання цього класу не є обов’язковим. Проте, якщо в своєму документі методології тривог ви зазначаєте використання цього класу, як класу означеного стандартом, тоді ви повинні чітко документувати та дотримуватися безлічі спеціальних адміністративних вимог згідно зі стандартом.

У декількох розділах стандарту ISA-18.2 згадуються різні обов'язкові вимоги до високоорганізованих тривог. До них відносяться:

  • Специфічні вимоги до блокування тривоги, наприклад, контроль доступу з відслідковуванням та реєстрацією подій, пов’язаних з тривогою (audit trail)
  • Специфічні вимоги до «виведення з обслуговування тривоги», такі як тимчасовий захист, контроль доступу, та реєстрація подій
  • Обов’язкова первинна підготовка та перепідготовка персоналу
  • Обов’язкове первинне та періодичне тестування
  • Обов'язкове навчання щодо вимог до технічного обслуговування
  • Обов’язкові вимоги до аудиту

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

9. Специфікація технічних вимог до тривогової системи (ASRS)

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

У такому випадку ASRS стає корисним документом для тестування та приймання.

10. Стадія ідентифікації

У даному розділі стандарту ISA-18.2 відмічається, що для визначення необхідності використання деяких тривог використовуються різні методи. Всі сучасні системи керування мають багато вбудованих функцій для організації функціонування підсистеми тривог; якусь ідентифіковану тривогу можна віднести  до десятка типів тривог.

У деяких випадках можна використати один з цих доступних типів, у інших – необхідне створення специфічної тривоги з програмною логікою обробки або розрахунками. Це робиться з індивідуальних міркувань і може залежати від технологічного процесу. Такий тип тривоги може сторцюватися на основі  аналізу технологічних ризиків (PHA), аналізу рівня захисту (LOPA), аналізу збоїв та їх вплив (FMEA) і т.п.

11. Стадія раціоналізації

Ця стадія життєвого циклу включає в себе декілька діяльностей. Більшість людей, знайомих з підходами  організації роботи тривогових систем, думають про раціоналізацію як про специфічну діяльність команди, що розглядає тривогові систему та приймає рішення про використання, назначення пріоритетів, уставок тощо. У ISA-18.2 термін використовується для позначення набору діяльностей, які можуть бути виконані різними способами.

До діяльностей належать:

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

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

Цей розділ є достатньо коротким і навмисне уникає опису конкретних методів ефективної раціоналізації. Деякі приклади таких методів будуть наведені в майбутніх технічних звітах.  (Ці технічні звіти вже випущені. Прим. перекладачів)

12. Стадія базового (основного) проектування

У цьому розділі описуються загальні можливості підсистеми тривог і як вони співвідносяться з діаграмою станів тривог. У стандарті пропонується кілька порад для правильного застосування деяких типів тривог і щодо параметрів конфігурування тривог, таких як зона нечутливості та затримка.

13. Стадія розроблення людино-машинного інтерфейсу

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

У стандарті наводяться деякі аспекти:

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

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

Я думаю, що стандарт ISA-101 про HMI випуститься через кілька років. Можливо це буде технічний звіт, а не стандарт. Тим часом, якщо ви хочете отримати більш детальну інформацію про підходи до розроблення HMI, ми рекомендуємо звертатися до книги The High Performance HMI Handbook, а також ASM Consortium Guidelines for Effective Operator Display Design. (Стандарт ISA-101 був випущений в 2015-му році. Прим. перекладача)

14. Покращені та вдосконалені (прогресивні) методи організації тривог

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

До таких типів прогресивних  методів, які коротко описані у стандарті, належать наступні:

  • Інформаційні зв’язки
  • Організація тривог на основі логіки керування
  • Організація тривог на основі моделі процесу
  • Зміни атрибутів тривог
  • Зовнішньо підтримувані системи
  • Логічне блокування або зміна атрибутів тривог
  • Організація тривог у відповідності зі станом ТП
  • Організація тривог у відповідності зі станом ТП на основі його моделі
  • Віддалені сповіщення тривог (не на АРМ)
  • передача сигналів тривог по електронній почті і віддалені системи сповіщення
  • Додаткові тривогові системи
  • Постійна зміна меж уставок тривог
  • Тривоги в Batch процесах
  • Системи навчання, тестування та перевірки (аудиту)
  • Постійне спостереження за налаштуваннями тривог

15. Стадія впровадження

Цей розділ розглядає діяльності та вимоги пов’язані з впровадженням нових тривогових систем або бажаних змін у вже існуючі системи. У стандарті наводяться обов’язкові вимоги та рекомендації, що стосуються цієї стадії життєвого циклу.

До основних діяльностей належать:

  • Планування
  • Навчання користуванню новими системами чи внесеними до них змінами
  • Тестування та функціональна перевірка нових систем або модифікацій
  • Документування навчання та тестування

16. Стадія експлуатації

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

  • Процедура реагування на тривогу
  • Блокування тривог
  • Перепідготовка операторів

17. Стадія обслуговування

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

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

18. Стадія моніторингу та оцінки

На цій стадії оцінюється продуктивність роботи тривогової системи та формується відповідний звіт.

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

Обчислювати показники ефективності функціонування системи та перевіряти на відповідність значень заявлених у документі методології тривог є обов’язковим. Декілька показників для оцінки продуктивності функціонування тривогової системи описано в стандартів. Також наводиться таблиця з необов’язковими показниками ефективності.  Допустимі значення показників ефективності можуть змінюватися:

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

Показники описані у стандарті:

  • Аналіз кількості виникнення(активації) тривог за операційний період (за день, за годину, за 10 хвилин)
  • Пікова кількість виникнення тривог за операційний період
  • Потоки тривог (методи розрахунку і рекомендації)
  • Частота виникнення тривог
  • Вібруюча та швидкоплинна тривоги
  • Застарілі тривоги
  • Розподіл пріоритетів тривог
  • Несанкціоноване подавлення тривоги
  • Моніторинг параметрів тривог

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

19. Стадія керування змінами

Цей розділ наводить обов'язкові вимоги та необов'язкові рекомендації щодо внесення змін у тривогові систему.

Пункти, описані у стандарті:

  • Зміни, які підпорядковані керуванню змінами
  • Вимоги до процесу перегляду змін, включаючи розгляд технічної бази, впливу внесених змін, процедуру та документування змін, авторизації для внесення змін
  •  Підтвердження відповідності змін вимогам наведеним у документі методології тривог
  • Тимчасові зміни
  • Впровадження змін
  • Вимоги та рекомендації до документування змін
  • Рекомендації до видалення тривог
  • Вимоги та рекомендації до змін параметрів тривог

20. Стадія аудиту

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

21. Висновки.

ISA-18.2 є важливим стандартом і, безумовно, призведе до значного підвищення безпеки на підприємствах переробної промисловості. Стандарт підтверджує і описує найкращі практики, які промислові експерти та провідні компанії-виробники відстоюють протягом багатьох років. Публікація ISA-18.2 має суттєві регуляторні наслідки, і компаніям рекомендується ознайомитися з її змістом.

 

Післямова (від перекладачів)

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

На сьогоднішній день ISA-18.2 вже існує в 2-й редакції. Крім того, цей стандарт прийнятий також як IEC 62682, що робить його застосовним у всьому світі, у тому числі це може бути зроблено в Україні (завдання для комітету ТК-185).  Крім ISA-18.2 вийшло ряд технічних звітів, які деталізують окремі стадії та етапи життєвого циклу організації тривогової системи:

·         ISA-TR18.2.1-2018 - Alarm Philosophy

·         ISA-TR18.2.2-2016 - Alarm Identification and Rationalization

·         ISA-TR18.2.3-2015 - Basic Alarm Design

·         ISA-TR18.2.4-2012 - Enhanced and Advanced Alarm Methods

·         ISA-TR18.2.5-2012 - Alarm System Monitoring, Assessment, and Auditing

·         ISA-TR18.2.6-2012 - Alarm Systems for Batch and Discrete Processes

·         ISA-TR18.2.7-2017 - Alarm Management When Utilizing Packaged Systems

Ми сподіваємося, що ця біла книга спонукатиме спеціалістів з автоматизації принаймні ознайомитися з стандартом ISA-18.2. Окрім того, важливим стандартом також є ISA-101, який направлений на розробку та експлуатацію ЛМІ. По темі SCADA/HMI також доступні наступні матеріали українською мовою: відео вебінару від PAS, який був перекладений та озвучений в стінах кафедри АКТСУ та матеріали ТДА. На даний момент йде підготовка навчального посібника по SCADA/HMI, куди окремим розділом увійде Alarm Management.

   

 

 

 

 

 

 

 

 

 

 

Перепрошивка TSX Premium з PL7 PRO на Unity PRO (відео)

опубліковано 3 лист. 2018 р., 11:18 Александр Пупена

Після оновлення лабораторної бази Шнейдер Електрик, відпала необхідність у старому програмному забезпеченні PL7 PRO, що використовувалися для програмування ПЛК TSX Micro та TSX Premium. Хоч обладнання 90-х ніхто не збирається утилізовувати :) (нам ще й старенькі TSX Nano в нагоді ставали), деякий хард 2000-х, а саме TSX Premium ще може згодитися для навчального процесу. Було вирішено два ЦПУ TSX Premium перепрошити під сучасний софт Unity PRO (щоб робочих стало чотири замість двох).

Сказано – зроблено! Дмитро Мацебула взявся за справу, а Володимир Полупан взявся за документування цього процесу. Що з цього вийшло – дивіться на відео! Може комусь знадобиться, може у вас теж завалявся подібний TSX Premium.    

 

Керування періодичними процесами та виробництвами на базі сучасних технологій та стандартів (ISA-88)

опубліковано 12 січ. 2017 р., 22:32 Александр Пупена

Доступні відеоматеріали та презентації з семінара-конференції ТДА16-2, який проходив 1.10.2016 в НУХТ.
За цими матеріалами можна отримати багато інформації щодо керування періодичними (batch) виробництвами.  

Індустрія 4.0 – 4-та Індустріальна Революція

опубліковано 9 бер. 2016 р., 23:53 Александр Пупена   [ оновлено 9 бер. 2016 р., 23:54 ]

На Світовому Економічному Форумі 2016 в Давосі оголосили: «Четверта Індустріальна Революція» розпочалася. Німецький Уряд заявив: «Arbeiten, громадяни, будуємо Індустрію 4.0!». А американці і різного роду стартапери вже декілька років стверджують, що настає ера «Інтернету всього на світі». Китайці стверджують: «де криза, там і можливості». Спробуємо розібратись в темі і пошукати можливості для українських інженерів і бізнесу.
Читати далі

Електронний посібник по стандарту ISA S88.01

опубліковано 5 січ. 2016 р., 07:30 Александр Пупена

Сьогодні інтегроване виробництво не може обійтись без знань міжнародних стандартів, в яких відображаються кращі практики проектування, створення та експлуатації таких систем. Серед таких стандартів для систем MES дуже актуальними є ISA-88 та ISA-95.
Вашій увазі пропонується переклад електронного посібника (теж в електронному вигляді) з назвою "S88.01 Tutorial", в якому доступною мовою розповідається про основи стандарту ISA S88. Переклад зроблено співробітником нашої кафедри.
 
Приємного чтива!
 
 

1-10 of 30