Обслуживайте ПО на протяжении всего срока использования

Назначьте ответственного за обслуживание сервиса

Полезное ПО продолжает меняться после первого релиза. Зависимости получают исправления. Поддержка сред выполнения заканчивается. Срок действия сертификатов истекает. Бизнес-правила меняются. Доступ, выданный при настройке, может сохраниться дольше, чем планировалось.

Ведите учёт сервисов, ответственных, развёрнутых версий, зависимостей и сроков поддержки. Учитывайте плановую работу и работу по новым обнаруженным проблемам. Выделяйте ресурсы на обе. Backlog обслуживания без ответственного не защищает сервис.

Отделяйте обслуживание от немедленного реагирования на инциденты. Раскрытые учётные данные или признаки активной компрометации могут потребовать локализации угрозы до завершения обычного цикла разработки. Передавайте такие случаи в процесс реагирования на инциденты безопасности.

Определяйте приоритет по реальной подверженности риску

Серьёзность описывает возможные последствия. Приоритет также зависит от эксплуатации уязвимости, её достижимости, данных, существующих мер защиты и цены задержки. Даже внутренний сервис с небольшим трафиком может хранить важные учётные данные.

Каталог Known Exploited Vulnerabilities агентства CISA содержит уязвимости с доказательствами эксплуатации. Используйте его как один из источников для расстановки приоритетов. Отсутствие уязвимости в этом каталоге не доказывает, что она безопасна. Каталог CISA.

Рассмотрим вымышленные проблемы. Сроки относятся к организации из примера и не являются универсальными.

Не превращайте автоматически каждую проблему в крупное обновление. Выберите поддерживаемое исправление, проверьте совместимость и нужное поведение. Для временных мер снижения риска укажите ответственного и условие прекращения действия.

Проследите исправление до production

Используйте прослеживаемую последовательность: обнаруженная проблема, решение, изменение, review, deployment и проверка. Зафиксируйте идентификатор артефакта, который действительно используется в production. После изменения повторно просканируйте нужный артефакт или среду.

В вымышленном примере уязвимого PDF-пакета команда выполняет merge обновления в 10:00. В 11:00 в production всё ещё работает вчерашний образ. Исправление репозитория завершено. Устранение уязвимости в production не завершено.

После deployment проверьте версию пакета и генерацию PDF. Сканирование уязвимостей не подтверждает, что экспорт по-прежнему работает. Функциональный тест не подтверждает, что уязвимый компонент удалён.

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

Указывайте ограничения автоматизации

Taiga Maintaining сканирует связанные репозитории и может превращать обнаруженные проблемы в инициативы по исправлению. Проверяйте последнее успешное сканирование, затронутую версию и полученное изменение. Сканирование репозитория не устанавливает достижимость уязвимости в production. Maintaining.

Автоматизация может уменьшить повторяющуюся работу, но сервису по-прежнему нужны ответственный за deployment и проверка. Явно определяйте решения о релизе, экстренный доступ и срок действия исключений.

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

Следующий урок подробно рассматривает непрерывное сканирование уязвимостей и их устранение.