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

Закончу разбирать основной 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-ных пунктов. 😉

CSAM от Positive Technologies

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

CSAM от Positive Technologies

CSAM от Positive Technologies. Посмотрел 2 выступления про Asset Management с PSDay. Если совсем коротко, то было сказано много очень правильных слов про то, что Asset Management это основа практически всех IT-шных и ИБшных процессов (включая управление уязвимостями и инцидентами). Непрерывное детектирование, инвентаризация и классификация разнообразных активов (не только сетевых хостов) это сама по себе важная работа. Главные моменты выступлений, на мой взгляд это то, что:

🔻 Анонсировали новое направление по управлению активами. Выделили команду. Отстраиваются от класса CSAM (CyberSecurity Asset Management). Продукт такого класса есть у одного западного VM-вендора, что +- даёт представление на что это может быть в итоге похоже.

🔻 Представили ранний драфт интерфейса. На нём показана некоторая таблица активов: ОС, скоринг актива, теги, группы, в которые он входит, инструменты безопасности на данном активе и т.д.

Positive Security Day 10-11 октября: что посмотреть про Vulnerability Management?

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

Positive Security Day 10-11 октября: что посмотреть про Vulnerability Management?

Positive Security Day 10-11 октября: что посмотреть про Vulnerability Management? Уже завтра в кластере "Ломоносов" стартует PSDay 2024. Это главное продуктовое мероприятие Positive Technologies. Ориентировано на заказчиков, дистрибьюторов и партнеров. Расскажут о технологической и продуктовой стратегии, что было сделано за год и что появится в ближайшем будущем.

Касательно VM-а я собираюсь смотреть и комментировать следующее:

10 октября
🔻 13:30 - 14:30 (Молекула). "Новая концепция — discover & defend, detect & response". Тут должно быть про место VM-а в современной ИБ организаций.

11 октября
🔻 11:00 - 12:30 (Молекула). Большой блок про Asset Management в контексте РКБ, Vulnerbility Management и Compliance/Configuration Management (MaxPatrol VM и HCC).
🔻 13:00 - 13:30 (Физика). Ещё один блок про Asset Management, но с фокусом на задачи IT.

Также в 13:00 - 14:00 (Корпускула) пройдёт воркшоп по аудиту активов с помощью MaxPatrol.

Боли Asset Management процесса

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

Боли Asset Management процесса

Боли Asset Management процесса. Судя по результатам прошлого опроса, Asset Management-ом в организациях занимаются, но в основном не с использованием специализированных продуктов, а закрывают эти задачи около-AM-ной функциональностью в смежных IT/ИБ решениях.

Давайте теперь наведём статистику, по проблемам, с которыми мы сталкиваемся в процессе управления активами. Ну и тем самым сформируем приоритизированный список задач, которые Asset Management система должна решать. 😉

🗳 Голосуем
🗣 Высказываемся в VK (в частности, интересно почему специализированные AM-решения не используете)

А у вас вообще есть Asset Management процесс в организации?

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

А у вас вообще есть Asset Management процесс в организации?

А у вас вообще есть Asset Management процесс в организации? Прямо вот взрослый с использованием специализированных инструментов? Или хватает около-AM-ной функциональности в смежных IT/ИБ решениях? Или может вам Asset Management вообще не нужен? Давайте выяснять. 🙂

Моё имхо я неоднократно высказывал: Asset Management это наиболее важная часть Vulnerability Management-а. Даже с сетевым периметром разобраться зачастую непросто. А с внутрянкой тем более. В идеале, конечно, было бы хорошо, чтобы ответственность за AM лежала не на самом VM-щике. Чтобы VM-щик только аномалии в учёте активов находил и жаловался. 😅

🗳 Голосуем
🗣 Высказываемся в VK

Вчера Qualys представили CyberSecurity Asset Management 3.0

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

Вчера Qualys представили CyberSecurity Asset Management 3.0Вчера Qualys представили CyberSecurity Asset Management 3.0

Вчера Qualys представили CyberSecurity Asset Management 3.0. В названии решения значится "Asset Management", но само решение сразу презентуется нам как "переопределение управления поверхностью атаки" , т.е. EASM. Такая вот гартнеровская маркетинговая мешанина. 🤷‍♂️ При этом, у Qualys действительно достаточно необычный Asset Managementи и EASM. И необычно как они к этому пришли. Тут, естественно, исключительно мои впечатления как стороннего наблюдателя, никакого инсайда у меня нет.

🔹 В 2020 году Qualys представили решение Global AssetView. Если упрощённо, то пользователи могли бесплатно раскатать облачные агенты Qualys на известные в инфре хосты, развернуть Qualys Passive Sensor для поиска неизвестных активов по трафику и получить некоторое базовое представление о составе инфры и её состоянии (без расчета уязвимостей). Такое Freemium предложение, с которого можно было бы удобно апселить основную функциональность Vulnerability Management и Compliance Management. Ход весьма и весьма смелый.

🔹 В 2021 году как развитие Global AssetView появился продукт CyberSecurity Asset Management. Это уже был заход в полноценное Управление Активами: двусторонняя синхронизация с CMDB ServiceNow, учёт критичности активов, учёт ПО, оценка поверхности атаки при помощи Shodan (последнее тогда не особенно подчёркивали). Насколько я могу понять, изначальная цель CSAM была в том, чтобы отслеживать кейсы, которые влияют на безопасность активов, но уязвимостями, строго говоря, не являются: shadow IT, хосты с подходящими end-of-life (EoL)-of-support (EoS), хосты без установленных EDR, рискованные порты опубликованные в Интернет, мисконфигурации софта и сервисов.

🔹 В 2022 Qualys выпустили CyberSecurity Asset Management 2.0 с интегрированным решением по контролю внешней поверхности атаки (EASM). Сама идея, что EASM можно развивать и продавать в рамках решения по Управлению Активами весьма необычная. Но логика в этом есть. Уменьшение поверхности атаки это не про то, что нужно пропатчить тот или иной торчащий наружу сервер, а про то, что какого-то торчащего наружу старья вообще не должно быть ("if an externally facing asset or its configuration is not necessary for the business, then it should be shut down"). И вот с этой точки зрения EASM это действительно не столько периметровый сканер, сколько хитрая штуковина, которая накидывает неочевидные активы, с некоторой вероятностью относящиеся к компании, и показывает риски с ними связанные. 🐇 🎩 Часть управления активами? Ну видимо да.

Таким образом, насколько я понимаю, сейчас у Qualys есть VMDR (Vulnerability Management, Detection and Response), который включает в себя CSAM (CyberSecurity Asset Management ), который включает в себя EASM (External Attack Surface Management). Такая вот матрёшка. 🪆

А что же в версии CSAM 3.0?

🔻 Убрали упоминания Shodan. "CSAM 3.0 использует новую систему оценки атрибуции и расширяет использование технологий с открытым исходным кодом и собственного интернет-сканера для обеспечения точного обнаружения, атрибуции и оценки уязвимостей" . При атрибуции актива отображаются показатели достоверности (можно по ним фильтровать).

🔻Используются возможности детектирования активов Cloud Agent Passive Sensing (хостовые агенты, снифающие трафик - я о них уже писал)

🔻Коннекторы для интеграции с источниками данных об активах (анонсированы коннекторы для Active Directory и BMC Helix). Видимо раньше интеграции с AD не было. 🤷‍♂️

Как будем описывать активы в Vulremi?

2 комментария

Как будем описывать активы в Vulremi?

Как будем описывать активы в Vulremi? Основная идея, что это должен быть настолько гибкий формат, чтобы в него можно было разложить результаты детектирования уязвимостей из любого решения: коммерческого, опенсурсного, агентного, безагентного. Вообще любого. Поэтому задачу досконально описывать конфигурацию актива сознательно отбрасываем. Берём только то, что понадобится нам в приоритизации уязвимостей (с учётом активов) и их исправлении. 

{
    "asset_id": "important-host1",
    "owner": "marketing_department",
    "patching_engineer": "johnsmith1",
    "patching_rule": "once in a month",
    "asset_value": "key",
    "asset_type": "server",
    "perimeter": false,
    "last_scan": "2024-02-06T21:07:27+00:00",
    "vulnerabilities":
    [
        {
            "vulnerability_id": "CVE-2024-00001",
            "cvss_v3_env": "CR:L/IR:M/AR:M/MAV:N/MAC:L/MPR:N/MUI:N/MS:U/MC:L/MI:L/MA:L",
            "related_objects":
            [
                {
                    "object_type": "ubuntu_package",
                    "name": "anacron",
                    "version": "2.3-38ubuntu1"
                }
            ]
        }
    ]
}

Параметры для описания самого актива

🔹 asset_id - идентификатор актива. Логично было бы использовать для него hostname, но ситуации бывают разные, поэтому не конкретизирую. Возможно это будет id из CMDB-шки.
🔹 owner - ответственный за актив, с которым можно договариваться о регулярных и экстренных обновлениях актива. Обычно какое-то бизнесовое подразделение.
🔹 patching_engineer - тот, кто непосредственно должен обновлять активы. С него нужно спрашивать, если договоренности по регулярным или экстренным обновлениям нарушаются.
🔹 patching_rule - правило регулярного обновления, которое было согласовано с овнером. Если оно нарушается, то спрашиваем с patching_engineer.
🔹 asset_value - ценность актива для злоумышленника. Если, получив доступ к активу, злоумышленник может непосредственно реализовать недопустимое событие, то значит актив целевой (target). Если, получив доступ к активу, злоумышленник может развить атаку на целевой актив, то значит актив ключевой (key). Если и не ключевой, и не целевой, то обычный (ordinary).
🔹 asset_type - тип актива. Critical Infrastructure, Server, Network Equipment, Desktop, Other. Ровно как в методике оценки уровня критичности уязвимости ФСТЭК, примеряемся к использованию. 😏
🔹 perimeter - влияет ли состояние актива на безопасность периметра. Тоже как в методике ФСТЭК.
🔹 last_scan - когда этот актив сканировали на уязвимости в последний раз. Чтобы понимать насколько у нас информация по уязвимостям актуальная. Если нашли активы со старой датой - идём разбираться со сканами.

Параметры для описания уязвимостей на активе

🔸 vulnerability_id - идентификатор уязвимости. CVE. Если нет CVE, то BDU. Если и его нет, то любой уникальный идентификатор уязвимости. По этому идентификатору найдем описание этой уязвимости в объекте типа vulnerability, который я буду описывать позже.
🔸 cvss_v3_env - environmental часть CVSS вектора на случай, если мы захотим поманипулировать через него критичностью уязвимости для данного актива.
🔸 related_objects - объекты актива, связанные с уязвимостью. Опциональная штука, которая может быть использована patching_engineer-ом для того, чтобы понять на что ругается сканер. Если в связанных объектах линуксовый пакет, значит его нужно обновлять и всё будет ок. С другой стороны, там может быть описан не только пакет, но и, например, софт. В этом случае можно будет накрутить логику учёта российский он или нет, а следовательно решать требуется ли тестирование безопасности обновления или не требуется. Но подробнее эту штуку буду расписывать позже, уже после MVP.