За последние полтора года ИТ-периметры организаций так усложнились (один переход на удаленку чего стоит!), что немудрено даже самому опытному ИБэшнику запутаться в этих динамичных лабиринтах. На этом фоне мы решили выяснить, как же сейчас налажен процесс Vulnerability Management (VM) в компаниях: как часто проводится сканирование, где ищут уязвимости, как принимаются решения об установке патчей и может ли сканирование заменить пентест. Результатами нашего опроса делимся в этом посте.
Серию опросов мы проводили в апреле-июне 2021 года в онлайн-формате. В них приняли участие 200 респондентов – представителей компаний из разных отраслей (IT, госсектор, финансы, промышленность, ТЭК, здравоохранение, ритейл и другие). Треть опрошенных – это небольшие компании (до 250 хостов), еще 45% – компании от 250 до 5 тыс. хостов, а 22% – крупные организации, где насчитывается более 5 тыс. хостов. При этом в большинстве компаний (43%) есть собственный полноценный ИБ-отдел. 36% респондентов ответили, что защита от киберугроз находится в ведении ИТ-отдела, а 21% – что этими вопросами занимается один выделенный ИБ-специалист.
Итак, мы выяснили, что управление уязвимостями есть в 70% организаций, но половина из них недовольна устройством этого процесса. Конечно, под VM мы подразумеваем не просто сканирование, но и постоянную инвентаризацию, оценку уровня защищенности сетевой инфраструктуры, разработку рекомендаций по устранению найденных уязвимостей и проверку выполнения этих самых рекомендаций.
Что же до сканирования, то 90% организаций отметили, что сканируют ИТ-периметры для обеспечения реальной кибербезопасности. В то же время для 60% респондентов VM – это способ выполнять требования российских регуляторов (приказ ФСТЭК № 239 требует от субъектов КИИ проводить инвентаризацию информационных ресурсов, аудит и анализ/устранение уязвимостей, а приказ ФСТЭК № 235 требует выявлять уязвимости в значимых объектах КИИ).
Среди других целей сканирования респонденты назвали:
- соответствие требованиям международных стандартов;
- проверку ресурсов сетей, ОС, подключенных устройств, портов;
- создание отчетов, в которых описываются типы уязвимостей;
- поиск различных типов уязвимостей сети и их анализ в режиме реального времени.
Что сканируют
Самым интересными элементами инфраструктуры для сканирования большинство респондентов (45%) считают локальную сеть. Действительно, многие компании понимают, что эксплуатация уязвимостей на внешнем периметре – это лишь первый шаг злоумышленника, а его главная цель заключается в развитии атаки внутри инфраструктуры (для хищения данных, влияния на технологические процессы и т. п.). Радует, что защищенности внутренних сетевых узлов уделяется столько внимания, но сканирование нужно не только внутри.
На втором месте – внешний периметр. Именно здесь встречаются критические и при этом относительно старые уязвимости, некоторые из которых были обнаружены еще лет 10 назад. Среди них баг Heartbleed, который использует ошибки в криптографической библиотеке OpenSSL, уязвимость EternalBlue, через которую в 2017 году хакеры распространяли WannaCry, а также BlueKeep – уязвимость RDP-протокола. Все помнят, какую панику вызвали в свое время эти «динозавры». И пусть вендоры оперативно выпустили обновления, все эти ошибки мы до сих пор встречаем в компаниях разного масштаба и профиля.
Сканирование внешнего периметра стало особенно актуально в период пандемии, так как переход на удаленку и массовая цифровизация бизнес-процессов значительно ослабили ИТ-инфраструктуры. По оценке Solar JSOC, за последний год более чем на 60% выросло число АСУ ТП, доступных из интернета. А количество хостов с уязвимым SMB-протоколом увеличилось почти в 2 раза.
Из исследования видно, что веб-приложения и изолированный контур находятся вне фокуса внимания респондентов. Это тревожно, так как за последний год веб-уязвимости стали значительно чаще использоваться хакерами для проникновения в сети организаций. Например, по нашей оценке, в 2020 году треть всех инцидентов кибербезопасности была связана именно с атаками на веб. По нашим подсчетам, 44% веб-приложений имеют некорректную настройку прав доступа, а 29% – возможности внедрения SQL-инъекций.
Если говорить об изолированном контуре, то автоматические обновления ПО, которые закрывают многие уязвимости, здесь недоступны. В то же время ручной или полуручной процесс установки патчей отсутствует в 90% российских компаний. Это происходит и по организационным причинам (иногда проще ничего не обновлять, чем согласовывать простой оборудования из-за установки патчей), и по техническим (например, при попытках обновить legacy или самописные системы).
Как сканируют
Более 60% опрошенных сканируют всю инфраструктуру раз в квартал или реже. Остальные чаще, а 9% респондентов ответили, что запускают сканер даже несколько раз в неделю.
Анализ критических серверов и АРМ сотрудников проводится чаще. 17% опрошенные запускают сканирование этих элементов несколько раз в неделю, столько же – один раз в неделю, а 26% — раз в месяц. Раз в квартал и реже это делают 40% респондентов.
Трудно дать универсальный совет о том, как часто надо проводить сканирование уязвимостей. Несколько раз в квартал — правильный ответ скорее такой, но все зависит от размера, состава и критичности инфраструктуры, частоты вносимых в нее изменений, а также от скорости устранения обнаруженных ранее уязвимостей.
Да и про общий ландшафт киберугроз и скорость появления и эксплуатации новых уязвимостей забывать не стоит. Раньше с момента публикации до эксплуатации проходило 1,5 – 2 года, а сегодня – уже может несколько часов. А новые уязвимости появляются вообще со скоростью света. Например, по данным vulners.com, за последний месяц было обнаружено 350 эксплойтов. Из них 11 получили оценку выше 7 по CVSS.
Кстати, в качестве источников информации о новых ИБ-угрозах опрошенные чаще всего используют новостные порталы, специализированные ресурсы, профессиональные блоги и сообщества в соцсетях, а также бесплатные бюллетени от вендоров.
А как именно сканируют? 41% респондентов проводят сканирование автоматически по расписанию, а 39% – что делают это силами только одного ИБ-специалиста. Можно представить, какой объем технических данных сваливается на этого бедолагу и сколько времени ему нужно, чтобы их обработать. А если при этом есть и другие задачи?
Но вопрос не только в закрытии уязвимостей. VM – это еще и про инвентаризацию, без которой пышным цветом расцветают shadow IT.
Патч-менеджмент в разгар атаки
Половина опрошенных отмечает, что в период массовых атак-пандемий решение об установке патчей принимается на уровне ИТ-администраторов, так как ситуация «прозрачна для всех». Экстренный патч-менеджмент чаще всего находится в ведении ИТ-администраторов в крупных компаниях. А в организациях среднего размера (от 250 до 5 тыс. человек) подобные решения чаще всего принимает ИТ-руководитель, но при этом сотрудники ИБ-службы должны аргументировать ему эту потребность. Первых лиц компании и бизнес-подразделения к принятию решения о необходимости установки патчей в период эпидемий привлекают только в крупных (более 5 тыс. человек) и мелких (менее 250 человек) организациях. В то же время есть организации, где ИТ-службы никак не реагируют на запрос об установке патчей – таких 12% среди всех опрошенных.
Получается, что проблема патч-менеджмента связана с несогласованностью в действиях между ИБ-службами и ИТ-администраторами. В итоге процесс затягивается из-за дополнительных согласований.
А как же пентест?
VM все бреши в инфраструктуре, конечно, не закроешь. Чуть больше трети компаний уверены, что для поиска уязвимостей необходимо проводить еще и пентесты. Правда, почти столько же респондентов считают, что сканера для этих целей вполне достаточно.
Мы же уверены, что две эти процедуры не исключают, а дополняют друг друга.
Сканирование уязвимостей – это автоматизированный процесс поиска технических неисправностей и ошибок (из базы CVE), плюс инвентаризация активов. Пентест же выявляет не только технические, но и логические уязвимости, показывая, как выглядит инфраструктура для злоумышленника, где и как он может проникнуть в критичные системы или во внутреннюю сеть. Кроме этого, такая наглядность помогает ИБ-специалистам продемонстрировать потребность в регулярном сканировании и обосновать необходимость установки патчей.
Заключение
Итак, большая часть организаций старается управлять уязвимостями в своих инфраструктурах. Однако многие делают это нерегулярно (60% респондентов проводят сканирование всей инфраструктуры раз в квартал или реже). Ресурсов на это тоже выделяется недостаточно: почти в трети компаний сканированием занимается один ИБ-специалист.
Акцент при поиске уязвимостей большинство организаций делает на локальной сети, а веб-приложения и изолированный сегмент остаются вне фокуса их внимания.
По поводу пентеста мнения разделились: 38% считают, что он должен дополнять VM, однако столько же уверены, что тестирование на проникновение – это лишнее.
Остается актуальной проблема установки патчей. Есть организации, где ИТ-службы никак не реагируют на подобные запросы – таких оказалось 12% среди всех опрошенных. Зато больше половины респондентов отмечают, что решение об установке патчей принимается на уровне ИТ-администраторов, так как ситуация «прозрачна для всех».
А как вы считаете, помогает ли сканирование держать ИБ-оборону?
APrioriAPosteriori
Спасибо, за то, что результаты Ваших опросов легко доступны в пдф, а не требуют очередную регистрацию и ввод данных, чтобы продажник связался и тп (не то, что доблесные Solarwinds!).
А можно выссказать пожелания на будущие публикации по освещению вопроса, тк из представленных файлов на сайте тоже не удалось отыскать (вполне возможно при реальном прочтении материалов, выяснится, что информация есть): можно ли затронуть и осветить тему взаимодействия команд и отделов, отвечающих за кибербезопасность с пролетариатом и энтузиастами/баунти хантерами? Даже сложно сказать, что имею в виду большие компании с огромными командами, тк из свежих примеров - месяца полтора-два white hacker слал популярному в рунете приложению Clubhouse, с подробными описаними уязвимости, трубил во все двери, заваливал (в прессе можно найти подробности кейса), Клабхаус стабильно игнорировал (по ряду причин аргумент маленького стартапа с лимитированным customer service/техподдержке не выдерживает критики). Положительные примеры часто встречались в истории Spotify - они не только платили, но и в дальнейшем сотрудничали в фриланс-формате с white hackers/баунти хантерами.
Специалисты подтвердят или подкорректируют: зачастую в больших организациях вообще игнорируют такие коммуникации с целью затишить проблему, чтобы она не вышла в публичное русло(не в целях безопасности, а в целях того, чтобы уровень своей некомпетентности не транслировать на весь мир (ну или в коммерческих организациях-не пугать инвесторов, избежать коллапс цены акций компании итд и характер индустрии этой организации немаловажен).
В лучшем случае, фирма организовывала свою Bounty Hunter Rewards Program, но даже среди завсегдатаев гугловских-гитхабовских программ подобного рода, многие подтвердят, что деньги смехотворны и привлекают нередко школьников (ничего не имею против школьников) и самые лучшие находят четкие, а то и уникальные уязвимости, но в современных реалиях сфера ответственности и умение разбираться в законодательной базе (бывает с некоторыми CVE), и куче других дисциплин, требующих профессионального подхода. Было бы здорово, если бы Вы затронули эту проблему, предпочитетельнее был бы формат из каких-нибудь qualitative methods, где респонденты из разных компаний, крупных и маленьких, поделились своими соображениями на тему. (Просто как статистик, я бы исключила опросный подход к этой проблемы по ряду конкретных причин. )
Можно вот еще от хмурого статистика пожелание? В файле Otchet-po-kontrolyu-uyazvimostey_final.pdf, стр 10:
В параграфе сообщается, что авторы как минимум отметили, а судя по параграфу учли квантитативно необходимость сегментирования популяции по группам, заключающихся в количестве сотрудников в компании, эксклюзивно для Вас закопипастю в порядке (от > к <):
крупных(более 5 тыс. человек)
среднего размера (от 250 до 5 тыс. человек)
мелких (менее 250 человек)
категория-мистерия наименованная как "В то же время есть организации, где ИТ-службы никак не реагируют на запрос об установке патчей – таких 12% среди всех опрошенных" <---в этих 12% вышеперечисленные 3 как-то пересекаются? Зачем в одном парраграфе констатируется процент из я так подозреваю общего числа опрошенных, судя по пай-чарту на стр. 11 (мы к нему еще перейдем).
Формулировки при подаче выводов из полученных данных имеют ***ключеовое*** значение, т.к. могут как у нас на хуторе говорят misrepresent the data/your actual results, проманипулировав отвлеченностью или статнеграмотностью читатетля, что в зависимочти от намерений, без пяти минут манипулятивно. Конкретно: фраза "В то же время есть... ", связывающая 12% с предыдущими категориями из совсем другой оперы. Тот факт, что в 2ух из них, крупных и мелких, привлекают первых лиц компании к принятию решений по патчам, что малорелевантно по отношению к тем кто вообще никак не реагируют, ****из общей выборки*****.
Далее, необходимо разъяснить и аргументировать сегментацию таких организаций по кол-ву персонала. Как пришлм к решениям сделать это конкретное ранжирование 5тыс.+, 250-5тыс, <250 ? Почему решили разделить на 3 категории по этим конкретным пределам? Откуда вдохновение пришло, что это?Это приказ ФСТЭК № 239, или 235 регламентирует (случайный пример из вашео документа. Кроме того, почему по количеству персонала - фундаментальный , не решенный вопрос, тк еще на 4ой странице Вы указываете, что выборка состоит из опрошенных сотрудников
т.е. не в какой-то конкретной индустрии (резонно ожидать допустим опрос компаний исключительно, например, ИТ индустрии), но все-таки указанно, что профиль-то разный у компаний(что бы не значило многообещающее "разного профиля",это надо на 4ой же странице и конкретизировать). Отсюда вывод, в совокупности с предыдущей проблемой, почему разделение по группам было решено совершать исходя из критерия "количество сотрудников", а не, в том же предложении на 4ой странице, "профиля" организации? Какую в связи с этим смысловую нагрузку несет деление на 3 категории по кол-ву персонала, т.е. какую информацию до нас доносит весь этот параграф?
Индустрия компании может являться в среднем по моделируемой популяции гораздо более влиятельным фактором на результаты в Ваших пай-чартах. А может и нет, но тогда какая из представленной информации иллюстрирует надобность вообще упоминания этого деления, особенно справа от пай-чарта, к которому она вообще если Вы присмотритесь не имеет отношения.
Расписала бы про пай чарты и еще несколько ключевых моментов которые я бы специалиста попросила переделать, но у меня по причине праздничного настроения открылась минутка непрошеного альтруизма и редкий момент бесплатного статконсалтинга я уже не смогла остановить, простите! Не воспринимайте это как критику на личный счет, просто эти вещи легко исправить на данном этапе, тем более проэкт интересный! Правда мы еще не разобрались в этой выборке из 200, опрошенных на сайте (что с позитивной точки зрения, может предоставить неожиданно содержательную информацию, благодаря данным сайта, но я уже пошла праздновать, всего хорошего в начинаниях в интересной области!)
Solar_MSS Автор
Спасибо за такой подробный и интересный комментарий!
Тема с Bug Bounty, действительно, интересна, но она выходила за рамки нашего опроса. Отразим ее в следующих публикациях.
Относительно методологии: мы размещали опрос на нескольких площадках и не ограничивали круг респондентов конкретной отраслью или размером компании, чтобы получить более широкие результаты. Такое деление по количеству хостов используется нами и в других отчетах, и мы пришли к выводу, что оно достаточно универсально для определения масштаба компании и ее ИТ-инфраструктуры.
Мы делаем акцент именно на масштаб, а не на отрасль, так как проблемы с VM, как правило, носят организационный характер – согласованность работы подразделений, наличие штатных специалистов и т.п. И здесь важен скорее масштаб организации, а не сфера деятельности.