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

В этот четверг, 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"

1 комментарий

Смотрю подкаст коллег из 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 руб.

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