Кібербезпека систем з високим ризиком - А.Войтова, Ю.Федоренко, А.Мартиненко, О.Шеметов, В.Балашов

Конспект панельної дискусії "Кібербезпека в критичних системах: досвід держави та приватного сектору"

Тема та контекст:
Панельна дискусія на IT-конференції, присвячена кібербезпеці в високоризикових системах, особливо в оборонному секторі України. Модератор — Юрій Федоренко (Engineering Manager, Макпо). Учасники: Олег Шеметов (полковник, керівник експертної групи політик інформаційної та кібербезпеки Міністерства оборони України), Артем Мартиненко (архітектор Delta, Центр інновацій МОУ), Анастасія Войтова (Head of Security Engineering, Cossack Labs) та Віталій Балашов (заступник міністра цифрової трансформації з питань кібербезпеки та хмар). Обговорювалися підходи, виклики та практики вбудовування безпеки в критичні для держави продукти.

Ключові тези:

1. Контекст визначає пріоритет безпеки. Безпека — це non-functional requirement, важливість якого залежить від профілю ризиків і моделі загроз продукту. Для «Instagram для котиків» безпека може бути не першим пріоритетом, тоді як для бойових інформаційних систем, де на кону життя (наприклад, Delta), — це один з топ-пріоритетів.
2. Джерела вимог до безпеки комплексні. На них впливають: нормативка (регуляторні вимоги, комплаєнс), вимоги стейкхолдерів (у тому числі користувачів, яким це важливо), внутрішня культура команди, здоровый глузд та ризик-менеджмент.
3. «Shift Left» — ключовий принцип. Запобігання проблемам шляхом інтеграції безпеки на ранніх етапах життєвого циклу розробки (SDLC) — від дизайну та архітектури (через ADR — Architecture Decision Records) до код-рев’ю — значно ефективніше і дешевше, ніж усунення наслідків.
4. Безпека не повинна суттєво гальмувати розробку. Якщо безпека значно сповільнює процес, це ознака її поганої інтеграції в робочі процеси. При правильному підході вона стає їх природною частиною.
5. Мотивація команди розробки — критично важлива. Безпеку потрібно «продавати» розробникам:
   • Показуючи її цінність і вплив (особливо в оборонному контексті).
   • Створюючи позитивний зворотний зв’язок (наприклад, через measurable security — відстеження прогресу за чеклістами на кшталт OWASP ASVS).
   • Роблячи безпекові задачі цікавими інженерними викликами.
   • Залучаючи Security Champions — зацікавлених розробників у команді, які промоють імплементують безпеку.
6. Роль держави та регуляцій. Україна переживає переломний етап, коли держава дедалі більше починає регулювати сферу кібербезпеки. Це може бути допомогою для команд, оскільки формалізує вимоги. Однак часто командам доводиться працювати в областях, де стандартів ще не існує (наприклад, UA Drone ID), і їх потрібно розробляти з нуля.
7. Комплаєнс потребує «перекладачів». Розуміння регуляторних вимог часто вимагає спільної роботи юристів, compliance-офіцерів та інженерів для «перекладу» з юридичної на технічну мову.

Технічні деталі та згадані практики:

• Процеси в Delta (МОУ): Впроваджено процеси Security Review на основі класифікації даних та оцінки ризиків. Фічі, що стосуються критичних даних аутентифікації, авторизації, інтеграцій, обов’язково проходять перевірку безпековою командою. Використовуються ADR для фіксації архітектурних рішень.
• Security Champions: Практика залучення розробників у команді, які на частину часу беруть на себе функції просування та імплементації безпекових практик.
• Measurable Security: Використання стандартизованих чеклістів (наприклад, OWASP ASVS, MASVS) для оцінки та візуалізації прогресу в безпеці продукту.
• UA Drone ID: Приклад проекту, де доводиться розробляти стандарти безпеки та ідентифікації для дронів з нуля, оскільки готових регуляцій під конкретні юзкейси ще не існує.
• Інструменти: MDM (Mobile Device Management) для захисту кінцевих пристроїв, UTM (Unmanned Traffic Management) для управління повітряним рухом дронів.

Практичні поради від спікерів:

1. Оцінюйте ризики. Будьте risk-oriented. Вкладайте ресурси в безпеку там, де це найкритичніше для вашого продукту та бізнесу.
2. Думайте про безпеку з самого початку. Чим раніше в SDLC ви задумаєтесь про безпеку, тим менше болю і витрат це принесе згодом.
3. Будуйте культуру, а не лише функцію. Безпека має стати частиною мислення та цінностей команди, а не лише набором правил, які хтось нав'язує.
4. Не ігноруйте людський фактор. Кінцевий користувач і його пристрій часто є найслабшою ланкою. Інвестуйте в їх захист (навчання, MDM, апаратні ключі).
5. Не бійтеся регуляцій. Комплаєнс може бути зовнішнім драйвером і чітким орієнтиром. Навчіться читати та інтерпретувати вимоги.
6. Виділяйте фахівців. На певному масштабі проекту (особливо в критичних системах) неможливо обійтися без виділених фахівців з кібербезпеки. Це окремий глибокий домен знань.

Дискусійні моменти:

• Швидкий реліз vs. безпека. Спікери погодились, що це питання контексту. Іноді швидкий реліз може бути важливішим, але це рішення має прийматися з огляду на оцінку ризиків, а не автоматично. В оборонному секторі таке малоймовірне.
• Чи сповільнює безпека розробку? Віталій Балашов категорично не погоджується. Якщо безпека суттєво сповільнює процес, це ознака її поганої інтеграції в процеси розробки (не-агільний підхід).
• Чи можна обійтися без виділеного спеціаліста з безпеки? Для маленьких стартапів або непріоритетних продуктів — можна (наприклад, через Security Champion). Для великих, критичних або регульованих систем — ні. Кібербезпека — це окрема індустрія з глибокими доменними знаннями.
• Переоцінена роль кібербезпеки? Модератор Юрій Федоренко висловив думку, що часто достатньо базових практик (Cloudflare, 2FA, перевірені бібліотеки). Спікери відповіли, що це справедливо лише для продуктів з низьким профілем ризиків. У системах, де на кону життя (оборона, медицина), безпека не може бути другорядним питанням.