Архив метки: VulnerabilityManagement

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit "Стратегия и тактика информационной безопасности"

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit Стратегия и тактика информационной безопасности

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit "Стратегия и тактика информационной безопасности". У меня там будет короткий доклад про эволюцию Vulnerability Management-а в Exposure Management. Буду рассказывать про то, как мы все жили не тужили где-то с начала нулевых: детектировали и приоритизированно устраняли уязвимости и мисконфигурации, называя это "Управление Уязвимостями". А потом бац - в 2017 году маркетологи Tenable придумали для позиционирования своих решений на рынке использовать вместо уязвимостей слово "exposures" - максимально обтекаемое и неконкретное даже на английском, а тем более при попытках перевести его на русский. И эти самые "exposures" настолько зашли консалтерам из Gartner, что где-то с 2022 года они стали использовать их в хвост и гриву в рамках своей концепции "продвинутого VM-а" под аббревиатурой CTEM (Continuous Threat Exposure Management). И т.к. Gartner в деле ИБ-шного маркетинга могущественны и влиятельны, то сейчас на Западе VM практически закончился. 🤷‍♂️ У всех бывших VM-вендоров сплошной CTEM через CTEM, естественно определяемый так, как конкретному вендору выгодно. 😏 И, соответственно, масса сопутствующей маркетинговой активности: новые продуктовые ниши для решений (EAP, AEV, VPT, EASA, CAASM, APM, APA, BAS, Auto PT, CART, APS, TIP, DRPS, ASCA, X-SPM - можно подумать, что я рандомно стучу по клавиатуре, но нет 😅), новые квадранты, масса аналитики на тему (полезной и не очень). Работают люди! 😉

И тут, глядя на это западное маркетингово-консалтинговое пиршество духа из подсанкционной России, возникает вопрос: игнорировать его или интерпретировать (желательно не сильно противореча оригиналу) и попытаться извлечь некоторую практическую пользу (чтобы EM не выхолостился просто в модный синоним VM-а). Учитывая, что мы чай не в лесу живём, игнорировать не выглядит хорошим вариантом - всё это так или иначе сюда придёт и будет использоваться. Получается, следует включаться в это использование, чётко определяя, что такое exposures (экспозиции, "уязвимости в широком смысле"), что такое Exposure Management ("управление экспозициями"), что такое CTEM ("непрерывное управление экспозициями с учётом угроз") и какая функциональность для этих классов решений является ключевой и приносящей реальную пользу.

В общем, примерно таким будет выступление. Заглядывайте на мероприятие, пообщаемся. 🙂 Positive Technologies - генеральный партнёр, поэтому на стенде про PT-шный взгляд на CTEM тоже расскажем и покажем продукты, которые его реализуют. 😉

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision

Продолжу разбирать 10 неудобных вопросов Product Manager-у по VM из подкаста коллег из R-Vision

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision.

Вопрос 2: Вы можете гарантировать, что в вашем сканере уязвимостей не будет фолзов?

💬 Андрей Селиванов сначала пошутил, что можно гарантировать отсутствие фолзов, если просто не проводить сканирование. 😏 Далее сказал, что фолзы (некорректные детекты каких-то уязвимостей) есть в абсолютно любом решении. Причин для этого может быть масса: от некорректной информации по детектированию уязвимости в источнике данных об уязвимости (например, бюллетене RHSA вендора Red Hat или на странице с описанием уязвимости Microsoft) до ошибок при написании правил детектирования на стороне VM-вендора. Важны два параметра: процент допустимых фолзов в решении VM-вендора и то, как быстро VM-вендор их устраняет (принимая от клиентов через форму обратной связи).

#️⃣ С этим тоже не поспоришь. Но я бы посмотрел несколько шире. Фолзы - это не только про то, что какие-то конкретные правила детектирования были реализованы некорректно. Хотя, безусловно, и это тоже, и хотелось бы, чтобы такие проблемы VM-вендор ловил самостоятельно, а не только после того, как их зарепортят клиенты. 😉 Это ещё и про зрелое восприятие возможностей VM-продукта и зрелое позиционирование VM-продукта вендором.

🔹 Если сканер не детектирует какие-то уязвимости в инфраструктуре, потому что не поддерживает те или иные продукты или способы установки, это со стороны клиента может выглядеть как false negative. А может как вполне осознаваемые ограничения детектирования VM-продукта.

🔹 И с другой стороны, то, что упомянул вскользь Андрей "многое зависит от окружения, от специфических условий", когда сканер детектирует уязвимости в библиотеке, которая по факту не используется, это может восприниматься со стороны клиента как жуткие false positive ошибки. А может как особенность детектирования "потенциальных" уязвимостей сканером.

Тут, наверное, хотелось бы, чтобы мы (как VM-комьюнити) отходили от восприятия любых средств анализа защищённости как волшебных оракулов, которые выдадут все 100% имеющихся уязвимостей в инфраструктуре. Конечно же, нет. 🤷‍♂️

Детектирование всех уязвимостей конкретной инфраструктуры - это сложная задача. За которую ответственен в первую очередь VM-специалист. И VM-специалист должен понимать ограничения используемых средств анализа защищённости и выбирать наиболее адекватные из них (а не самые дешёвые 😉).

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM"

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) 10 неудобных вопросов Product Manager-у по VM

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM". Естественно, обсуждение шло в контексте решения R-Vision VM. Интересный формат и подборка вопросов. 🔥 Собираюсь их постепенно разобрать и добавить свои комментарии. 😉

Вопрос 1: Класс Vulnerability Management решений - это маркетинговая обёртка сканеров уязвимостей или за этим есть какие-то дополнительные технологии?

💬 Андрей Селиванов ответил в духе, что VM-решения - эволюционное развитие сканеров уязвимостей, потребность в которых возникла с увеличением количества активов (сказал, что у них есть клиент с 300 000 конечных точек и сотней миллионов уязвимостей) и увеличением разнообразия типов активов. Все уязвимости на этих активах необходимо эффективно детектировать, приоритизировать и ставить задачи на устранение. С простым сканером уязвимостей с таким объёмом справляться сложно, требуется более функциональное решение. "Но сканер - это то, по чему встречают решение в любом пилоте и у любого клиента". Важно, насколько качественно выявляются уязвимости, насколько широкое покрытие. "Если у тебя не будет нормального сканера, называться полноценным VM-решением - ну такое себе".

#️⃣ В целом, согласен со сказанным. Особенно в части качества детектирования. 👍 Единственное я бы выделил такие формальные признаки сканера уязвимостей и VM-решения: если средство анализа защищённости (САЗ) работает в парадигме отдельных сканов - это сканер уязвимостей. Классический пример - Nessus. А если САЗ хранит картину текущего состояния всей инфраструктуры (активов и уязвимостей на них), позволяет делать выборки по уязвимостям, делать приоритизацию уязвимостей, заводить и отслеживать задачи на устранение (через встроенную тикетницу или через интеграции) и производить прочую высокоуровневую обработку, то это уже решение класса Vulnerability Management. Потому что это решение реализует внутри себя Vulnerability Management процесс. Ну или, во всяком случае, вендор решения это декларирует и к этому стремится. 😉

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

🔹 И сканер уязвимостей может быть оправданно дорогим, если он реализует востребованную, крутую и качественную экспертизу по детектированию. Даже если он поставляется в виде консольной утилиты, а то и вовсе в виде фида с контентом.

🔹 В свою очередь VM-решение может лишь формально реализовывать заявленную функциональность и, к примеру, не справляться с реальной нагрузкой (особенно если его навайбкодили за выходные 😉). VM-решение вообще может быть опенсурсным проектом, типа Faraday Security или DefectDojo, и стоить (ну, в теории 😏) 0 руб.

Так что маркетинговые категории мало чего значат на самом деле. Нужно смотреть в суть.

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости. Есть готовые интеграции с Security Vision или R-Vision (+ компании предоставили урезанные бесплатные версии продуктов только для инвентаризации), BiZone TDR и GRC, Ansible.

Для уязвимостей есть признаки эксплуатации вживую и публичные эксплоиты, есть расчёт критичности по методике ФСТЭК, есть проверенные патчи (они там появляются раньше и их больше, чем на БДУ ФСТЭК), можно заводить задачи на устранение с автоматическим закрытием при перескане.

Напоминает зародыш российского "Qualys-а". 🤔 Не хватает только облачных агентов и апплаенсов. И неплохо было бы загружать не только инвентаризацию, но и уязвимости продетектированные сторонним сканерами. 😉

Учитывая, что это всё бесплатно, всему нашему VM-рынку стоит обратить внимание и задуматься, чем это крыть.

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening. 😉 По поводу этой картинки Mads Bundgaard Nielsen-а, о которой писали Александр Редчиц и Алексей Лукацкий, у меня вопросов нет. Ну, во всяком случае, по моей части. 😏

Видим у Vulnerability Management-а и Compliance Management-а (Наrdening-а) очень высокую эффективность при средней цене. И это должен быть первый приорититет у CISO. ⚡️

После Firewall-а. 🙄 Тут спорно, но пусть будет так. Без NGFW заниматься безопасностью действительно не сладко.

В общем, одобряю картинку. 🙂👍

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким. У Алексея Викторовича очень необычный взгляд на вопросы Vulnerability Management-а и мастерские формулировки. 👍🙂📝 Отметил для себя 3 темы, которые было бы интересно подробнее разобрать:

🔻 VM и облачные SaaS-провайдеры. Как контролировать, что провайдер имеет адекватный VM-процесс (да и вообще ИБ) у себя, учитывая, что в случае инцидента отвечать будет не провайдер, а клиент-жертва.

🔻 Статьи о гос. измене / шпионаже (УК РФ 275, 276) и репортинг уязвимостей зарубежным вендорам, организациям и базам уязвимостей. Насколько реальна опасность для исследователя, как поступать правильно и безопасно?

🔻VM-вендорам интересно поддерживать не все продукты. Что делать клиентам (навскидку: пушить VM-вендора, пилить свои детекты, выбирать решения с учётом возможностей VM)?

"Патчить абсолютно всё невозможно и безыдейно" меня, конечно, триггернуло. 🙄

Стоит ли использовать в вашей организации пиратское VM-решение?

Стоит ли использовать в вашей организации пиратское VM-решение?

Стоит ли использовать в вашей организации пиратское VM-решение? На аргументах про этичность и законность останавливаться не буду (см. 146, 272, 273 УК РФ и штрафы для юрлиц). 🙂 По технике:

🔻 Как вы можете гарантировать, что в скаченную откуда-то сборку не внесли НДВ? Троян, майнер, криптолокер с отложенным запуском. Это вполне естественный способ монетизации для релиз-команды. И чем вы оправдаетесь в случае инцидента?
🔻 В развернутое VM-решение будут забивать учётки для сканирования. Оно будет заходить на таргет-хосты и выполнять произвольные команды (как правило, с привилегиями рута/админа). Вы точно хотите "ZVER-сборку" туда пускать?
🔻 Если у вас правила детектирования уязвимостей не обновляются, то вы сможете определить с помощью такого решения только старый ли таргет-хост как гуано мамонта или нет. Полезность сомнительная. 🙂

А главное нафига рисковать, если можно официально запросить у вендора триалку и тестить сколько потребуется с поддержкой и прочим. 😉