Злиття операційних технологій (OT) та інформаційних технологій (IT) створює нові можливості для моніторингу та автоматизації, але водночас значно розширює поверхню атаки та ускладнює управління кібербезпекою. Для CISO та операційних команд інтеграція подій від SCADA (Supervisory Control and Data Acquisition) та BMS (Building Management Systems) у єдиний Security Operations Center (SOC) є стратегічним кроком. Проте без чітких критеріїв відбору та механізмів обробки, цей процес може перетворитися на джерело шуму, що загрожує ефективності реагування на реальні загрози.
Виклики інтеграції OT/IT подій: чому «все» — це забагато
Традиційні IT-системи та OT-середовища мають фундаментальні відмінності. Якщо для IT пріоритетом є конфіденційність, то для OT — доступність, безпека та надійність. Системи SCADA та BMS часто працюють 24/7, містять застарілі пристрої, які важко оновлювати або перезавантажувати, та критично важливі для фізичних процесів. Будь-який простій може призвести до фізичних пошкоджень, шкоди навколишньому середовищу або навіть людських жертв.
Спроба інтегрувати всі події з OT-систем у SOC призводить до так званої «втоми від тривог» (alert fatigue). Аналітики SOC перевантажені величезною кількістю сповіщень, багато з яких є хибними спрацьовуваннями або низькопріоритетними. Це призводить до уповільнення часу реагування, пропущених загроз та вигорання персоналу. Дослідження показують, що з тисяч щоденних сповіщень близько 83% виявляються хибними тривогами, і лише невелика частина є реальними загрозами. У результаті якість розслідувань знижується, а критичні інциденти можуть бути проігноровані.
Крім того, відсутність єдиних протоколів та форматів даних між різними виробниками SCADA/BMS систем ускладнює інтеграцію. Застарілі RTU/PLC можуть використовувати власні діалекти та зберігати дані у несумісних форматах, що вимагає складних перетворень та шлюзів.
Критерії відбору критичних подій: що дійсно має значення для безпеки
Для ефективної інтеграції необхідно зосередитися на подіях, які мають пряме відношення до кібербезпеки та операційної стійкості. CISA (Cybersecurity and Infrastructure Security Agency) та NIST (National Institute of Standards and Technology) надають рекомендації щодо моніторингу OT-систем, які допомагають визначити пріоритети. Зокрема, CISA Cybersecurity Performance Goals (CPG 2.0) пропонує єдиний набір цілей для критичної інфраструктури, що охоплює як IT, так і OT середовища.
Критичні події для SOC включають:
- Несанкціонований доступ та зміни конфігурації: Спроби несанкціонованого доступу до контролерів, HMI (Human-Machine Interface), зміни логіки PLC або конфігурацій SCADA.
- Аномальна поведінка пристроїв/мережі: Незвичайні показання датчиків, відключення сенсорів, аномальний мережевий трафік між OT-сегментами, несанкціоновані з'єднання.
- Спроби зміни прошивки або програмного забезпечення: Будь-які спроби оновлення або зміни прошивки пристроїв OT без належного дозволу.
- Індикатори компрометації (IoC): Події, що відповідають відомим тактикам, технікам та процедурам (TTP) зловмисників, описаним у фреймворках, таких як MITRE ATT&CK for ICS.
- Події, що впливають на безпеку та навколишнє середовище: Будь-які події, що можуть призвести до фізичної шкоди, екологічних катастроф або зупинки критичних виробничих процесів.
- Помилки автентифікації та авторизації: Багаторазові невдалі спроби входу, використання облікових записів за замовчуванням, спроби підвищення привілеїв.
NIST SP 800-82 Revision 3, «Guide to Operational Technology (OT) Security», рекомендує підхід до управління ризиками, заснований на наслідках, де найвищий пріоритет надається сценаріям, що можуть спричинити фізичну шкоду або відмову систем безпеки.
Нормалізація та збагачення контекстом: від сирих даних до дієвої інформації
Сирі дані від SCADA та BMS систем часто не містять достатнього контексту для швидкого аналізу в SOC. Нормалізація подій до єдиного формату (наприклад, Syslog, CEF, LEEF) та збагачення їх додатковою інформацією є критично важливими.
Збагачення контекстом означає додавання до події таких даних, як:
- Критичність активу: Чи є пристрій, що генерує подію, критично важливим для виробничого процесу або безпеки?
- Місцезнаходження: Де розташований пристрій (цех, будівля, лінія)?
- Власник/Відповідальний підрозділ: Яка команда або особа відповідає за цей актив?
- Тип системи: SCADA, BMS, система пожежної безпеки, контроль доступу тощо.
- Пов'язані вразливості: Чи є відомі вразливості для цього типу пристрою або програмного забезпечення?
- Ідентифікатори користувачів: Хто здійснив дію, що призвела до події (інтеграція з IAM/Active Directory).
Інтеграція з CMDB (Configuration Management Database), системами управління ідентифікацією та доступом (IAM), а також інвентаризаційними системами дозволяє автоматично збагачувати події та надавати аналітикам SOC повну картину інциденту. Це прискорює розслідування та дозволяє швидше визначити потенційний вплив події.
Визначення відповідальності та процедур реагування: хто і як діє
Конвергенція IT та OT вимагає чіткого визначення ролей та відповідальності для реагування на інциденти. Відсутність таких протоколів може призвести до затримок та конфліктів між IT та OT командами.
Ключові аспекти:
- Матриця RACI: Розробка матриці RACI (Responsible, Accountable, Consulted, Informed) для інцидентів кібербезпеки, що стосуються OT/BMS.
- Спільні плани реагування: Створення єдиних планів реагування на інциденти, які враховують специфіку OT-систем, включаючи пріоритет безпеки та доступності. CISA рекомендує щорічно проводити навчання та оновлювати плани реагування.
- Комунікаційні канали: Забезпечення чітких каналів зв'язку між SOC, інженерними, операційними та безпековими командами.
- SLA для OT-інцидентів: Визначення угод про рівень обслуговування (SLA) для реагування на інциденти в OT-середовищах, враховуючи їхню критичність.
- Навчання та крос-функціональні команди: Навчання як IT, так і OT команд ризикам конвергенції та специфіці реагування.
Такі ініціативи, як ICS4ICS (Incident Command System for Industrial Control Systems), розроблені ISAGCA спільно з CISA, пропонують структурований підхід до управління інцидентами в ICS, що базується на перевірених системах реагування на надзвичайні ситуації.
Практичний чекліст для CISO: які події SCADA/BMS інтегрувати в SOC
Для CISO та операційних керівників критично важливо мати чіткий механізм для прийняття рішення про інтеграцію подій. Цей чекліст допоможе систематизувати процес відбору та пріоритизації:
| Критерій | Так/Ні | Коментарі |
|---|---|---|
| Чи подія вказує на потенційну загрозу кібербезпеці (наприклад, несанкціонований доступ, зміна конфігурації, аномальна поведінка)? | Приклад: спроба зміни логіки PLC, несанкціонований вхід до HMI. | |
| Чи впливає подія на безпеку персоналу або навколишнього середовища? | Приклад: критичне відхилення температури, тиску, рівня. | |
| Чи може подія призвести до зупинки критичних виробничих процесів або значних фінансових втрат? | Приклад: відключення основного виробничого обладнання, несправність системи охолодження. | |
| Чи є подія індикатором компрометації (IoC) згідно з відомими фреймворками (наприклад, MITRE ATT&CK for ICS)? | Приклад: виявлення відомого шкідливого програмного забезпечення, нетипові мережеві з'єднання. | |
| Чи має подія чіткий контекст, який дозволяє SOC-аналітику швидко зрозуміти її суть та потенційний вплив? | Чи можливо збагатити подію даними про актив, його критичність та місцезнаходження? | |
| Чи можливо автоматично нормалізувати та збагатити цю подію для інтеграції в SIEM? | Оцінка технічної можливості та зусиль для інтеграції. | |
| Чи визначено відповідальний підрозділ та процедуру реагування на цю подію? | Чи є чіткий власник інциденту та план дій? | |
| Чи є можливість фільтрувати «шумові» події, залишаючи лише критичні? | Використання правил кореляції та порогових значень. | |
| Чи є подія унікальною та не дублюється іншими джерелами моніторингу? | Уникнення надмірності даних. | |
| Яка вартість інтеграції та моніторингу цієї події порівняно з потенційним ризиком? | Аналіз витрат та вигод. |
Як це реалізує AZIOT
Платформа AZIOT розроблена для вирішення викликів інтеграції OT/IT, забезпечуючи централізований збір та обробку даних від різноманітних протоколів, таких як MQTT, Modbus, BACnet, KNX, SCADA та BMS. Завдяки можливостям edge processing, AZIOT дозволяє фільтрувати та попередньо обробляти телеметрію на місці, зменшуючи обсяг даних, що передаються до центрального SOC, та мінімізуючи «шум». Використання правил та сценаріїв дозволяє автоматично нормалізувати події та збагачувати їх контекстом, що критично важливо для швидкого та релевантного реагування. Системи аудиту та контролю доступу Unity Base гарантують, що лише авторизовані користувачі мають доступ до критичних даних та функцій, підтримуючи принципи найменших привілеїв та нульової довіри. Архітектори корпоративних систем, такі як Сергій Бойко, можуть використовувати ці принципи для проєктування інтеграційних рішень, що зводять розрізнені OT/BMS системи в кероване ціле, забезпечуючи ефективний моніторинг та реагування на інциденти кібербезпеки в SOC.
Ефективна інтеграція SCADA та BMS подій у SOC — це не просто технічне завдання, а стратегічне рішення, що вимагає глибокого розуміння як IT, так і OT середовищ. Зосереджуючись на критичних подіях, забезпечуючи їх нормалізацію та контекстуалізацію, а також чітко визначаючи відповідальність, організації можуть побудувати стійку систему кібербезпеки, яка захищає фізичні активи та забезпечує безперервність операцій. Це дозволяє перейти від реактивного до проактивного захисту, мінімізуючи ризики та оптимізуючи ресурси SOC.
Дізнайтеся більше про рішення Intecracy на Intecracy solutions та inbase.com.ua solutions.
Перелік джерел
- ucertify.comICS Incident Response and Risk Management for Industrial Security
- sans.orgICS/OT Incident Response: A Guide to Industrial Cyber Resilience | SANS Institute
- sans.orgA Guide to OT Security Best Practices | SANS Institute
- opsiocloud.com
- rapid7.comWhat Is Alert Fatigue in Cybersecurity? | Rapid7
- lrqa.comWhat is alarm fatigue in cyber security? | LRQALogoCloseSearch open
- corelight.comThe key to alleviating alert fatigue in cybersecurity - Corelight
- prophetsecurity.aiAlert Fatigue in Cybersecurity: Why Tuning Isn’t Enough Anymore | Prophet Security