Вот Михаил Кондрашин правильную тему поднимает. А где вообще кейсы, когда именно через обновления вендоры блокировали функциональность или добавляли зловредную функциональность? Может это все домыслы? Особенно интересно в контексте текущей новостной повестки. Если есть что добавить, приглашаю присоединиться к обсуждению в ВК.
А как собственно изменилась работа с уязвимостями в 2022 году? Возвращаясь к названию исследования Positive Technologies. Как я вижу.
1. Раньше было страшно не успеть обновиться и получить инцидент с эксплуатацией уязвимости. Теперь ещё страшно обновиться и получить кирпич или бэкдор, потому что вендор решил прогнуться под геополитику. Эти страхи борются. Сейчас ситуация несколько стабилизировалась и первый страх побеждает. Что завтра будет неизвестно.
2. Замена ПО на стабильное (отечественное) выглядит как избавление от второго страха и возврат к более простому и надежному процессу. VM-щики могут этому способствовать, но их слово вряд ли будет решающим. Более значима позиция регуляторов, бизнеса и IT.
3. Переход на стабильное (отечественное) ПО совсем не обязательно будет простым с точки зрения VM. Есть сомнения в зрелости вендоров ПО. Заводят ли они уязвимости своих продуктов в БДУ? Выпускают ли бюллетени безопасности? Если не будет идентификаторов уязвимостей и бюллетеней, значит не может быть адекватной поддержки в VM решениях. Хотелось бы, чтобы регуляторы обращали на это внимание и выдвигали такие требования к сертифицированным решениях и решениям находящимся в реестрах.
4. С VM-решениями стало хуже. Западные вендоры официально ушли, продолжать использовать их решения теоретически можно, но сложно и они становятся менее эффективны с учетом перехода организаций на стабильное (отечественное) ПО, которое в западных VM-решениях не поддерживается. Для приобретения VM решения доступно сейчас 3-4 опции и стоимость у них отнюдь не как у Nessus Professional. Нужно раскошеливаться или проявлять изобретательность. А скорее и то, и другое.
5. Регуляторы начали уделять гораздо больше внимания исправлению уязвимостей в организациях. С информированием стало на порядок лучше. Не удивлюсь, если скоро мы увидим ещё и жесткий публичный ататат за неисправление уязвимостей, о которых было проинформировано, приведшее к серьезным инцидентам. С одной стороны ответственность растет, а с другой стороны и обосновывать важность VM-а становится гораздо проще.
Прочитал исследование Positive Technologies "Как изменилась работа с уязвимостями в 2022 году". Впечатления не очень. Компания мне родная. Особенно команда VM. Но тут вопросы не к ним, а к авторам этого исследования.
1. Мое мнение, что любая публикация про Vulnerability Management в России это здорово. Особенно если это исследование, а не рекламный проспект. Это порождает дискуссию, подсвечивает проблемные места и в конечном итоге улучшает качество продуктов и конкурентоспособность отечественных VM компаний.
2. В данном случае методология исследования вызывает вопросы. Публичный опрос на "сайте Positive Technologies, интернет-порталах, посвященных ИБ, в социальных сетях, тематических чатах и Telegram-каналах" с интерпретацией результатов автором отчета это не то, что хотелось бы видеть. Это делать дешево и просто, но при этом напрочь теряется контекст.
3. Формулировки вопросов странные. "Какие продукты вы используете для управления уязвимостями?" Множественный выбор. 43% "используют решения open-source". – Петька, приборы! – 20! – Чё "20"?! – А чё "приборы"? О чем здесь речь? Сканируют ли сетку nmap-ом? Используют опенсурсные утилиты для детекта уязвимостей? OpenVAS? OpenSCAP/Wazuh? Есть что-то достаточно хорошее опенсурсное для сканирования Windows? Может это не про детект, может просто результаты детекта в опенсурсный Faraday складывают?
4. Варианты ответов неполные. На вопрос "Где вы ищете информацию о новых уязвимостях?" получили аномалию, что БДУ ФСТЭК используют больше чем NVD. Переходим на отечественные источники! Как тебе такое Илон Маск?! Но в вариантах ответа нет важного в нашей стране источника данных об уязвимостях - бюллетеней регуляторов. Они как раз и содержат ссылки на БДУ. Может результаты показывают не то, что люди БДУшный фид анализируют, а то, что они реагируют на рассылки регуляторов и лезут потом в БДУ?
5. Формулировки выводов странные. "Проблемы с организацией патч-менеджмента остаются у каждого десятого респондента." А у 90% нет проблем с организацией патч-менеджмента? Все автоматом патчится-тестится, VM не нужен, расходимся?
6. Вопросы "как быстро вы это делаете ?" - просто песня. Это как, извините, в анекдоте про разницу в размерах у жителей в Вилариба и Вилабаджо. В одной деревне измеряли, а в другой опрашивали. Абстрактные уязвимости на абстрактных активах исправляются за какое-то время. Получили, что 75% опрошенных закрывают критически опасные уязвимости на важных активах за неделю и меньше! А в месяц укладываются 90%! При этом на фултайме VM-ом практически никто не занимается. "Какой процент рабочего времени занимают задачи специалиста по ИБ, связанные с VM?" Свыше 75% процентов только у 4% опрошенных. Удивительно!
7. Раздел "Какими возможностями должно обладать VM-решение для вашей компании?" норм. Важные фичи перечислены. Есть некое лукавство, очень уж они похожи на фичи и бэклог MaxPatrol VM, но это ладно. Если бы весь опрос был преимущественно в эту сторону и опрашиваемые могли предлагать свои варианты, то это могло быть любопытно.
Критикуешь - предлагай. Кажется правильным изменить методологию. Не опрашивать всех подряд. Работать адресно с людьми, которые специализируются на VM-е. Собрать экспертную группу. В рамках этой экспертной группы отобрать человек 50. Провести с ними полноценные интервью минут на 30. Задавать примерно те же вопросы, но получить развернутые ответы, а не выбор вариантов из опросника. В чем трудности VM-а? Что работает, что не работает? Спрашивать о фиксах конкретных актуальных уязвимостей, например Log4Shell или ProxyShell, как с ними справлялись? Как устроен процесс патчинга? Как патчатся неудобные активы: BIOS/UEFI, прошивки устройств и т.п.? Да, такие ответы будет сложнее и дороже анализировать. Но будет видна более-менее реальная картина. Возможно какие-то best practices можно будет сформулировать. Ну и вопросы, а затем и результаты, неплохо бы с экспертной группой провалидировать, чтобы исключить откровенные странности и ляпы.
Напоследок напишу про многострадальный @VMconf, https://vmconf.pw/. Очень удачный год я выбрал для попытки запуска некоммерческого международного эвента в области VM-а, ничего не скажешь. 😅 В воздухе прям веет международным экспертным сотрудничеством. Плюс ещё мои безумные организаторские скиллы интроверта. Все сошлось. За всё время удалось заинтересовать участием только одного человека, и тот весной ожидаемо окуклился. Та й на краще это сейчас наверное, евпочя. 🙂 Поэтому в этом году VMconf в режиме странноватого моноспектакля. До конца года ещё парочку видео собираюсь для него записать. НО (!), если кто-то хочет запостить свою видяшку на английском по теме VM-а, это всячески приветствуется. Если есть идеи-предложения на следующий год тоже пишете. Домен на год проплатил, в эту авантюру все ещё верю. 🤓
Несколько организационных моментов. В опросе по открытию комментов победил пункт "открыть". Но открывать я все равно не буду. Уот так вот. 🙂
Походил по ИБшным канальчикам с открытыми комментариями. Нигде не увидел ламповых дискуссий. Сплошное адище, токсичность и оффтоп. Понять можно. Время сейчас непростое. Плюс поправка на осень. Но перспектива взваливать на себя дополнительную бесполезную работу по просеиванию чужого негатива мне совсем не улыбается. Свою кукуху я тоже стараюсь беречь. 😇
Если хочется дать обратную связь, то это можно сделать следующими способами:
1) Лучше всего развернуто написать мне в личку @leonov_av, что я в чем-то не прав или что-то не учитываю. Мы пообщаемся, разберем аргументы, и вполне вероятно, что я скомпоную полученные знания в новый пост и отправлю в канал. В итоге мы и горизонтальные связи прокачаем, и больше полезного контента нагенерим. Сплошной win-win.
2) Если хочется публичного общения в телеграмме, то есть чат @avleonovchat. Единственный момент - он строго англоязычный. Это для того, чтобы зарубежные коллеги прошаренные в теме VM-а тоже могли принимать участие в дискуссии. Не стесняйтесь, автоматический перевод вполне сойдет. Т.к. в чатик постоянно добавляются рекламные боты, а антибот системы для тележеньки довольно убогие, то я просто проверяю подписан ли новый смахивающий на бота молчаливый человек на каналы @avleonovcom или @avleonovrus и если нет, то баню. Вроде пока такой примитивный способ неплохо работает. Но если кого-то случайно заблокирую, пишите в личку, поправим.
3) Также я тащу все посты отсюда в ВК-шечку. Можете зайти на мою страничку найти там пост и откомментить. Вот к примеру Андрей Бешков вступился за бывшего работодателя и не согласен с тем, что Microsoft кейлоггер в Windows добавили. 🙂 Не без перехода на личности конечно ответил, но дискуссия пошла достаточно адекватная. Удачный пример. 👍 Также я охотно добавляю в друзьяшки всех, кто судя по профилю как-то связан с ИБ или в личке представился, так что welcome.
4) Наконец в той же ВК-шечке есть сообщество Управление Уязвимостями и прочее, куда я также весь контент аккуратно переношу . Так как я ненастоящий блоггер и все делаю неправильно, то там у меня 47 подписчиков, а не 4301, как у Андрея Прозорова. Это я не из зависти (хотя безусловно 🙂), a к тому, что сообщества в ВК тоже подходят для комьюнити-билдинга, так что если хотите можете тоже подписаться и комментить там.
Ну или сердечко посту поставьте или палец вверх, тоже норм обратная связь. 😊
![Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910](https://avleonov.ru/wp-content/uploads/2023/10/photo_46@07-10-2022_16-01-42.jpg)
Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910. Прочитал исследование. Может я что-то не понял, но похоже из мухи слона делают. Описание-то прямо страшное: "Jamf Threat Labs recently discovered a new macOS vulnerability in Archive Utility that could lead to the execution of an unsigned and unnotarized application without displaying security prompts to the user, by using a specially crafted archive". Можно подумать, что скачал пользователь архив, кликнул по нему случайно и всё, похачен.
На самом деле там пишут про вот этот механизм macOS:
"Когда архив загружается из Интернета, он будет содержать расширенный атрибут com.apple.quarantine. Этот расширенный атрибут укажет macOS, что файл был загружен из удаленного источника и должен быть проверен, прежде чем будет разрешено его выполнение. Когда утилита архивирования извлекает архив, она применяет атрибут карантина ко всем извлеченным элементам. Это обеспечивает соответствующее распространение атрибута карантина и проверку Gatekeeper-ом любых открытых исполняемых файлов".
И вот простановку атрибута com.apple.quarantine (и проверку Gatekeeper) исследователи научились обходить.
"Когда пользователь загружает и запускает такой архив, он будет открыт Archive Utility в следующем виде. [картинка] Как мы видим, приложение не имеет атрибута карантина и, следовательно, будет обходить все проверки гейткипера, позволяя выполняться unnotarized a и/или неподписанным двоичным файлам."
То есть пользователь должен скачать архив и запустить оттуда зловредное приложение и тогда ему не дадут по рукам встроенные механизмы безопасности. Но возможно дадут по рукам какие-то другие механизмы безопасности.
В общем, уязвимость это? Уязвимость. Критикал ли это, который нужно срочно патчить? Ну вроде нет. Возможно повод научиться искать подобные архивы в почте.
Интересный пост вышел вчера в блоге Qualys. Про устаревшие активы. Суть в следующем. В ходе эксплуатации Vulnerability Management системы в неё добавляются активы. В основном сетевые хосты, но в случае Qualys не только. На них каким-то образом, агентно или безагентно детектируются уязвимости. И вот по какой-то причине данные по некоторому активу перестают обновляться. Как правило, это связано с тем что актива больше нет. Сервер выключили, виртуалку удалили, десктоп перезалили и т.п. А в интерфейсе Qualys актив продолжает отображаться, для него показываются уязвимости, он в лицензии учитывается. Непорядок.
И какую же функциональность предлагает Qualys для решения этой проблемы? Во-первых отображают активы в дашборде, с разбивкой по дате последнего обновления данных. Уже неплохо. Как минимум можно поресерчить что с этими активами случилось. Во-вторых можно настроить правила, которые будут активы неактивные больше N дней удалять. Это конечно не самое хорошее решение, десятки дней терпеть в VM-е зомби-хосты и неисправляемые уязвимости на них. Но зато просто. И эти правила не работают для "IP/DNS/NetBIOS tracked scanned assets (no Cloud Agent)", для них там ручной метод предлагается.
Но, имхо, самое лучшее решение, о котором в посте не пишут это забирать актуальные статусы активов непосредственно из IT-систем через которые они управляются, залезать в VM решение по API и оперативно подчищать неживое. Благо у Qualys API мощный и такие штуки можно делать без проблем. Кастомная автоматизация рулит! 🙂
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.