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

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки.

Добавить комментарий

Закончу разбирать основной VM-ный пункт 3.3. Управление уязвимостями (КУ) из недавно опубликованного методического документа Мероприятия и меры по защите информации, содержащейся в информационных системах, и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки.

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки. В прошлый раз я расписал Цели и Требования к реализации, сегодня рассмотрю Требования к документированию и Требования к усилению.

ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

Фактически весь раздел описывает требования к содержанию внутреннего регламента по управлению уязвимостями информационных систем.

👥 Подразделения / работники

"перечень подразделений (работников), ответственных за организацию и контроль управления уязвимостями, а также участвующих в реализации процессов управления уязвимостями, их обязанности (функции) и права (полномочия);"

Получается, что подразделения (работники) делятся на:

🔹 ответственных за организацию и контроль управления уязвимостями;
🔹 участвующих в реализации процессов управления уязвимостями.

Для каждого подразделения (работника) необходимо расписать:

🔹 обязанности (функции);
🔹 права (полномочия).

Напрашивается таблица следующей структуры:

Подразделение (работник); За что отвечает; В реализации каких процессов участвует; Обязанности (функции); Права;

📋 Операции

Требования по документированию операций имеют идентичную структуру:

"описание операций, осуществляемых при {название этапа (подпроцесса)}, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при {название этапа (подпроцесса)}"

Буквально вот так:

"описание операций, осуществляемых при мониторинге уязвимостей и оценке их применимости, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при мониторинге уязвимостей и оценке их применимости;
описание операций, осуществляемых при оценке уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при оценке уязвимостей;
описание операций, осуществляемых при определении методов и приоритетов устранения уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при определении методов и приоритетов устранения уязвимостей;
описание операций, осуществляемых при устранении уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при устранении уязвимостей;
описание операций, осуществляемых при контроле устранения уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при контроле устранения уязвимостей;"

Напрашивается таблица следующей структуры:

Этап (подпроцесс); Наименование операции; Описание операции; Перечень исполнителей; Продолжительность реализации; Входные данные; Выходные данные;

Типовые операции и их описания можно взять из Таблиц 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2 "Руководства по организации процесса управления уязвимостями в органе (организации)" от 17 мая 2023 г. (далее для краткости буду обозначать документ как РУУ23).

🗺️ Схемы

"схемы взаимодействия подразделений (работников) при реализации операций по управлению уязвимостями."

Интересно, что здесь требуются схемы взаимодействия при реализации операций. А операция, в терминах РУУ23, - это что-то более-менее атомарное, чем занимается один исполнитель. Например, "Анализ информации об уязвимости" или "Корректировка механизмов мониторинга". Это не тот уровень, где подразумевается взаимодействие. Есть подозрение, что авторы здесь имели в виду не конкретные операции, а этапы (подпроцессы). По аналогии с тем, как этапы разрисованы в РУУ23 на Рисунках 2.2, 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2. Здесь требуется разъяснение регулятора, какие именно схемы должны быть приведены в регламенте. Текущая формулировка неоднозначна.

📜 Какие различия с драфтом?

В релизе убрали требование "перечень информационных систем, для которых осуществляется управление уязвимостями;". Скорее всего, этот пункт убрали, чтобы не привязывать регламент к статическому перечню информационных систем, который быстро устаревает и дублирует данные из CMDB или реестра активов, а также чтобы закрыть лазейку формального комплаенса, когда систему можно просто не включить в список и не управлять её уязвимостями; в результате область применения становится неявно шире и распространяется на все релевантные ИС, что делает подход более процессным и универсальным.

Остальные правки касались только орфографии.

К сожалению, требования к документированию не затрагивают, как именно описываются уязвимости и как ставятся задачи для IT на их устранение. 😔 А ведь именно от качества описаний и постановки задач зависит, будут ли уязвимости корректно поняты и устранены в требуемый срок. Без этого процесс управления уязвимостями рискует остаться формальным.

ТРЕБОВАНИЯ К УСИЛЕНИЮ

Насколько вообще обязательны требования из этого раздела? Читаем в сноске в пункте 3.1:

"Усиления мероприятий (процессов) по защите информации, приведенные в подразделах «требования к усилению» раздела 3, применяются по решению оператора (обладателя информации) для повышения эффективности реализации мероприятий по защите информации и повышения уровня защищенности информационных систем и содержащейся в них информации, а также для снижения возможности нарушителей по реализации угроз безопасности информации.

⚙️ Автоматизация

1) для управления уязвимостями используются автоматизированные системы управления уязвимостями;

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

👾 Анализ угроз

2) для мониторинга уязвимостей применяются средства анализа угроз, в том числе TI-платформы;

Фактически это требование означает, что управление уязвимостями должно стать частью CTEM (Continuous Threat Exposure Management) и учитывать данные о реальной эксплуатации уязвимостей: какие из них уже используются атакующими, какие техники применяются и в каких сценариях. В связке с анализом путей атаки это позволяет понимать, как уязвимости используются злоумышленниками для проникновения к целевым активам, и соответственно приоритизировать их устранение.

🗃️ CMDB

3) для оценки применимости уязвимостей используются данные, содержащиеся в автоматизированных системах сбора и хранения данных об объектах инвентаризации и их конфигурациях (СMDB-системы); (в документе в "СMDB" кириллическая С 🤷‍♂️)

Это нужно, чтобы управление уязвимостями опиралось на полный и актуальный контекст инфраструктуры. CMDB задаёт перечень активов, их конфигурации, связи и критичность для бизнеса. Без CMDB информацию об активах приходится получать исключительно методом активного сканирования, у которого могут быть ограничения по полноте и точности.

🤝 Смежные процессы

4) для контроля устранения уязвимостей используются результаты мониторинга информационной безопасности или управления обновлениями, или управления конфигурациями.

Это требование означает, что контроль устранения уязвимостей должен опираться на перекрёстные проверки из уже существующих процессов - мониторинга ИБ, управления обновлениями и управления конфигурациями. Такой подход снижает риск ошибок, когда устранение уязвимости подтверждается только средством анализа защищённости (САЗ), но фактически проблема в системе сохраняется. Использование нескольких независимых источников позволяет подтвердить факт устранения с разных сторон и повысить достоверность контроля.

📜 Какие различия с драфтом?

В релиз не вошло требование "для мониторинга уязвимостей и оценки их применимости используются результаты контроля (оценки) уровня защищенности информации;"

Очень жаль, что убрали этот пункт, потому что результаты пентестов и независимого анализа защищённости часто выявляют уязвимости, которые по каким-то причинам не обнаруживаются штатными САЗ, используемыми в процессе управления уязвимостями. Такие находки являются индикатором проблем в процессе: недостаточного покрытия активов, низкого качества детектирования или несоблюдения сроков устранения. Они позволяют объективно оценить эффективность VM-процесса и улучшить его.

Остальные исправления касаются опечаток и косметических изменений.

---

Вот такой получился разбор. Пишите в комментариях, понравился ли формат и следует ли продолжать разбор других VM-ных пунктов. 😉

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

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

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

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