В середовищах OT (операційних технологій) словосполучення «тестування на проникнення» викликає в більшості керівників однакову реакцію: «Чи не зупинить це виробництво?» Без належного планування — так, це ризиковано. Натомість за правильної методології результат протилежний: реальні шляхи атак, здатних зупинити виробництво, виявляються контрольовано і знижується найдорожчий для підприємства ризик — незапланований простій.

Відмінність OT від IT полягає ось у чому: в IT вразливість часто означає «витік даних». В OT ж вразливість безпосередньо пов’язана з фізичним процесом та безпекою людей . Помилкова команда, надіслана до PLC, маніпулювання екраном HMI, «непомітна» зміна параметрів технологічного процесу — усе це погіршує якість, прискорює зношування обладнання й навіть може призвести до аварії. Тому тестування на проникнення в OT не зводиться до агресивного сканування портів і застосування експлойтів до всього підряд. Реальні умови на виробництві визначають його проведення: межі доступу, вікна технічного обслуговування, виробничі зміни, захисні блокування, план повернення до попереднього стану та виважені перевірки.

Загрозливий сценарій починається так: технік підрядної організації після завершення робіт забуває вимкнути «тимчасовий» обліковий запис VPN, який використовувався для віддаленого підключення. До того ж пароль легко вгадати — наприклад, «Oskon2025!». Зловмисник отримує контроль над цим обліковим записом і через VPN потрапляє до мережі OT. На проміжному сервері доступу в DMZ працює неоновлена служба. Звідти він шляхом бічного переміщення переходить до мережі керування. Його мета — не «здійняти галас», а змінити параметри так, щоб виробництво зупинилося через кілька годин: температурні межі, налаштування PID, швидкості обертання двигунів… На перший погляд усе виглядає нормально. Якість продукції падає, кількість браку зростає, підшипники нагріваються, витрати на обслуговування стрімко збільшуються. У цей момент ніхто не каже «кібератака» — кажуть «збій у роботі». Саме це і є найнебезпечнішим проявом атак на OT: непомітний саботаж.

Мета тестування на проникнення в OT — на підставі доказів визначити, яка ланка цього ланцюга є слабкою. Якісне тестування охоплює:

  • Обсяг і межі безпечного проведення: Межі тестування, що не створюють ризику для виробництва, часові вікна, перелік систем, у роботу яких втручатися заборонено.

  • Аналіз шляхів доступу: VPN, RDP, віддалений інженерний доступ, модеми, доступ постачальників, мости Wi-Fi, комутатори на виробничих ділянках.

  • Перевірки ідентифікації та прав доступу: Відсутність MFA, спільні облікові записи, паролі, жорстко задані в коді, варіанти «admin/admin», недоліки інтеграції з AD/LDAP.

  • Сегментація та правила передавання трафіку: Плоска мережа, правила міжмережевого екрана, що дозволяють з’єднання «звідусіль усюди», з’єднання між OT та IT.

  • Безпека протоколів і служб: Поверхні атаки, пов’язані з Modbus, DNP3, S7, OPC (класичним), RDP, SMB, VNC; контрольовані перевірки без створення аномалій.

  • Видимість і журналювання: Чи залишаються сліди подій? Чи не є середовище OT сліпою зоною для SIEM/SOC? Чи є синхронізація часу (NTP)?

Результат тестування — це не лише «перелік виявлених недоліків». В OT найціннішим результатом є шлях атаки та його опис: «Точка входу — тут, подальший перехід — тут, під вплив потрапляє цей актив, а наслідок — ось такий». Саме це найпереконливіше для керівництва: ризик перестає бути «теоретичним» і перетворюється на сценарій втрат для бізнесу . Наприклад, простій тривалістю 2 години, втрата X тонн продукції, штраф за SLA, понаднормова робота зміни, перевитрата матеріалів… За такої картини бюджет стає не «витратами на безпеку», а «інвестицією в запобігання витратам через простої».

На завершення: тестування на проникнення в OT, проведене належною командою, за контрольованою методикою та з якісним плануванням, виявляє «сліпі зони» підприємства. Зловмисник діятиме не хаотично й галасливо, а терпляче . Вам потрібно виявити ці слабкі місця першими.