Как построить рабочий процесс контроля уязвимостей с нуля

Как построить рабочий процесс контроля уязвимостей с нуля

Чтобы контроль уязвимостей в компании был эффективным, перед его запуском стоит пройти несколько подготовительных этапов: оценить ИТ-инфраструктуру и текущие ИБ-процессы, определиться с зонами ответственности персонала и т. п. Разберём, на какие вопросы надо ответить, прежде чем внедрять VM (Vulnerability Management) в организации.

 

 

 

 

 

  1. Введение
  2. Оценка процессов ИБ в компании
  3. Выбор инструмента сканирования
  4. Оценка и формирование процессов взаимодействия ИБ- и ИТ-команд
  5. Внедрение процесса контроля уязвимостей
  6. Выводы

Введение

Уязвимости программ, ошибки конфигурации, неучтённые ИТ-активы есть в любой организации. Какие-то недочёты более опасны с точки зрения информационной безопасности, какие-то — менее. Но в любом случае они открывают злоумышленникам путь во внутреннюю инфраструктуру компании. Сократить количество возможных и существующих киберугроз можно с помощью контроля уязвимостей (Vulnerability Management, VM). Это процесс, который состоит из:

  • регулярной инвентаризации инфраструктуры,
  • сканирования,
  • обработки результатов сканирования,
  • построения плана устранения уязвимостей с их последующей ликвидацией,
  • контроля за выполнением поиска и устранения брешей.

К слову, в конце марта 2021 года прошёл эфир AM Live, посвящённый актуальным вопросам построения системы управления уязвимостями. Ведущие ИБ-эксперты поделились со зрителями методами выстраивания процесса Vulnerability Management в условиях неоднородной инфраструктуры, а также рассказали, как автоматизировать этот процесс. С цитатами, мнениями и результатами опросов зрителей можно ознакомиться в соответствующей статье.

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

Оценка процессов ИБ в компании

Первый шаг к эффективному управлению уязвимостями — это оценка самой компании и её ИБ-процессов. Организация может сделать это самостоятельно или привлечь внешнего аудитора.

Оценивая процессы ИБ, стоит ответить на следующие вопросы:

  • Есть ли сейчас процесс контроля всех ИТ-активов компании и насколько он эффективен?
  • Есть ли сейчас процесс поиска уязвимостей в ПО, насколько он регулярен и эффективен?
  • Есть ли сейчас процесс устранения уязвимостей, насколько он регулярен и эффективен?
  • Есть ли во внутренней ИБ-документации описание контроля уязвимостей и все ли с этими документами ознакомлены?

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

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

Выбор инструмента сканирования

Сегодня на рынке представлено несколько вариантов реализации процесса VM. Кто-то предлагает самообслуживание (продажу сканера), а кто-то — экспертный сервис. Сканеры могут размещаться в облаке или на периметре компании, мониторить хосты с помощью агентов или без них, а также использовать разные источники данных для пополнения своих баз уязвимостей. Более подробно о выборе инструмента сканирования можно прочитать в нашей предыдущей статье.

На этом этапе стоит ответить на следующие вопросы:

  • Как построена ИТ-инфраструктура организации и насколько она специфична?
  • Есть ли региональные особенности в работе организации?
  • Много ли удалённых хостов?
  • Есть ли штатные специалисты для обслуживания сканера?
  • Есть ли финансовые резервы для закупки собственного ПО?
  • Кто и как будет осуществлять работы по запуску сканирования и обрабатывать полученные результаты?

Оценка и формирование процессов взаимодействия ИБ- и ИТ-команд

Это, пожалуй, самый сложный этап, так как здесь необходимо правильно выстроить взаимодействие людей. Как правило, за информационную безопасность в организации отвечают ИБ-специалисты, а за устранение уязвимостей — ИТ-служба. Бывает и так, что вопросы ИТ и ИБ находятся в ведении одной команды или даже одного сотрудника. Но это не меняет подхода к распределению задач и зон ответственности, и иногда именно на этом этапе выясняется, что текущий объём задач не под силу одному человеку.

В итоге должен быть сформирован согласованный и синхронный процесс устранения уязвимостей. Для этого нужно определить критерии передачи обнаруженных уязвимостей от ИБ-команды в ИТ (то есть сформировать удобные для всех способ и форму передачи данных).

Также этот этап позволяет согласовать для обеих команд KPI и SLA по передаче информации и устранению уязвимостей (при этом стоит учитывать знания полученные на втором этапе). Например, для ИБ важно установить требования по скорости передачи данных об уязвимостях и точности определения их критической значимости, а для ИТ — скорость закрытия уязвимостей заданного уровня опасности.

Внедрение процесса контроля уязвимостей

Оценив эффективность и наличие процессов, определившись с подходящим способом организации контроля уязвимостей и инструментом сканирования, а также регламентировав взаимодействие между командами, можно приступать ко внедрению контроля уязвимостей.

Здесь можно дать такой совет: не стоит сразу загружать этот процесс всеми функциональными модулями, доступными в инструментах сканирования. Если в организации не было постоянного мониторинга, то, скорее всего, ИБ- и ИТ-команды испытают сложности в коммуникации. Это может привести к конфликтам и несоблюдению KPI и SLA.

Лучше внедрять VM постепенно. Можно проводить полный цикл контроля уязвимостей (инвентаризация, сканирование, обработка, контроль) с меньшими темпами, например сканируя всю инфраструктуру раз в квартал, а критические для бизнеса сегменты — раз в месяц. Где-то через год ваши команды смогут «сработаться», найти и устранить основные уязвимости, понять явные недостатки своих процессов и предоставить план по их устранению. Впоследствии это увеличит скорость и эффективность контроля уязвимостей.

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

Выводы

При построении процесса контроля уязвимостей компания может столкнуться со следующими ошибками:

  • завышенная оценка текущих процессов и их эффективности внутри организации, в том числе из-за того, что люди, отвечающие за эти процессы, боятся показаться некомпетентными;
  • неправильная оценка при выборе способа и инструмента сканирования. Это происходит из-за того, что специалисты выбирают сканер либо на основании субъективной оценки, либо «по указанию сверху» — также без оценки процессов и анализа. А если у штатных сотрудников нет достаточного опыта и компетенций, то лучше выбрать сервис-провайдера для проведения сканирования, анализа результатов и т. п.;
  • отсутствие разграничения зон ответственности между ИБ- и ИТ-командами;
  • внедрение всего и сразу. «Интегрируем регулярный мониторинг всех серверов, АРМ и облаков, сразу будем ориентироваться на соответствие ISO 12100 и PCI DSS, поставим патч-менеджмент, а Борис это будет контролировать» — такой подход опасен. Через месяц Борис поссорится с ИТ, через три — уволится, а процесс признают неэффективным и забудут о нём до первого киберинцидента.

Поэтому лучше сначала «заложить фундамент» и только после этого начинать строить процесс сканирования.

Полезные ссылки: 
Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Яндекс Дзен, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru