Что именно требует аудитор по ISO 27001 для процесса управления уязвимостями?

Разделите скоуп на две части: инфраструктура и код. По инфре раз в месяц гоняйте любой open-source сканер по пулу IP-адресов и складывайте отчеты. В коде внедрите в CI/CD проверку зависимостей: если в библиотеке критическая уязвимость, билд должен падать. Такие логи из пайплайна — любимое доказательство аудиторов.

Мы в прошлом году перед аудитом прописали реальные SLA: критические — 7 дней, высокие — 30 дней, средние — 90 дней. Аудитор сразу нашел 4 незакрытые уязвимости уровня High, но мы показали подписанные бланки принятия рисков с бизнес-обоснованием, и он пропустил всё без единого замечания.

В папке для аудита обязательно должны быть четыре вещи: 1) Утвержденная Политика управления уязвимостями с таблицей SLA, 2) Отчеты сканирований с датами за последние 3 месяца, 3) Тикеты из таск-трекера по исправленным уязвимостям, 4) Подписанные акты принятия рисков на то, что нельзя пропатчить технически или операционно.

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

edit: писал с телефона, извините за опечатки.

а отчёты полученные бесплатными open-source сканерами аудитор по ISO принимает как официальный документ или обязательно нужны лицензионные отчёты от очень дорогих корпоративных софтов по кибербезопасности?

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

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

Попробую.

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

Интересно, есть ли те, кто делает иначе.

В теории верно, но на практике так не работает. Ответ сильно зависит от отрасли, универсального правила нет.

Удачи.

редко встретишь текст с такой ясностью изложения.

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

Удачи.

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

Интересно, есть ли те, кто делает иначе.

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

Забытые тестовые среды становятся входом в систему чаще, чем продакшн.

Я бы не торопился. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

Это мое мнение, не утверждаю, что оно единственно верное.

сохранил.

Я тоже об этом думал. Прежде чем принимать решение, посмотрите, какие данные у вас есть.

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

Взял на заметку спасибо.