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

1. Вступ

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

2. Мета

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

3. Обсяг дії політики

Охоплює інциденти безпеки, пов’язані з кодовою базою DeskCamera, середовищем збирання, сторонніми залежностями, системами дистрибуції та внутрішніми інструментами розробки.

4. Типи інцидентів

• Несанкціонований доступ до репозиторіїв з кодом
• Компрометація сертифікатів підпису або середовища збирання
• Уразливості в ланцюжку постачання (3rd party бібліотеки)
• Некоректні налаштування, що впливають на цілісність інсталяційних файлів
• Уразливості в інструментах, які використовуються протягом життєвого циклу розробки ПЗ (SDLC)

5. Ролі та відповідальність

• CTO – контролює процес реагування та затверджує критичні дії
• Команда розробки – аналізує технічні деталі, вносить виправлення в код, відновлює системи
• Керівник з безпеки – координує розслідування, веде журнали подій, забезпечує комунікацію

6. Процес обробки інцидентів

6.1. Ідентифікація

• Автоматичний моніторинг CVE через стрічки безпеки
• Ручні рев’ю коду та виявлення аномалій під час рутинних операцій

6.2. Оцінка

• Класифікація інциденту за рівнем критичності (Critical, High, Medium, Low)
• Перевірка, чи вплинув інцидент на розповсюджене ПЗ

6.3. Ізоляція та мінімізація наслідків

• Негайне відкликання скомпрометованих облікових даних
• Ізоляція уражених середовищ або pipeline
• Усунення або оновлення уразливих сторонніх бібліотек

6.4. Відновлення

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

7. Комунікація

• Внутрішня: всі інциденти фіксуються та передаються керівництву
• Зовнішня: клієнти інформуються протягом 24 годин лише у разі порушення цілісності поширюваних збірок або механізмів оновлення

8. Аналіз після інциденту

• Аналіз першопричини протягом 5 робочих днів
• За потреби — оновлення процедур безпеки
• Інцидент документується і використовується під час щорічного навчання з безпеки

9. Перегляд і тестування

• Політика переглядається щороку CTO
• Внутрішні навчальні симуляції з реагування на інциденти проводяться періодично