Vulnerability management

Vulnerability management

Каждая организация хочет защитить свои информационные ресурсы и делает это согласно собственной политике безопасности. Типовая служба ИБ имеет свое видение того, какими организационно-правовыми мерами и техническими средствами она будет оберегать информационное пространство, вверенное под ее надзор. Для достижения этой цели выстраивается множество слаженных и взаимосвязанных процессов. Об одном из них и пойдет речь, а именно, об управлении уязвимостями. Я расскажу о значимых аспектах процесса Vulnerability Management, информация о которых накоплена нами за время работы с заказчиками при оказании услуги SOC.

МИНИМИЗИРОВАТЬ ВРЕМЯ СКАНИРОВАНИЯ

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

НАРУШЕНИЯ СЕТЕВОЙ ТОПОЛОГИИ

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

ПРОБЛЕМЫ ОТЧЕТНОСТИ

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

Во-первых, выгрузки могут содержать неверные или устаревшие патчи, ссылки на уже не существующие или неактуальные статьи по устранению уязвимостей. Да, процент ошибок невелик, однако никто не может гарантировать, что они не произойдут в той самой уязвимости, которая будет проэксплуатирована злоумышленником. Поэтому необходима тщательная проверка результатов работы сканера. Это, по сути, задача борьбы с False Positive.

Во-вторых, необходимо обозначить приоритет устранения уязвимостей. Этот параметр играет немаловажную роль в информационной безопасности организации. Даже если мы будем руководствоваться CVSS-метрикой (популярный принцип классификации критичности, который, в частности, применяется в PCI DSS), может возникнуть ситуация, при которой ИТ-службам придется обрабатывать слишком большое число запросов, имеющих равный вес согласно CVSS, однако разный для заказчика. Это, в свою очередь, может привести к тому, что не будут своевременно закрыты определенные бреши.

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

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

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

ЭТАП РАССЛЕДОВАНИЯ

Далее наступает следующий этап взаимодействия заказчика и исполнителя – расследование тех или иных подозрительных отклонений в статистике предоставленной отчетной документации. Далеко не все организации готовы самостоятельно этим заниматься. Иногда приходится оказывать профессиональную помощь. К примеру, могут возникать вопросы о том, как же вышло, что в инфраструктуре так много уязвимостей (в том числе и далеко не свежих), несмотря на якобы регулярные обновления. В итоге выясняется, что часть их не была применена или рекомендации бюллетеней выполнены не полностью. Помимо установки указанных в них патчей, иногда требуются и иные мероприятия, которые необходимо выполнить, чтобы закрыть брешь (например, изменить в регистре некоторую запись). Нередко сотрудники забывают и про то, что при прекращении поддержки производителем программного обеспечения необходимо в срочном порядке осуществлять переход на актуальные версии ПО, искать аналогичные продукты. Дальнейшая его эксплуатация является серьезной угрозой информационной безопасности.

ПОИСК УЯЗВИМОСТЕЙ – НЕ РАЗОВАЯ ПРОЦЕДУРА

К сожалению, до сих пор существует мнение, что поиск уязвимостей – разовая процедура. Провели мероприятия по сканированию, получили отчеты и рекомендации, дали задание сотрудникам ИТ служб и успокоились на год-другой. Данный подход в корне неверный, о чем говорят большинство общепринятых стандартов ИБ в разных областях: от PCI DSS, NIST до требований российских регуляторов. Управление уязвимостями – весомая часть политики безопасности, которая должна быть глубоко проработана с целью достичь:

- установленной периодичности, зависящей в том числе от критичности сегмента;
- регулярной инвентаризации активов, оценки их критичности;
- постоянного совершенствования методов в целом;
- качественного мониторинга и устранения брешей.

ПРО SOC

На последнем пункте хотел бы остановиться чуть подробнее.  При повторных сканированиях инфраструктуры замечаешь, что остается довольно много невыполненных рекомендаций, незакрытых уязвимостей. Далеко не всегда речь идет о халатности сотрудников. Управление уязвимостями – процесс борьбы с хаосом, которым сложно управлять своими силами. Нужна централизованная платформа, предоставляющая разносторонний взгляд на то, как протекает выполнение поставленных задач по закрытию брешей или иных связанных мероприятий. На мой взгляд, один из выходов для тех, у кого нет достаточных ресурсов - услуга коммерческого сервиса Security Operations Center (SOC). Сервис SOC как нельзя лучше решает данную задачу, так как это одна из главных его функций (помимо мониторинга и расследований инцидентов).

Мониторинг ИБ и управление уязвимостями – понятия, безусловно, разные, однако взаимосвязанные, так как последнее является одним из важнейших поставщиков событий для процессов мониторинга. Результаты инструментальных исследований инфраструктуры на наличие брешей можно, к примеру, использовать для более тонкой и точной настройки SIEM’а. На рынке уже можно встретить решения, которые объединяют в себе SIEM и сканер уязвимостей. Полагаю, что тенденция к объединению подобных продуктов сохранится. Большинство из громких угроз современности обнаруживается связкой Vulnerability Management и мониторингом SOC.