Чтобы контроль уязвимостей в компании был эффективным, перед его запуском стоит пройти несколько подготовительных этапов: оценить ИТ-инфраструктуру и текущие ИБ-процессы, определиться с зонами ответственности персонала и т. п. Разберём, на какие вопросы надо ответить, прежде чем внедрять VM (Vulnerability Management) в организации.
- Введение
- Оценка процессов ИБ в компании
- Выбор инструмента сканирования
- Оценка и формирование процессов взаимодействия ИБ- и ИТ-команд
- Внедрение процесса контроля уязвимостей
- Выводы
Введение
Уязвимости программ, ошибки конфигурации, неучтённые ИТ-активы есть в любой организации. Какие-то недочёты более опасны с точки зрения информационной безопасности, какие-то — менее. Но в любом случае они открывают злоумышленникам путь во внутреннюю инфраструктуру компании. Сократить количество возможных и существующих киберугроз можно с помощью контроля уязвимостей (Vulnerability Management, VM). Это процесс, который состоит из:
- регулярной инвентаризации инфраструктуры,
- сканирования,
- обработки результатов сканирования,
- построения плана устранения уязвимостей с их последующей ликвидацией,
- контроля за выполнением поиска и устранения брешей.
К слову, в конце марта 2021 года прошёл эфир AM Live, посвящённый актуальным вопросам построения системы управления уязвимостями. Ведущие ИБ-эксперты поделились со зрителями методами выстраивания процесса Vulnerability Management в условиях неоднородной инфраструктуры, а также рассказали, как автоматизировать этот процесс. С цитатами, мнениями и результатами опросов зрителей можно ознакомиться в соответствующей статье.
Однако запустить VM «с наскока» нельзя. Сначала нужно провести подготовительную работу: оценить ИБ-процессы, которые уже существуют в компании, понять, насколько хорошо подготовлен персонал, выбрать инструмент и способ сканирования. В противном случае VM и уязвимости будут существовать отдельно друг от друга. Как же подготовиться ко внедрению VM в организации?
Оценка процессов ИБ в компании
Первый шаг к эффективному управлению уязвимостями — это оценка самой компании и её ИБ-процессов. Организация может сделать это самостоятельно или привлечь внешнего аудитора.
Оценивая процессы ИБ, стоит ответить на следующие вопросы:
- Есть ли сейчас процесс контроля всех ИТ-активов компании и насколько он эффективен?
- Есть ли сейчас процесс поиска уязвимостей в ПО, насколько он регулярен и эффективен?
- Есть ли сейчас процесс устранения уязвимостей, насколько он регулярен и эффективен?
- Есть ли во внутренней ИБ-документации описание контроля уязвимостей и все ли с этими документами ознакомлены?
Если ответы на эти вопросы не будут соответствовать реальному положению дел в компании, то оценка получится некорректной и при внедрении или доработке процесса контроля уязвимостей появится много ошибок. Например, часто в компании есть инструмент для VM, но либо он плох, либо нет специалиста, который может им эффективно управлять. Тогда формально контроль уязвимостей есть, но фактически часть ИТ-ресурсов может не попадать в поле зрения сканера или результаты сканирования могут трактоваться некорректно.
По итогам проверки должен быть сформирован отчёт, который наглядно продемонстрирует, как устроены процессы в компании и какие недостатки в них есть на данный момент.
Выбор инструмента сканирования
Сегодня на рынке представлено несколько вариантов реализации процесса VM. Кто-то предлагает самообслуживание (продажу сканера), а кто-то — экспертный сервис. Сканеры могут размещаться в облаке или на периметре компании, мониторить хосты с помощью агентов или без них, а также использовать разные источники данных для пополнения своих баз уязвимостей. Более подробно о выборе инструмента сканирования можно прочитать в нашей предыдущей статье.
На этом этапе стоит ответить на следующие вопросы:
- Как построена ИТ-инфраструктура организации и насколько она специфична?
- Есть ли региональные особенности в работе организации?
- Много ли удалённых хостов?
- Есть ли штатные специалисты для обслуживания сканера?
- Есть ли финансовые резервы для закупки собственного ПО?
- Кто и как будет осуществлять работы по запуску сканирования и обрабатывать полученные результаты?
Оценка и формирование процессов взаимодействия ИБ- и ИТ-команд
Это, пожалуй, самый сложный этап, так как здесь необходимо правильно выстроить взаимодействие людей. Как правило, за информационную безопасность в организации отвечают ИБ-специалисты, а за устранение уязвимостей — ИТ-служба. Бывает и так, что вопросы ИТ и ИБ находятся в ведении одной команды или даже одного сотрудника. Но это не меняет подхода к распределению задач и зон ответственности, и иногда именно на этом этапе выясняется, что текущий объём задач не под силу одному человеку.
В итоге должен быть сформирован согласованный и синхронный процесс устранения уязвимостей. Для этого нужно определить критерии передачи обнаруженных уязвимостей от ИБ-команды в ИТ (то есть сформировать удобные для всех способ и форму передачи данных).
Также этот этап позволяет согласовать для обеих команд KPI и SLA по передаче информации и устранению уязвимостей (при этом стоит учитывать знания полученные на втором этапе). Например, для ИБ важно установить требования по скорости передачи данных об уязвимостях и точности определения их критической значимости, а для ИТ — скорость закрытия уязвимостей заданного уровня опасности.
Внедрение процесса контроля уязвимостей
Оценив эффективность и наличие процессов, определившись с подходящим способом организации контроля уязвимостей и инструментом сканирования, а также регламентировав взаимодействие между командами, можно приступать ко внедрению контроля уязвимостей.
Здесь можно дать такой совет: не стоит сразу загружать этот процесс всеми функциональными модулями, доступными в инструментах сканирования. Если в организации не было постоянного мониторинга, то, скорее всего, ИБ- и ИТ-команды испытают сложности в коммуникации. Это может привести к конфликтам и несоблюдению KPI и SLA.
Лучше внедрять VM постепенно. Можно проводить полный цикл контроля уязвимостей (инвентаризация, сканирование, обработка, контроль) с меньшими темпами, например сканируя всю инфраструктуру раз в квартал, а критические для бизнеса сегменты — раз в месяц. Где-то через год ваши команды смогут «сработаться», найти и устранить основные уязвимости, понять явные недостатки своих процессов и предоставить план по их устранению. Впоследствии это увеличит скорость и эффективность контроля уязвимостей.
Дополнительно можно привлекать внешних экспертов, которые помогут значительно сократить рутинную работу для штатных сотрудников компании. Например, сервис-провайдера можно привлекать к проведению инвентаризации и сканирования, к обработке результатов. Сервисный подход также поможет руководителям планировать работы и следить за ходом их выполнения. Так, например, если из отчёта провайдера видно, что найденные при предыдущем сканировании уязвимости так и не закрыты, руководитель, посмотрев SLA своих сотрудников, поймёт, что либо ИБ-отдел не успевает передавать данные о сканировании, либо ИТ — исправлять выявленные ошибки.
Выводы
При построении процесса контроля уязвимостей компания может столкнуться со следующими ошибками:
- завышенная оценка текущих процессов и их эффективности внутри организации, в том числе из-за того, что люди, отвечающие за эти процессы, боятся показаться некомпетентными;
- неправильная оценка при выборе способа и инструмента сканирования. Это происходит из-за того, что специалисты выбирают сканер либо на основании субъективной оценки, либо «по указанию сверху» — также без оценки процессов и анализа. А если у штатных сотрудников нет достаточного опыта и компетенций, то лучше выбрать сервис-провайдера для проведения сканирования, анализа результатов и т. п.;
- отсутствие разграничения зон ответственности между ИБ- и ИТ-командами;
- внедрение всего и сразу. «Интегрируем регулярный мониторинг всех серверов, АРМ и облаков, сразу будем ориентироваться на соответствие ISO 12100 и PCI DSS, поставим патч-менеджмент, а Борис это будет контролировать» — такой подход опасен. Через месяц Борис поссорится с ИТ, через три — уволится, а процесс признают неэффективным и забудут о нём до первого киберинцидента.
Поэтому лучше сначала «заложить фундамент» и только после этого начинать строить процесс сканирования.
