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

💂 От наших регуляторов к британским: NCSC опубликовали руководство по Vulnerability Management-у для организаций

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

💂 От наших регуляторов к британским: NCSC опубликовали руководство по Vulnerability Management-у для организаций

💂 От наших регуляторов к британским: NCSC опубликовали руководство по Vulnerability Management-у для организаций. Приятный документ. Написан по-человечески и с прогрессивной позиции. Бальзам на душу. 😇

❗️ В введении подчеркивают: Управление Уязвимостями требуется для контроля как хорошо в вашей организации работает процесс обновления ПО и безопасное конфигурирование. Обновление ПО должно быть регулярным процессом, а не чем-то исключительным и по требованию. Хотя они и признают: многие организации сейчас исповедуют принцип "работает - не трогай". Но это нужно изживать.

Кажется, что документ настолько хорош, что его можно переносить на российские реалии практически без изменений. 🤔

Пока ограничусь весьма вольным переводом Пяти основных принципов:

🔸 Установите политику безусловных обновлений (update by default). Применяйте обновления как можно скорее, в идеале автоматически. Старайтесь укладываться по времени в рекомендуемые сроки обновления в зависимости от типа актива.

🔸 Определите свои активы. Вы должны понимать какие системы и ПО имеются в вашей инфраструктуре (technical estate), какие уязвимости в них присутствуют и какие люди за них отвечают.

🔸 Сортируйте (triaging) и приоритизируйте уязвимости. ❗️ Это требуется для уязвимостей и мисконфигураций, которые не исправляются простым обновлением до последней версии. Т.е. это не для всех уязвимостей, а для относительно небольшой части нетипичных и проблемных.

🔸 Организация должна взять на себя риски необновления. Иногда могут быть веские причины не обновляться. Но принимать решение по такому риску должны ТОПы (senior-level). И это решение должно рассматриваться в контексте Управления Рисками организации. В общем, пусть ТОПы явно подпишутся, что понимают последствия - может в процессе и поменяют своё мнение. 😉

🔸 Проверяйте и регулярно анализируйте свой процесс Управления Уязвимостями. Ваш процесс управления уязвимостями должен постоянно развиваться, чтобы идти в ногу с изменениями в состоянии вашей организации, новыми угрозами или новыми уязвимостями. Быстрее-выше-сильнее и т.д. 🙂

Дальше каждый принцип подробно раскрывается. Если мне будет не лень, то буду их также вольно переводить. 😉
Если вам такое надо, то в реакции кита 🐳 ставьте.

Как будем описывать активы в 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.

Возвращаюсь к теме простой утилиты для управления исправлением уязвимостей

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

Возвращаюсь к теме простой утилиты для управления исправлением уязвимостей

Возвращаюсь к теме простой утилиты для управления исправлением уязвимостей. Собираюсь вести работу в рамках проекта Vulremi на GitHub (заводил 3 года назад и пока там пусто).

Что нужно для MVP? Видятся следующие этапы:

🔹 Научиться раскладывать результаты детектирования уязвимостей и данные по инфре в удобные структурки описывающие активы/хосты (назовём их Активы).

🔹 Научиться на основе Активов генерить/обновлять структурки описывающие требования по исправлению уязвимостей определенными ответственными лицами в определенный срок (назовём их Таски).

🔹 Научиться по Таскам делать сводную статистику по ответственным: сколько Тасок на каждом ответственном, сколько из них укладываются по времени, а сколько нет.

То есть берём источник данных об уязвимостях (результаты сканирований), непрерывно обновляем из него Активы, по Активам непрерывно обновляем статус Тасков, ответственных по просроченным Таскам автоматизированно тыкаем палочкой. Профит. 🙂

Правда ли, что 96% компаний в России можно взломать с помощью старых эксплуатабельных уязвимостей на периметре?

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

Правда ли, что 96% компаний в России можно взломать с помощью старых эксплуатабельных уязвимостей на периметре?

Правда ли, что 96% компаний в России можно взломать с помощью старых эксплуатабельных уязвимостей на периметре? Статья CNews выглядит забавно потому, что там тезис из аналитического отчёта опровергается одним неаргументированным мнением эксперта. Типа завышено и всё тут. Но когда я смотрю на эту цифирь, то я тоже думаю, что она с реальностью не особо бьётся. 🙂 Попробую аргументировать.

🔻Если мы просто посмотрим организации из ЕГРЮЛ, очевидно, что там будет значимое число организаций типа ООО "Вектор", у которых весь условный "сетевой периметр" это сайт-визитка с телефоном и email-ом на бесплатном сервисе. Очевидно, что если у вас нет периметра, уязвимости ему не страшны. 😏

🔻В отчёте Джеты не пишут, что это статистика по всем российским организациям. Они пишут, что отчёт на основе работ с клиентами и опроса более 100 организаций. В статье CNews это тоже пишут "Все данные из отчета относятся к клиентам и сервисам компании «Инфосистемы Джет», но представитель компании объяснил CNews, что эти данные могут быть релевантны для экстраполяции на российские компании в целом, поскольку компания давно на рынке и обслуживает крупнейших клиентов из самых разных сфер, а в статистику вошло около 500 крупных компаний". Т.е. "96% компаний используют на внешнем периметре версии ПО, имеющие уязвимости уровня «Critical» и «High», для которых существуют публично доступные эксплойты" это не про все российские компании, а про некоторую выборку. А оценку для всех российских компаний можно получить путём какой-то хитрой экстраполяции. Но там будет уже не 96%.

🔻 Так от какого числа компаний посчитаны эти 96% и достоверна ли информация, что у них на периметре эксплутабельные уязвимости? Учитывая, что в отчёте ссылаются на сервис Jet Nautilus (надо ж было назваться как и популярная модель раций - в поиске фиг найдёшь 🙂), видимо речь о клиентах этого сервиса. Сколько этих клиентов непонятно. Но цифра 96% может быть, к примеру, получена, если у вас 25 клиентов и у 24 у них вы продетектировали эксплутабельные уязвимости. Если посмотреть описание сервиса, то в части детектирования уязвимостей он проводит "Пассивное сканирование внешней инфраструктуры компании без прямого контакта с ней. Обеспечивает оценку потенциальных векторов атак и инвентаризацию внешнего периметра". Что это за пассивное сканирование без прямого контакта стоит уточнять у Джетов, но я при таких словах воображаю себе, что у них есть доступ к условному Shodan/Censys и они смотрят результаты баннерных детектов через API-шку и ищут для продетектированных CVE-шек эксплоиты. Метод простой, но достоверность таких детектов, конечно, низкая. Но это не более чем мои домыслы на основе чтения лендинга, конкретно нужно у вендора узнавать.

➡️ Так что, имхо, нет. Доля российских компаний, которых можно взломать с помощью старых эксплуатабельных уязвимостей на периметре, меньше 96%. А для того, чтобы оценить сколько конкретно таких компаний нужно уметь активно и достоверно сканировать весь рунет на уязвимости и понимать какие IP-адреса к каким организациям относятся. А до этого это всё прикидки уровня пол-палец-потолок.

Снова забавное от CNews: cтатья "96% компаний в России можно взломать с помощью старых уязвимостей, которые уже описаны в Сети"

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

Снова забавное от CNews: cтатья 96% компаний в России можно взломать с помощью старых уязвимостей, которые уже описаны в Сети

Снова забавное от CNews: cтатья "96% компаний в России можно взломать с помощью старых уязвимостей, которые уже описаны в Сети". 🙂

🔹 Половина статьи про то, что Джеты выпустили отчет за 2023 г. и там якобы написано, что "96% компаний в России используют на внешнем периметре версии софта, имеющие уязвимости критического либо высокого уровня". Ссылку на отчёт Cnews почему-то не приводят, но вот этот отчёт. В нём 96% относятся к несколько другому: "96% компаний используют на внешнем периметре версии ПО, имеющие уязвимости уровня «Critical» и «High», для которых существуют публично доступные эксплойты". Согласитесь, что важную часть месседжа проглотили. Сами данные на основе анализа инфраструктур компаний-клиентов Джета. Как бы ок - аудиты, пентесты, статистика.

🔹 Вторая половина статьи (которая собственно меня и позабавила) озаглавлена "Но всё не так критично". Ага. Т.е. на периметре организаций эксплуатабельные уязвимости, но это не так критично. Тут должна быть интересная аргументация. 🧐 Возможно там нам расскажут про какие-то компенсирующие меры, которые повсюду в организациях внедрены, Zero Trust или что-нибудь такое… Но нет, на самом деле аргументация там такая: "Ведущий инженер CorpSoft24 Михаил Сергеев считает, что уязвимости такого уровня действительно присутствуют у большого количества компаний, но цифра в 96% явно завышена". Во как! Явно завышена. 😅 Джеты пишут так, а Михаил Сергеев, ведущий инженер CorpSoft24, считает иначе. 🤷‍♂️ Шах и мат, аналитики. ♟

Дальше приводятся цитаты Михаила, которые не про "не всё так критично", а про то что Vulnerability Management это слооожна, а у админов лапки: 🐾

🔻 "Для закрытия уязвимостей необходимо чуть ли не ежедневно обновлять ПО, но это очень трудоемкий и требовательный к ресурсам процесс"

🔻 "Обычно компании обновляются когда им требуется дополнительный функционал или возникают проблемы, которые они хотят решить с помощью патча. Многие информационные системы работают в режиме "работает, не трогай" "

А раз так, давайте закроем глазки и не будем нагнетать. 🙈 Так что ли должно следовать по логике автора статьи? 😁

В общем, CNews такой CNews. Что ни материал, то радость, веселье и хорошее настроение. 🤩

Но к 96% из отчёта есть, конечно, вопросики. 🧐

Периодически у меня возникает идея: а почему бы не сделать простую опенсурсную утилиту для контроля исправления уязвимостей в организации?

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

Периодически у меня возникает идея: а почему бы не сделать простую опенсурсную утилиту для контроля исправления уязвимостей в организации?

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

На этом этапе требуется перейти из уютного ИБшного мирка к суровой IT-шной реальности. Согласованию (а затем отслеживанию и отстаиванию) договоренностей по регулярным апдейтам и дедлайнов по исправлению супер-критичных уязвимостей. Хорошо, когда у вас все инструменты для этого есть в рамках вашего энтерпрайзного VM-решения, а что если их по каким-то причинам нет или они вас не устраивают? А активов у вас десятки тысяч со множеством групп ответственных. 🤩

Я на самом деле даже несколько раз такое запиливал и оно работало с ощутимой пользой. Но потом начиналось - в проде такое нельзя держать, несерьёзно. 🫣 Нужно делать по красоте, с проработкой сложной архитектуры, многопользовательскими интерфейсами, правильным оптимизированным кодом и всем прочим. Короче, нормальный серьезный проект, а не поделье наколеночное. И это, конечно, справедливо. Однако такой серьезный проект требует серьезных ресурсов, выделенной команды и всё это начинает жутко буксовать и перерождается в нечто совсем иное. 🙂 Может и неплохое, но уже с другим замыслом и принципами.

Мне же хотелось бы, чтобы было примитивно и наглядно. Вот как OVAL/SCAP в части правил детектирования. Казалось бы возня с нелепыми XML-ками, ха-ха. А насколько живучая тема вышла! 🤔

Какие бы принципы я сформулировал:

🔹 Чтобы всё описывалось JSON-файликами: активы, инвентаризационные объекты на активах, уязвимости, таски на исправление.

🔹 Чтобы были простые скрипты, которые эти файлики молотили в автоматическом режиме и отображали текущее состояние процесса в организации.

🔹 Чтобы не было никаких архитектурных и технических ограничений на логику работы с файликами и можно было гибко настроить любой воркфлоу.

🔹 Чтобы с этим можно было поиграться и понять, какие фичи было бы неплохо получить в рамках полноценного "взрослого" VM-решения. Ну или если какой-то небольшой организации без бюджетов и такое зайдет as is для старта или на постоянку - ну круто. 🙂

Так вот, как считаете, имеет смысл поописывать и покодякать такой наколеночный "игрушечный" Vulnerability Remediation? 🙂