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

1. Введение

Данный документ описывает политику реагирования на инциденты для приложения DeskCamera. DeskCamera — это локальное приложение для трансляции экрана, предназначенное для работы внутри локальной сети клиента. Оно не предоставляет облачных сервисов, не хранит и не обрабатывает пользовательские данные и не передаёт никакой информации на серверы DeskCamera.

2. Цель

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

3. Область применения

Политика охватывает инциденты безопасности, связанные с кодовой базой DeskCamera, процессом сборки, сторонними зависимостями, системами распространения и внутренними инструментами разработки.

4. Типы инцидентов

• Несанкционированный доступ к репозиториям кода
• Компрометация сертификатов подписи или среды сборки
• Уязвимости в цепочке поставок (библиотеки сторонних разработчиков)
• Ошибки конфигурации, влияющие на целостность установщиков
• Уязвимости в инструментах, используемых в процессе разработки ПО (SDLC)

5. Роли и обязанности

• CTO — контролирует процесс реагирования и утверждает критические действия
• Команда разработки — анализирует технические детали, вносит исправления в код и восстанавливает системы
• Ответственный за безопасность — координирует расследования, ведёт журналы и обеспечивает коммуникацию

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

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

• Автоматический мониторинг CVE (Common Vulnerabilities and Exposures) через ленты безопасности
• Ручные проверки кода и выявление аномалий в ходе повседневной работы

6.2. Оценка

• Классификация по уровню критичности (Критический, Высокий, Средний, Низкий)
• Проверка, затронуто ли распространяемое ПО

6.3. Изоляция и смягчение последствий

• Немедленное аннулирование скомпрометированных учётных данных
• Изоляция затронутых сред или процессов
• Удаление или исправление уязвимых сторонних библиотек

6.4. Восстановление

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

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

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

8. Разбор инцидента

• Анализ первопричины в течение 5 рабочих дней
• При необходимости — обновление процедур безопасности
• Отчёт об инциденте хранится внутри компании и используется в ежегодном обучении по безопасности

9. Пересмотр и тестирование

• Политика пересматривается ежегодно CTO
• Периодически проводятся внутренние тренировки по реагированию на инциденты