Для ISO 27001 от нас требуют управление уязвимостями — как выстроить процесс и какие инструменты выбрать?

Из бесплатного вполне подойдут комьюнити-версии сетевых сканеров в контейнерах. Можно сканировать пакеты ОС на серверах и открытые порты, получая отчеты на основе CVE. Основная головная боль — отсеивать фолз-позитивы. Если повесить сканирование на еженедельный cron и выгружать результаты в JSON, процесс можно полностью автоматизировать.

В Мадриде мы прошли похожий процесс для инфраструктуры из 20 серверов. Крупные корпоративные инструменты предлагали нам 6 500 EUR в год. Вместо этого мы поставили облачное security-расширение, за которое платим 8 EUR в месяц за сервер. Тратим около 1 900 EUR в год, и аудитор на первом же аудите утвердил процесс, не написав ни одного несоответствия.

Консультанты обычно раздувают масштаб работы и пытаются продать дорогой софт, с которого получают комиссию. Аудитор смотрит не на панель инструмента, а на то, кто и когда закрыл findings в Excel-таблице. Прежде чем вкладывать состояние в инструменты, наведите порядок в имеющейся документации процессов.

Цикл, который вам нужно внедрить, такой: 1) В начале месяца запускаете автоматическое сканирование. 2) Из полученного списка CVE отбираете критические и высокие. 3) Ставите задачи команде разработчиков. 4) После применения патча делаете проверочное сканирование. 5) Архивируете отчёт и дату закрытия в PDF в папку для аудита.

У какого облачного провайдера вы держите серверы? У крупных провайдеров есть встроенные security-сервисы, которые сканируют виртуальные серверы и контейнеры у них же. Часто включить эти внутренние сервисы выходит куда дешевле, чем арендовать внешний инструмент.

Не забывайте про уязвимости библиотек в коде. Сканировать только серверы недостаточно — добавьте в свой пайплайн сборки бесплатные инструменты, которые сканируют зависимости в вашем репозитории. Аудиторы очень любят видеть уязвимости в open source коде, а установка стоит почти ноль.

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

В версии ISO 27001:2022 пункт 8.8 напрямую рассматривает управление техническими уязвимостями. Организация обязана документально подтвердить, что обладает компетенцией оценивать уязвимости и инициировать корректирующие действия. В связи с этим подготовка утверждённой Процедуры управления уязвимостями является обязательной с точки зрения аудита.

Мне тоже интересно.

У нас было так. Любой пункт не зафиксированный письменно, в будущем обе стороны будут помнить по-разному.

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

Не знал об этом.

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

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

А как вы решили этот вопрос? Ответ сильно зависит от отрасли универсального правила нет.

Пишите, если есть вопросы, отвечу по мере возможности.

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

При принятии решений записывайте и худший сценарий, а не только лучший. Это мое мнение, не утверждаю, что оно единственно верное.

Если углубиться в детали: Время обнаружения проблемы напрямую определяет ее стоимость.

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

У нас было так. Две недели ведения заметок дают лучший результат, чем шестимесячные прогнозы.

Первые три месяца все идет хорошо, проблемы всплывают на четвертом.

Расскажу, как это делается на практике. Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.

Когда пытаешься изменить всё сразу, ничего не приживается. Я бы пошел этим путем.

Самое упускаемое из вида в теме инструменты управления уязвимостями: Чем сложнее отменить решение, тем медленнее его принимайте.

Удачи.