Клиент требует управление уязвимостями по стандартам BSI: что конкретно внедрять в Германии?

Небольшие команды часто пугаются одной аббревиатуры BSI и тонут в сотнях страниц документации IT-Grundschutz. Заказчику в 90% случаев нужен не сам бумажный сертификат, а подтверждение того, что процессы реально работают. Если в договоре нет прямого пункта про ISO 27001 или аудит от BSI сделайте регламент, приложите отчеты сканера и не сливайте бюджет впустую.

Чтобы упростить себе жизнь технически, прикрутите сканеры зависимостей в CI/CD и сканер уязвимостей на уровне ОС. Настройте вебхук, чтобы найденные CVE сразу падали тикетами в таск-трекер, и админу не придется вести списки руками. Аудиторы BSI обожают искать теневые неучтенные серверы, так что заведите под сканирование абсолютно все поддомены и машины.

Мы под аналогичный госконтракт взяли лицензию на сканер за 2.200 EUR в год. На развертывание и настройку ушло около 3 недель. Сисадмин тратит 2 часа по понедельникам на мониторинг рассылок BSI и CERT плюс часов 6 в месяц на отчеты. В таком режиме без сучка и задоринки прошли уже два клиентских аудита.

Самое быстрое, что можно сделать уже завтра: 1) Свести список серверов и библиотек в понятную таблицу. 2) Подписаться на бесплатную рассылку CERT-Bund. 3) Набросать на две страницы политику безопасности со сроками накатки патчей и подписать её внутри компании. Заказчик на аудите первым делом эту бумажку и спросит.

Сталкивались ровно с таким же требованием на медицинском софтверном тендере в Мюнхене. На первом же аудите нас спросили: «В прошлом месяце вылезла критическая уязвимость ядра, за сколько закрыли и где логи?». Мы-то на прод патч выкатили за 4 часа, но тикет не завели и время не зафиксировали, за что и схлопотали замечание. Тут вся фишка реально в дотошном логировании.

Заказчик в ТЗ напрямую ссылается на модуль BSI IT-Grundschutz OPS.1.1.3 (Patch- und Änderungsmanagement)? Если этот блок обязателен, вам придётся жестко увязать управление изменениями (Change Management) с процессом аппрува патчей.

мы через похожее проходили прикрутите к гиту ботов для автоматического поиска уязвимостей потом пусть сканят либы на каждом билде. заказчику даже обычной блок-схемы хватает мол, пока на теесте всё зеленое не загорится, в прод ничего не катим.

Поскольку ваш заказчик связан с госсектором, он обязан закрепить соблюдение стандартов BSI в договоре субподряда. В подготовленную вами документацию должны входить матрица ответственности (RACI), регламент экстренного патчинга и обязательство проходить ежегодный внешний аудит. Критически важно, чтобы эти документы были утверждены руководством компании.

Здесь нужно провести различие. Время обнаружения проблемы напрямую определяет ее стоимость.

На этом всё, извините, если затянул.

А как вы решили этот вопрос? Главное не цифра а то, на основе чего она получена.

Извините, но это верно не во всех случаях. Большинство инцидентов начинается не с уязвимости, а с украденного пароля.

Удачи.

Я долго занимался этим вопросом. Все, кто торопится с управление уязвимостями bsi, спотыкаются на одном и том же.

Буду рад, если напишете о результате. Начните с небольшого эксперимента, не привязывайте всё сразу.

Оставлю как заметку, пригодится.

Слежу за темой.

Есть момент, который я не понял. Автоматический отчет о сканировании и пентест — это не одно и то же.

Удачи.

Именно так. Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

Если напишете результат здесь, это поможет и другим.

Обсуждение размылось, давайте структурируем. Если делаете впервые, начните с малого, масштабирование потом.

Ответ сильно зависит от отрасли универсального правила нет. Надеюсь, это будет полезно.

Вы правы. ну спешка в решениях оборачивается исправлениями через полгода.

Автоматический отчет о сканировании и пентест — это не одно и то же. Если напишете результат здесь, это поможет и другим.