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

Хо-хо-хо или небольшой оффтоп про трудности перевода/произношения и сельское хозяйство

Хо-хо-хо или небольшой оффтоп про трудности перевода/произношения и сельское хозяйство

Хо-хо-хо или небольшой оффтоп про трудности перевода/произношения и сельское хозяйство. Для английского эпизода искал вчера корректный перевод для слова "мотыга" или "тяпка". Слово это однозначно переводится как "hoe". Теперь вопрос: а как это слово произнести так, чтобы это не звучало как "женщина с низкой социальной ответственностью"? 🤔

Не то чтобы я был настолько щепетилен в вопросе использования нецензурной лексики, но у меня везде стоит галка, что "explicit language" я не использую - непорядочек.

В общем, в произношении разница есть, но весьма  тонкая: /hoʊ/ и /hɔː/
По сути уходит ли звук немного в "у" на конце или нет.

Но засада в том, что даже если попасть в нужное произношение, то не поможет. Походу носители тоже не особо эту разницу слышат и эта самая мотыга "hoe" тоже имеет устойчивое сленговое значение как "женщина с низкой социальной ответственностью". 🤷‍♂️🤦‍♂️ Со всех сторон демоны обложили.

Может всё-таки другое слово для данного сельхоз инвентаря подобрать? А вот нету. Есть ещё "cultivator", но это именно тяпка с зубьями для разрыхления. А мотыга больше про сорняки и окучивание.

В общем, кое-как компромиссно сформулировал мотыгу как "long-handled farming weeding tool". И по такому запросу даже ищется что-то более-менее релевантное.

Хотя к английскому слову "сорняк" у меня, разумеется, тоже есть вопросики, но все же несколько меньшие. 😅

Upd. В комментах подсказали, что есть ещё слово "mattock", которое родственное "мотыге". Сила соцсетей! 💪

Закругляю февраль традиционным англоязычным постом и видяшкой

Закругляю февраль традиционным англоязычным постом и видяшкой. 🙂 Чуть-чуть поговорил про опенсурсные проекты (признаться, не было особо времени ими заниматься, пока одни намётки), про PT-шные активности и, естественно, про уязвимости (трендовые и не очень).

———

February 2024: Vulremi, Vuldetta, PT VM Course relaunch, PT TrendVulns digests, Ivanti, Fortinet, MSPT, Linux PW

Hello everyone! In this episode, I will talk about the February updates of my open source projects, also about projects at my main job at Positive Technologies and interesting vulnerabilities.

My Open Source projects
00:14 Vulremi - a simple vulnerability remediation utility
00:55 Vuldetta - an API for detecting vulnerabilities based on a list of Linux packages

Positive Technologies
01:22 Two new video modules for the relaunch of the Vulnerability Management training course
02:00 Monthly digests of trending vulnerabilities

Vulnerabilities
02:17 RCEs in the Ivanti Connect Secure, Ivanti Policy Secure and Ivanti Neurons for ZTA (CVE-2024-21887, CVE-2023-46805, CVE-2024-21893)
03:47 Arbitrary Code Execution vulnerability in Fortinet FortiOS and FortiProxy (CVE-2024-21762)
04:11 Cisco ASA Information Disclosure vulnerability (CVE-2020-3259) is used by the Akira ransomware
04:55 February Microsoft Patch Tuesday
07:14 February Linux Patch Wednesday

🎞 Video
📘 Blogpost
🎞 VKVideo

Хочется немного поиграться с непосредственным детектом уязвимостей - проект Vuldetta

Хочется немного поиграться с непосредственным детектом уязвимостей - проект Vuldetta

Хочется немного поиграться с непосредственным детектом уязвимостей - проект Vuldetta. С 2021 года я работаю над открытым проектом сканера уязвимостей Scanvus для Linux хостов и docker-образов. И с ним всё отлично, кроме того, что он сам уязвимости не детектирует. 😅 Он собирает пакеты и версию дистриба, но для детектирования использует внешние коммерческие API-шки: Vulners Linux API или VulnsIO API. А оно стоит денег и это, естественно, снижает привлекательность утилиты. 🤷‍♂️

Можно ли сделать так, чтобы Scanvus работал без использования коммерческих API? Можно. И тут видятся 2 пути:

🔹 Первый путь - это добавить детектирование уязвимостей непосредственно в Scanvus. Мне это не очень нравится. Мне нравится концепция такого "безмозглого" нейтрального сканера, который может использовать различную внешнюю экспертизу в зависимости от потребностей.

🔹 Второй путь - это сделать некоторый аналог Vulners Linux API или VulnsIO API, который можно было бы развернуть локально в организации и использовать для детекта уязвимостей хотя бы для некоторых Linux дистрибутивов. Понимая, безусловно, что коммерческий сервис будет, скорее всего, поддерживать большее количество дистрибутивов и, возможно, будет даже лучше детектировать. Но от бесплатной свободной альтернативы хуже не будет.

Собственно второй путь и есть Vuldetta. Взять готовые формализованные правила детекта (после возни с OVAL-контентом для Debian я смотрю теперь в сторону OVAL-контента для Ubuntu), разобрать их во что-нибудь простое и удобное для работы (Bulletin|CVE_Number|Distribution_Version|Package_Name|Package_Version), сделать API-шку-сравнивалку версии на хосте с безопасными версиями из OVAL-контента.

Вроде выглядит как изян. А на выходе может получиться штука, которую как минимум можно будет использовать для валидации качества детектирования коммерческих сканеров уязвимостей, а как максимум возможно даже в проде где-то использовать. А так как лицензия будет MIT, то это даже можно будет встроить куда-нибудь как альтернативу жуткому фолсящему Trivy. 😅 И будет на чём тестовый контент для Vulremi генерить опять же. 🙂

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

Как будем описывать активы в 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? Видятся следующие этапы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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