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

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

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

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

Вчера Qualys представили Cyber­Se­cu­ri­ty Asset Man­age­ment 3.0. В названии решения значится "Asset Man­age­ment", но само решение сразу презентуется нам как "переопределение управления поверхностью атаки" , т.е. EASM. Такая вот гартнеровская маркетинговая мешанина. 🤷‍♂️ При этом, у Qualys действительно достаточно необычный Asset Man­age­men­tи и EASM. И необычно как они к этому пришли. Тут, естественно, исключительно мои впечатления как стороннего наблюдателя, никакого инсайда у меня нет.

🔹 В 2020 году Qualys представили решение Glob­al AssetView. Если упрощённо, то пользователи могли бесплатно раскатать облачные агенты Qualys на известные в инфре хосты, развернуть Qualys Pas­sive Sen­sor для поиска неизвестных активов по трафику и получить некоторое базовое представление о составе инфры и её состоянии (без расчета уязвимостей). Такое Freemi­um предложение, с которого можно было бы удобно апселить основную функциональность Vul­ner­a­bil­i­ty Man­age­ment и Com­pli­ance Man­age­ment. Ход весьма и весьма смелый.

🔹 В 2021 году как развитие Glob­al AssetView появился продукт Cyber­Se­cu­ri­ty Asset Man­age­ment. Это уже был заход в полноценное Управление Активами: двусторонняя синхронизация с CMDB Ser­vi­ceNow, учёт критичности активов, учёт ПО, оценка поверхности атаки при помощи Shodan (последнее тогда не особенно подчёркивали). Насколько я могу понять, изначальная цель CSAM была в том, чтобы отслеживать кейсы, которые влияют на безопасность активов, но уязвимостями, строго говоря, не являются: shad­ow IT, хосты с подходящими end-of-life (EoL)-of-support (EoS), хосты без установленных EDR, рискованные порты опубликованные в Интернет, мисконфигурации софта и сервисов.

🔹 В 2022 Qualys выпустили Cyber­Se­cu­ri­ty Asset Man­age­ment 2.0 с интегрированным решением по контролю внешней поверхности атаки (EASM). Сама идея, что EASM можно развивать и продавать в рамках решения по Управлению Активами весьма необычная. Но логика в этом есть. Уменьшение поверхности атаки это не про то, что нужно пропатчить тот или иной торчащий наружу сервер, а про то, что какого-то торчащего наружу старья вообще не должно быть ("if an exter­nal­ly fac­ing asset or its con­fig­u­ra­tion is not nec­es­sary for the busi­ness, then it should be shut down"). И вот с этой точки зрения EASM это действительно не столько периметровый сканер, сколько хитрая штуковина, которая накидывает неочевидные активы, с некоторой вероятностью относящиеся к компании, и показывает риски с ними связанные. 🐇 🎩 Часть управления активами? Ну видимо да.

Таким образом, насколько я понимаю, сейчас у Qualys есть VMDR (Vul­ner­a­bil­i­ty Man­age­ment, Detec­tion and Response), который включает в себя CSAM (Cyber­Se­cu­ri­ty Asset Man­age­ment ), который включает в себя EASM (Exter­nal Attack Sur­face Man­age­ment). Такая вот матрёшка. 🪆

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

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

🔻Используются возможности детектирования активов Cloud Agent Pas­sive Sens­ing (хостовые агенты, снифающие трафик — я о них уже писал)

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

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

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

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

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

{
    "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 — идентификатор актива. Логично было бы использовать для него host­name, но ситуации бывают разные, поэтому не конкретизирую. Возможно это будет id из CMDB-шки.
🔹 own­er — ответственный за актив, с которым можно договариваться о регулярных и экстренных обновлениях актива. Обычно какое-то бизнесовое подразделение.
🔹 patching_engineer — тот, кто непосредственно должен обновлять активы. С него нужно спрашивать, если договоренности по регулярным или экстренным обновлениям нарушаются.
🔹 patching_rule — правило регулярного обновления, которое было согласовано с овнером. Если оно нарушается, то спрашиваем с patching_engineer.
🔹 asset_value — ценность актива для злоумышленника. Если, получив доступ к активу, злоумышленник может непосредственно реализовать недопустимое событие, то значит актив целевой (tar­get). Если, получив доступ к активу, злоумышленник может развить атаку на целевой актив, то значит актив ключевой (key). Если и не ключевой, и не целевой, то обычный (ordi­nary).
🔹 asset_type — тип актива. Crit­i­cal Infra­struc­ture, Serv­er, Net­work Equip­ment, Desk­top, Oth­er. Ровно как в методике оценки уровня критичности уязвимости ФСТЭК, примеряемся к использованию. 😏
🔹 perime­ter — влияет ли состояние актива на безопасность периметра. Тоже как в методике ФСТЭК.
🔹 last_scan — когда этот актив сканировали на уязвимости в последний раз. Чтобы понимать насколько у нас информация по уязвимостям актуальная. Если нашли активы со старой датой — идём разбираться со сканами.

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

🔸 vulnerability_id — идентификатор уязвимости. CVE. Если нет CVE, то BDU. Если и его нет, то любой уникальный идентификатор уязвимости. По этому идентификатору найдем описание этой уязвимости в объекте типа vul­ner­a­bil­i­ty, который я буду описывать позже.
🔸 cvss_v3_env — envi­ron­men­tal часть CVSS вектора на случай, если мы захотим поманипулировать через него критичностью уязвимости для данного актива.
🔸 related_objects — объекты актива, связанные с уязвимостью. Опциональная штука, которая может быть использована patch­ing_en­gi­neer-ом для того, чтобы понять на что ругается сканер. Если в связанных объектах линуксовый пакет, значит его нужно обновлять и всё будет ок. С другой стороны, там может быть описан не только пакет, но и, например, софт. В этом случае можно будет накрутить логику учёта российский он или нет, а следовательно решать требуется ли тестирование безопасности обновления или не требуется. Но подробнее эту штуку буду расписывать позже, уже после MVP.

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr

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

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Glob­al Dig­i­tal Space"

Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.

00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании Mon­goDB
05:35 Декабрьский Lin­ux Patch Wednes­day
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23–01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р‑ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rock­star Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало — Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024‑м году
59:24 DevSec­Ops Matu­ri­ty Mod­el 2023
1:01:25 Прощание в стихах от Mr. X

По случаю изучил прошлогодний CISA BOD 23–01 "Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях"

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

По случаю изучил прошлогодний CISA BOD 23-01 Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях

По случаю изучил прошлогодний CISA BOD 23–01 "Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях". Собирался больше года назад, а возможность представилась только сейчас. Интересная тема с точки зрения контроля VM-процесса в организациях со стороны регулятора.

Допустим вы CISA, т.е. приблизительный американский аналог нашего ФСТЭКа. У вас есть подопечные — американские федеральные агентства. Их много, сложно даже сказать сколько. От 60 до 430+. Вы для них подсвечиваете критичные уязвимости в активной эксплуатации, по мере сил, устанавливаете к какому сроку их нужно фиксить. А с безопасностью и с уязвимостями у этих федералов всё равно полный швах. Что делать?

Безопасники CISA почесали голову и решили — давайте насаждать в федеральных агентствах базовые ИБ-процессы.

🔻 Во-первых, пусть ищут активы в своих сетках. Пофиг как. Хоть активным сканированием, хоть снифанием трафика, хоть через API какую. Главное регулярно, раз в неделю. Управление активами — это база.

🔻 Во-вторых, пусть эти активы сканируют на уязвимости. И чтобы не блекбоксом, а нормально, агентно или с привилегированной учёткой. Чтобы скан запускался каждые 2 недели со свежей базой детектов уязвимостей. Не успеваете всё просканить за 2 недели? А пофиг, всё равно запускайте следующий скан. Главное регулярность.

Тю? И всё? Просто рекомендации, выполнение которых никак не проверишь? 😏

Нет, не всё. 😈

🔻 В третьих, результаты сканирования активов требуют складывать в шайтан-поделье CDM Agency Dash­board не позже чем за 72 часа после завершения сканов на уязвимости. Откуда эти данные передаются в CDM Fed­er­al Dash­board для изучения аналитиками CISA. Также требуется скидывать "vul­ner­a­bil­i­ty enu­mer­a­tion per­for­mance data", т.е. по сути логи сканов, чтобы видно было насколько результаты сканирования адекватны.

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

Есть, конечно, и странности. Почему-то не написано напрямую, что инфу по обнаруженным активам тоже нужно CISA скидывать и что адекватность детектирования активов нужно подтверждать. Но, возможно, это подразумевается или добавят потом. Вообще документ прикольный, много тонких технических моментов разъясняется по-человечески.

Ещё в этом же документе есть тема, что агентства должны быть готовы по запросу CISA поискать у себя определенные активы или уязвимости, но эта ручка немножко про другое, как мне кажется.

Самая важная часть Vulnerability Management‑а не имеет прямого отношения к уязвимостям

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

Самая важная часть Vulnerability Management-а не имеет прямого отношения к уязвимостям

Самая важная часть Vul­ner­a­bil­i­ty Management‑а не имеет прямого отношения к уязвимостям. Подумал, что если суммировать весь опыт практического внедрения VM‑а и выделить самое важное, то это будет оно.

В первую очередь у безопасника VM-щика должна голова болеть не об автоматически продетектированных на каком-то скоупе уязвимостях, а о том, что где-то есть какие-то IT-активы, о которых он вообще ни сном, ни духом.

По закону подлости именно там будет основное адище и именно там будут резвиться злоумышленники. А когда произойдёт инцидент, VM-щику будет нечего сказать кроме "а я не знал, что у нас такие активы есть" и вид он будет иметь весьма бледный. 😱

К существующей в организации системе инвентаризации должно быть максимальные недоверие. У вас действительно нет неучтённых активов? А если найду? (с)

Вопросы навскидку к системе инвентаризации:

🔹 А филиалы все? А дочерние/купленные компании все?
🔹 А десктопы все? И ноутбуки все? И у удалёнщиков, которые по VPN‑у не подключаются? И на всех ОС?
🔹 А сервера все? И которые не в домене? И которые в закрытых сетках? И которые в облаке? И которые на других внешних хостингах когда-то подрядчиками развенуты? А ERP-система? А Kuber­netes?
🔹 А сетевые устройства все?
А вот телефония? А вот камеры? А вот СКУДы? А вот экраны в переговорках? А вот система бронирования переговорок?

Можно до бесконечности продолжать.

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

Когда есть информация, что активы в принципе есть, можно копать вглубь:

🔸 А кто ответственный за актив? Кто должен обновлять этот актив? С какой периодичностью это делается? Что будет, если обновление по факту не производится?
🔸 А что это за актив? Какая у него критичность?
🔸 А можем ли мы сканировать этот актив на уязвимости? А если не можем, то как мы будем с этим активом дальше жить? Откажемся от использования актива, купим сканер, напишем свой сканер, будем руками проверять?
🔸 Если это сервер/десктоп можно уже инвентаризацией софтов заниматься и тоже прикидывать есть ли у нас средства для детектирования уязвимостей для этих софтов и как жить, если нет. Откажемся от использования софта, купим сканер, напишем свой сканер, будем руками проверять?

Посыл такой:

➕ С более-менее адекватной инвентаризацией активов и возможностью транслировать политики в сторону IT нам (крамола!) возможно и детектировать уязвимости не так и важно. 🙄 Видим хосты и то, что они полностью обновляются раз в месяц — отлично. Скорее всего там всё +- нормально. Если видим хост с EOL операционкой, то тоже сканировать на уязвимости излишне — нужно мигрировать. Если видим хост, который не обновлялся год, то тоже сканировать смысла нет — критичных уязвимостей за год гарантированно набежит, нужно разбираться почему процесс регулярного обновления не сработал.

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