Vulnerability Management — это в первую очередь процесс взаимодействия людей

Как в ПСБ выстроен процесс Vulnerability Management (VM)?

Андрей Исхаков: Промсвязьбанк является крупным российским банком с разветвленной инфраструктурной сетью. Такой масштаб, безусловно, сказывается на важнейшей составляющей любого VM-процесса — задаче инвентаризации активов. В идеальной картине мира в компании еще на моменте проработки архитектуры должна быть заложена CMDB, охватывающая всю инфраструктуру в части управления ИТ-активами. Системой должна управлять выделенная группа ИТ-специалистов, обеспечивающих не только полноту покрытия, но и регулярную актуализацию данных. Тогда безопасники могли бы со спокойной душой ориентироваться на этот инструмент, сосредоточиться на поиске shadow IT и задачах валидации уязвимостей. В реальности же с полнотой и актуальностью данных в CMDB часто возникают проблемы. Тогда ИБ начинает изобретать велосипед и строить собственную модель активов. Это процесс, в который можно погрузиться и не вынырнуть, ведь уровень возможной детализации в современных инструментах очень высок. Можно опускаться вплоть до инвентаризации физических портов коммутаторов, а также обслуживающих эти устройства подразделений и отдельных сотрудников.

Но здесь важно вовремя остановиться и понять: что мы делаем и для чего. Для управления уязвимостями достаточно сделать полную и актуальную базу активов и обозначить их владельцев. Погружение в детали — это крутой шаг к обогащению уязвимостей, но зачастую он избыточен. Мы в ПСБ начали с крупных мазков: сегментации активов на сетевом уровне, актуализации данных о владельцах ресурсов, а затем обратились к тем, кто их обслуживает. Так, двигаясь от масштабных задач к более мелким, но не закапываясь в детали, мы планомерно идем к идеальному VM-процессу, в безопасную инфраструктуру.

Сергей Алешинский: Процесс управления уязвимостями состоит из нескольких этапов. Первый и основной — подготовка нормативной документации, которая регламентирует происходящие в банке ИТ-процессы. Документация также описывает, как система может быть внедрена, какие требования к ней предъявляются и др. В документах важно четко обозначить жизненный цикл решения, который включает разработку архитектуры и сетевых схем, следом — установку, настройку и т. д. В рамках этого цикла существует несколько этапов ИБ-проверок, в том числе на уязвимости и комплаенс. Апрувленная система попадает в конфигурационные базы данных и вносится в чек-лист с пометкой «проверена и готова к эксплуатации». Далее мы устанавливаем для нее параметр rescan — срок, после которого каждое решение должно заново проходить все необходимые проверки.

Расскажите об особенностях комплаенс в ПСБ. Для вас это часть VM или отдельный процесс?

Сергей Алешинский: Это часть большого процесса управления уязвимостями и анализа инфраструктуры. В нашем случае главная особенность в том, что в банке есть собственный центр ИТ-архитектуры. Там работают специалисты, которые формируют наш технологический стек. В определенный момент банк взял курс на изменение архитектуры софта, поэтому реестр ПО начал неконтролируемо распухать ― вроде бы решения у всех одинаковые, но на самом деле разные. Пока мы прорабатывали конфигурационные стандарты для каждой новой системы, некоторые процессы в банке встали. Тогда мы приняли волевое решение ― остановились, заново утвердили стек и только после этого создали стандарты, которые утвердили ИТ- и ИБ-подразделение.

ИБ в этом случае отвечает за безопасность конфигурации, а ИТ гарантирует, что решение будет работать правильно. Для создания стандартов мы также привлекали внешних партнеров. По сути, это чек-листы ― как у пилотов, которые перед взлетом самолета тестируют все системы по списку. Мы точно так же проверяем, что все компоненты наших решений настроены в соответствии с лучшими практиками и отвечают требованиям регуляторов.

Андрей Исхаков: Хотелось бы остановиться на двух важных аспектах комплаенс, а точнее харденинга инфраструктуры. Первый — в рамках комплаенс ИБ нужно обязательно выстраивать диалог с ИТ-подразделением. Да, мы привлекаем для оценки и разработки стандартов внешнюю экспертизу, но в то же время подключаем к процессу согласования соответствующие подразделения из блока ИТ. Речь идет о сопроводителях по различным направлениям (ОС, СУБД, классам прикладных систем) — экспертах, которым предстоит жить с этими конфигурациями. Второй момент — максимальная автоматизация. Учитывая масштабы нашей инфраструктуры и необходимость проведения регулярных проверок по заданным сценариям, важно обеспечить имплементацию всех пунктов стандартов настройки в виде скриптов и программ. На мой взгляд, одной из сильных сторон нашего VM-процесса является полная кастомизация абсолютно всех используемых стандартов. Мы уделяем этим процедурам существенное внимание, хотя есть и обратная сторона медали — на валидацию и согласование всеми заинтересованными сторонами порой требуется длительное время.

ИТ + ИБ

Как вы выстраиваете работу с ИТ-подразделением в рамках VM?

Сергей Алешинский: Применяем инструменты для совместной работы, например Confluence и Jira. Мы анализируем инфраструктуру, формируем отчеты и выдаем коллегам из ИТ рекомендации по устранению уязвимостей.

Отмечу, что каждая рекомендация безопасников должна быть подробно объяснена и при необходимости подкреплена ссылками на соответствующие законы, указы и подзаконные акты. Мы получаем вопросы к отчетам: «На что вы ссылаетесь?», «Почему должно быть именно так?», «С чего вы решили, что мы небезопасны?» В этом есть очевидные плюсы — благодаря нашим разъяснениям коллеги становятся грамотнее в вопросах информационной безопасности. К примеру, я замечаю, что ИТ-специалисты, которые занимаются инфраструктурой, последнее время чаще делают свою работу с оглядкой на ИБ.

Андрей Исхаков: Шеринг специализированных инструментов для управления уязвимостями тоже имеет право на существование. В единичных случаях мы практиковали предоставление доступа к VM-решениям с ограниченными правами доступа для коллег из ИТ. Однако в условиях работы с большим штатом специалистов из распределенных команд устранять уязвимости в рамках ITSM-подхода гораздо эффективнее. Мы отправляем запрос — ИТ-служба его закрывает. Эта модель подразумевает фиксацию результата и прозрачные SLA, она лучше подходит для крупных компаний.

К слову, о крупных компаниях. У ПСБ масштабная инфраструктура со множеством ИТ-активов. В таких условиях непросто своевременно находить уязвимости. Какие ИБ-инструменты вы для этого используете?

Сергей Алешинский: Задача действительно непростая, но еще сложнее не просто своевременно идентифицировать уязвимость, а дать заключение о ее применимости в инфраструктуре. Тем более банк взял курс на импортозамещение, поэтому сейчас у нас довольно разрозненный ИТ-ландшафт — парк прикладного ПО и ОС растет прямо на глазах. Сканеры не всегда поспевают за всеми вендорами. Для проверки мы используем разные инструменты, в том числе небезызвестный MaxPatrol VM.

Андрей Исхаков: Vulnerability Management как процесс — это также взаимодействия людей. Я не умаляю значения его технической составляющей, тем более в такой большой структуре, как ПСБ, но хочу напомнить, что ключевую роль здесь играет умение договариваться. Кибербезопасность не должна стоять с мечом над головой, угрожать коллегам требованиями регуляторов и пугать нормативкой. Нужно объяснять, почему так важно своевременно устранять уязвимости и что может произойти, если этого не делать. В этом заключается одна из главных задач CISO и ИБ-блока в целом: все участники треугольника «бизнес — ИТ — ИБ» должны находиться в едином информационном поле и действовать сообща. 

Как в банке организован патч-менеджмент?

Сергей Алешинский: За обновление серверной инфраструктуры средств защиты отвечает департамент информационной безопасности. Но обслуживанием основного парка серверов, рабочих станций и сетевого оборудования занимается ИТ-блок. Обычно коллеги сами накатывали обновления, ставили свежие прошивки и т. д. Теперь процесс усложнился, потому что в банке остаются ОС из недружественных стран, и мы обязаны комплексно проверять любые апдейты на предмет закладок — этим занимается отдельная команда.

Андрей Исхаков: Мы и раньше тестировали все патчи, но в нынешней ситуации приходится тщательнее проверять их на предмет незадекларированных закладок. Основу команды, которая занялась полноценным изучением обновлений, составляют ребята из Red Team. Причем это была их инициатива — взять на себя новые обязанности. Кроме того, мы ориентируемся на рекомендации ФСТЭК в части апдейтов всевозможных систем.

А что насчет поиска уязвимостей в ПО, которое разрабатывают специалисты ПСБ?

Сергей Алешинский: Аналогично с любыми другими системами. В ИБ-департаменте есть несколько подразделений, которые проверяют те или иные компоненты ПО на протяжении его жизненного цикла. Одни эксперты анализируют код, другие проводят макетирование написанных компонентов на стендах и проверяют их работоспособность в конкретной инфраструктуре и т. д.

Помимо описанных вами методов есть и более радикальные — компенсационные меры или вывод ПО из эксплуатации. Как часто вы к ним прибегаете?

Сергей Алешинский: Приведу конкретный кейс: в банке есть legacy-система, которая выполняет важную бизнес-функцию. Она давно не обновлялась, поэтому мы выставили требования к ИТ-блоку — обновить, заместить или отказаться от использования. Пока мы изолировали ее на уровне сетевой инфраструктуры: ограничили взаимодействие с другими системами банка и ужесточили доступ (теперь он осуществляется через промежуточные хосты).

Как вы проводите категоризацию уязвимостей?

Андрей Исхаков: Используем базовые CVSS-метрики плюс собственную экспертизу и методику ФСТЭК. Наибольший вес получают уязвимости критичных сегментов и узлов (критерии критичности заложены в модель наших активов).

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

Сергей Алешинский: Большинство сервисов, которые мы должны защищать, направлены на веб. Поэтому серьезным триггером, который автоматически повышает статус уязвимости и побуждает нас к активным действиям, может стать публикация данных о проблеме в интернете. Например, из недавних кейсов можно вспомнить «1C-Битрикс».

Как вы действуете, если находите на периметре критически опасную уязвимость, которую нужно закрыть в считанные часы?

Андрей Исхаков: Собираем срочную конференцию, подключив ответственных за сопровождение уязвимого сервиса коллег из ИТ. Согласовав план действий, совместно приступаем к устранению проблемы. Со своей стороны подключаем все имеющиеся ресурсы и инструменты, включая виртуальный патчинг на WAF и возможные компенсационные меры. Но были кейсы, когда коллегам из ИТ приходилось экстренно устанавливать обновления. При этом подход «устраните, потом все объясним» в ПСБ не работает. Мы — эксперты в кибербезопасности и должны аргументированно объяснить, почему и чем уязвимость опасна для бизнеса. Обычно с этим проблем не возникает — редко когда приходится подключать к процессам тяжелую артиллерию в виде руководства.

Сергей Алешинский: ИТ-специалисты банка знают, что, если кто-то из безопасников прибежал с большими глазами и кричит «Немедленно выключаем „Битрикс“!», стоит прислушаться :) Они выключают опасную систему, и мы начинаем вместе разрабатывать план действий.

В какую сторону, по вашему мнению, должны развиваться отечественные VM-решения?

Андрей Исхаков: Я бы рекомендовал производителям стремиться к открытости. Приведу пример, с которым многие наверняка сталкивались: иностранный вендор уходит, и мы начинаем пилотировать отечественные аналоги. Первое, о чем задумается эксперт, — как оценить полноту базы знаний сканера, какой процент решений из моего импортозамещенного парка продуктов он не покрывает? И уже на этом этапе возникают сложности объективного сравнения, потому что вендоры не стремятся раскрывать подобную информацию. Было бы здорово, если бы производители публиковали данные по идентифицируемым CVE, поддерживаемому ПО и т. д. В ходе проведения качественных пилотов тайное всегда становится явным, но ведь можно значительно упростить жизнь заказчику.

Второй момент касается взаимных интеграций обеспечивающих систем и СЗИ, необходимых для комплексного управления уязвимостями всей инфраструктуры. Далеко не все заказчики могут позволить себе согласиться с трендом передовых производителей «экосистема ИБ от одного вендора». Бесспорно, все вендоры утверждают, что у них есть API, поэтому их решения можно интегрировать с чем угодно. Однако на практике часто возникают проблемы с нефункциональными API, которые вендоры еще и меняют без уведомления друг друга и комьюнити. Хочется видеть больше унифицированных неконфликтующих решений от разных производителей.

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